微服务架构整体思路

常见场景实施建议

按业务拆分微服务

DDD

概要介绍

战略设计

1. 领域，对应微服务的“子域”
2. 限界上下文，对应微服务的“服务”

战术设计

聚合根、实体、值对象：对应面向对象方法的对象

聚合根：核心的有状态对象

实体：有状态的对象

值对象：无状态的对象

难以落地的核心问题

DDD告诉你限界上下文是什么，却没有告诉你如何划分

实际项目中的业务边界划分

实际项目中的服务拆分

服务拆分技巧

服务粒度优先

三个火枪手原则

定义

平均3个开发人员负责一个微服务

剖析

为什么不是1个？

因为没有备份，且一个人思维有局限

为什么不是2个？

• 因为异常情况下剩余1个，压力会很大
• 2个人负责维护一个微服务，微服务复杂度偏低

为什么不是4个或者5个？

如果4个或4个以上，每个人不一定能掌握单个服务所有细节

技巧

1. 微服务数量=服务端开发人数/3
2. 3=1+2，1个有经验的（P7/P6+），2个普通的（P5/P6）
3. 处于维护期的服务，维护人员为2人

案例

一对一服务映射

多对一服务映射

一对多服务映射

####### 技巧
列出核心业务功能的处理流程，将流程中的处理步骤作为拆分的维度

####### 案例
方案1：拆分为5个

方案2：拆分为2个，下单（包含订单生成、订单支付）、物流（包含商家发货、确认收货、交易成功）

方案3：拆分为3个，下单（包含订单生成、订单支付）、发货（包含商家发货）、收货（包含确认收货、交易成功）

按质量属性拆分微服务

按性能拆分

方法：根据运维系统统计请求量排名前3的业务，将流量最大的业务以及强关联的业务拆分出来

目的：降低业务互相影响程度，拆分后优化流量大的业务，提升性能降低成本

按业务重要程度拆分

方法：将重要程度高的业务拆分出来，注意重要程度高不一定是流量大的

目的：降低业务互相影响程度，拆分后提升重要程度高的业务的可用性

案例：儿童电话手表的电话功能

按可用性拆分

方法：将经常出问题的业务拆分出来

目的：降低业务互相影响程度，拆分后有针对性的提升问题多的业务

按稳定性拆分

方法：将稳定的业务拆分出来

目的：降低业务互相影响程度，拆分后有利于不断变化的业务快速迭代