入门篇-02从单体应用走向服务化

入门篇-02从单体应用走向服务化

01 | 什么时候进行服务化拆分？

1、经验

1）项目第一个阶段主要目标是快速开发和验证想法，证明产品思路是否可行。
2）这个阶段功能设计一般不会太复杂，开发采取快速迭代的方式，架构也不适合多度设计。

2、服务化拆分

1）根据实际项目经验，当单体应用同时进行开发的人员超过10人，这个时候就需要考虑进行服务化拆分了。

02 | 服务化拆分的方法

1、服务化拆分的两种方式

1. 纵向拆分
	1）从业务纬度进行拆分。
	2）标准是按照业务的关联程度来决定，关联比较密切的业务适合拆分为一个微服务，而功能相对独立的业务适合单独拆分为一个微服务。
2. 横向拆分
	1）从公共且独立功能纬度拆分。
	2）标准是按照是否有公共的被多个其他服务调用，且依赖的资源独立不与其他业务耦合。

2、实施服务化拆分

1）最有效的手段就是将不同的功能模块服务化，独立部署和运维。
2）实际业务中这两种拆分方式一般是相互结合使用的，如果业务比较多分散，适合做纵向拆分。如果多个业务之间有公共模块耦合，适合把公共模块拆分出来，适合做横向拆分。

03 | 服务化拆分的前置条件

1、服务如何定义

1）单体应用不同模块之间相互交换时，通常是以类库的方式提供各个模块的功能。
2）对于微服务，每个服务都运行在各自的进程之中，服务之间的调用都通过接口描述来约定，约定内容包括接口名、接口参数以及接口返回值。

2、服务如何发布

1）单体应用部署在同一个WAR包里，接口之间的调用属于进程内的调用。
2）拆分为微服务后，需要一个类似登记处的地方，记录每个服务提供者的地址以供服务调用者查询，在微服务架构里，这个地方就是注册中心。

3、服务如何监控

1）对于一个服务，通常关心QPS（调用量）、AvgTime（平均耗时）、P999（99.9%的请求性能在多少毫秒以内）这些指标。
2）采用一种通用的监控方案，能够覆盖业务埋点、数据收集、数据处理、以及数据展示的全链路功能。

4、服务如何治理

1）拆分微服务架构后，服务的数量变多了，依赖关系也变复杂了。
2）可以设定一个调用性能的阈值，一段时间内一直超过该值，依赖服务的调用可以直接返回，这就是熔断。

5、故障如何定位

1）需要一种解决方案能够将一次用户请求进行标记，并在多个依赖的服务系统中传递，以便串联所有路径，从而进行故障定位。

04 | 总结

1、拆分手段

1）无论是纵向拆分还是横向拆分，都是将单体应用庞杂的功能进行拆分，抽离成单独的服务部署。

2、拆分粒度

1）功能拆分不是越细越好，多维度的拆分反而会让服务数量膨胀变得难以管理。
2）拆分要根据自己业务现状和团队人员技术水平决定拆分的粒度。
3）建议的标准是按照每个开发人员负责不超过3个大的服务为标准。

参考文献：

[1]胡忠想. 从0开始学微服务[M]. 极客时间, 2018.