从单体应用走向服务化

以前讲解了什么是微服务：微服务的核心在于服务治理，微服务架构是将复杂臃肿的单体应用进行细粒度的服务化拆分，每一个拆分出来的服务各自独立打包部署，并交由小团队进行开发和运维，从而极大地提升了应用交付的效率。

何时进行服务化拆分？拆分单体应用有哪些标准呢？

何时进行服务化拆分？

好比作社交 App，初期为了快速上线，验证可行性，能够只开发首页信息流、评论等基本功能。产品上线后，通过一段时间的运营，用户开始逐步增多，可行性验证经过，下一阶段就须要进一步增长更多的新特性来吸引更多的目标用户，好比再给这个社交 App 添加我的主页显示、消息通知等功能。

这个时候就须要大规模地扩张开发人员，以支撑多个功能的开发。若是这个时候继续采用单体应用架构，多个功能模块混杂在一块儿开发、测试和部署的话，就会致使不一样功能之间相互影响，一次打包部署须要全部的功能都测试 OK 才能上线。并且，多个功能模块混部在一块儿，对线上服务的稳定性也是个巨大的挑战。

再例举一个 58 到家的例子，随着业务愈来愈复杂，数据量愈来愈大，并发量愈来愈大，15 年的时候，58 到家的架构碰到了种种问题：

• 垂直业务扩展，家政、丽人、速运、平台，一些类似的业务代码拷贝愈来愈严重
• 数据量、并发量提高，底层架构复杂性不断向上游扩散，全部调用方都须要关注缓存、分库、存储引擎等，效率逐步下降
• jar 包耦合，多个系统依赖一个公用的 jar 包，一个业务升级致使兼容性问题，影响其余业务
• 数据库耦合，多个业务公用一个数据库，相互耦合，相互影响
• SQL 质量低，业务相互耦合，一个业务编写了一个低质量的 SQL，致使其余业务受影响

这个时候 58 到家开始进行服务化拆分，找到通用痛点，抽象出通用数据访问与子业务，而后将它们下沉成微服务。

通常来讲，一旦单体应用同时进行开发的人员超过 10 人，就会遇到上面的问题，这个时候就该考虑进行服务化拆分了。

服务化拆分的两种姿式

那么服务化拆分具体该如何实施呢？一个最有效的手段就是将不一样的功能模块服务化，独立部署和运维。之前面提到的社交 App 为例，能够认为首页信息流是一个服务，评论是一个服务，消息通知是一个服务，我的主页也是一个服务。

这种服务化拆分方式是纵向拆分，是从业务维度进行拆分。标准是按照业务的关联程度来决定，关联比较密切的业务适合拆分为一个微服务，而功能相对比较独立的业务适合单独拆分为一个微服务。

还有一种服务化拆分方式是横向拆分，是从公共且独立功能维度拆分。标准是按照是否有公共的被多个其余服务调用，且依赖的资源独立不与其余业务耦合。

之前面的社交 App 为例，不管是首页信息流、评论、消息箱仍是我的主页，都须要显示用户的昵称。若是把用户的昵称功能单独部署成一个独立的服务，那么有什么变动我只须要上线这个服务便可，其余服务不受影响，开发和上线成本就大大下降了。

服务化拆分的前置条件

通常状况下，业务系统引入新技术就必然会带来架构的复杂度提高，在具体决策前，先要认识到新架构会带来哪些新的问题，这些问题你和你的团队是否可以解决？如何解决？是本身投入人力建设，仍是采用业界开源方案？

下面几个问题，是从单体应用迁移到微服务架构时必将面临也必须解决的。

• 服务如何定义：对于单体应用来讲，不一样功能模块以前相互交互时，一般是以类库的方式来提供各个模块的功能。对于微服务来讲，每一个服务都运行在各自的进程之中，经过接口向外界传达信息。不管采用哪一种通信协议，是 HTTP 仍是 RPC，服务之间的调用都经过接口描述来约定，约定内容包括接口名、接口参数以及接口返回值。

• 服务如何发布和订阅：单体应用因为部署在同一个 WAR 包里，接口之间的调用属于进程内的调用。而拆分为微服务独立部署后，就须要一个可以记录每一个服务提供者的地址以供服务调用者查询，也就是注册中心（如 Zookeeper、Eureka、Consul 等）。

• 服务如何监控：对于一个服务，须要一种通用的监控方案，可以覆盖业务埋点、数据收集、数据处理，最后到数据展现的全链路功能。

• 服务如何治理：拆分为微服务后，服务的数量变多，依赖关系变复杂。好比一个服务的性能有问题时，依赖的服务也会受影响。能够设定一个调用性能阈值，若是一段时间内一直超过阈值，那么依赖服务的调用能够直接返回，也就是熔断。

• 故障如何定位：拆分为微服务后，一次用户调用可能依赖多个服务，每一个服务又部署在不一样的节点上，若是用户调用出现问题，须要一种解决方案可以将一次用户请求进行标记，并在多个依赖的服务系统中继续传递，以便串联全部路径，从而进行故障定位。

针对上述问题，必须有可行的解决方案以后，才能进行服务化拆分。

总结

不管是纵向拆分仍是横向拆分，都是将单体应用庞杂的功能进行拆分，抽离成单独的服务部署。

但并非功能拆分的越细越好，过分的拆分反而会让服务数量膨胀变得难以管理，所以找到符合本身业务现状和团队人员技术水平的拆分粒度才是可取的。

<center><img src="https://img2018.cnblogs.com/blog/1356806/201910/1356806-20191009000648748-355850292.png" /></center>

参考

https://time.geekbang.org/column/article/13891

https://www.infoq.cn/article/2017/09/Do-your-service-first

原文出处：https://www.cnblogs.com/wupeixuan/p/11657549.html