入门篇-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.