微服务架构整体思路
常见场景实施建议
| 拆分方式 | 基础设施要求 | 服务拆分落地方式 | |
|---|---|---|---|
| 从0开始构建业务系统 | 按业务拆分微服务 | 搭建完善基础设施，按照微服务基础设施优先级逐步落地 | 一步到位 |
| 单体架构微服务化 | 按业务拆分微服务，先从非核心业务开始拆分 | 搭建完善基础设施，按照微服务基础设施优先级逐步落地 | 逐步落地 |
| 粗粒度服务微服务化 | 按质量拆分微服务 | 重用已有基础设施 | 逐步落地 |
| 局部系统优化 | 按质量拆分微服务 | 重用已有基础设施 | 逐步落地 |
按业务拆分微服务
DDD
概要介绍
战略设计
- 领域，对应微服务的“子域”
- 限界上下文，对应微服务的“服务”
战术设计
聚合根、实体、值对象：对应面向对象方法的对象
聚合根：核心的有状态对象
实体：有状态的对象
值对象：无状态的对象
难以落地的核心问题
DDD告诉你限界上下文是什么，却没有告诉你如何划分
实际项目中的业务边界划分
| 做法 | 风险 | 技巧 | |
|---|---|---|---|
| 业务专家 | 以业务专家意见为准 | 业务专家太水 | 从行业挖人才 |
| 粗分+演进 | 先按照某个维度粗粒度划分，后面随着业务发展而演进，划分为细粒度边界 | 太粗导致频繁演进 | 三个火枪手 |
| 参考业界实现 | 直接参考业界类似业务的划分方式 | 照搬导致水土不服 | 三个火枪手 |
实际项目中的服务拆分
服务拆分技巧
服务粒度优先
三个火枪手原则
定义
平均3个开发人员负责一个微服务
剖析
为什么不是1个？
因为没有备份，且一个人思维有局限
为什么不是2个？
- 因为异常情况下剩余1个，压力会很大
- 2个人负责维护一个微服务，微服务复杂度偏低
为什么不是4个或者5个？
如果4个或4个以上，每个人不一定能掌握单个服务所有细节
技巧
- 微服务数量=服务端开发人数/3
- 3=1+2，1个有经验的（P7/P6+），2个普通的（P5/P6）
- 处于维护期的服务，维护人员为2人
案例
一对一服务映射
多对一服务映射
一对多服务映射
####### 技巧
列出核心业务功能的处理流程，将流程中的处理步骤作为拆分的维度
####### 案例
方案1：拆分为5个
方案2：拆分为2个，下单（包含订单生成、订单支付）、物流（包含商家发货、确认收货、交易成功）
方案3：拆分为3个，下单（包含订单生成、订单支付）、发货（包含商家发货）、收货（包含确认收货、交易成功）
按质量属性拆分微服务
按性能拆分
方法：根据运维系统统计请求量排名前3的业务，将流量最大的业务以及强关联的业务拆分出来
目的：降低业务互相影响程度，拆分后优化流量大的业务，提升性能降低成本
按业务重要程度拆分
方法：将重要程度高的业务拆分出来，注意重要程度高不一定是流量大的
目的：降低业务互相影响程度，拆分后提升重要程度高的业务的可用性
案例：儿童电话手表的电话功能
按可用性拆分
方法：将经常出问题的业务拆分出来
目的：降低业务互相影响程度，拆分后有针对性的提升问题多的业务
按稳定性拆分
方法：将稳定的业务拆分出来
目的：降低业务互相影响程度，拆分后有利于不断变化的业务快速迭代
