单体架构&微服务架构&中台服务架构

开门见山，一图胜千言，先来看看单体架构跟微服务架构的区别？

单体服务架构，将所有的功能模块(service)打包到一起并放在一个web容器中运行。

微服务架构，就是将复杂臃肿的单体应用进行细粒度的服务拆分，每个微服务可以交给小的团队进行开发和维护，拆分出来的服务各自独立打包部署。

这两种架构各有优缺点：

　　我之前工作过的几个公司，基本都是单体架构，顶多加一个负载均衡。很多人都有疑问，我们公司的产品是不是适合微服务架构？我们有没有能力把现在的单体架构重构为微服务架构？

　　我觉得，如果公司打算做一个新的产品，团队有这个技术储备，并且公司的业务量在短期内会有一个大的提升，那么尝试微服务架构会是一个明智的选择。

　　但是如果公司的业务已经积累了很多年，并且现在已经有很多独立的业务系统。我们可以把这样的架构叫做“烟囱式架构”，每个业务系统像烟囱一样搞搞耸立，并且系统间的交互错综复杂，那么可以把单体架构改造成微服务架构吗？如何做呢？

　　单体应用改造成微服务架构，需要各个功能模块服务化，通俗地讲，服务化，就是将传统的单体应用中通过jar包依赖方法调用，改造成通过RPC接口远程调用的方式。

　　如果已有的多个业务系统已经上线运行，那么改造起来确实需要费点力气。从单体到微服务的拆分过程，拆分微服务先要把业务梳理清楚，做到心中有数，梳理清楚了那么业务的边界自然清晰了，自然而然对应拆分哪些服务也出来了。新的需求自然放到拆分的微服务，老的逻辑，按照优先级和重要程度一个点一个点的从单体迁移微服务，服务化上线之后，渐渐取代老的单体，等全部拆分完毕，线上稳定之后，自然就可以下掉老的单体应用。

　　了解了微服务的概念后，我再提一个概念“中台服务架构”，中台服务架构的思想是伴随着企业规模不断扩大、业务多元化而形成的。我理解中台服务架构是微服务架构的升级。