微服务，设计先行.pdf

微服务，设计先⾏

你听说的微服务

独⽴部署 复杂性 解决 不同的语⾔ 独⽴扩展 单独的团队

你学习的微服务 服务注册与发现 负载均衡

服务⽹关 熔断与限流 Spring Cloud Dubbo 微服务治理 配置中⼼ 分布式事务 服务调⽤追踪 gRPC

实际中的微服务 不好测试 分布式事务 性能差

数据难⼀致 服务依赖

问题出在哪了？

微服务不是问题，设计才是

设计不好的问题，微服务解决不了

最好的设计是单体设计 易于测试

数据⼀致 ⼀次性部署 进程内调⽤

微服务为何兴起？

复杂度

对抗软件复杂度

软件设计

解决复杂度问题

只能依赖于软件设计

微服务只是⼀种部署⽅案

今天怎么做设计？

领域驱动开发（DDD）

通⽤语⾔ 模型驱动设计 战略设计 战术设计 理解 DDD

开发⼈员 通⽤语⾔ 业务⼈员 通⽤语⾔：同样的业务语⾔

核⼼域 ⽀撑域 通⽤域 战略设计：切分⼦域

战略设计：组织⼦域 限界上下⽂ 上下⽂映射图

⻆⾊ 关系 互动 实体 聚合 ⼯⼚ 值对象 聚合根 仓库 领域服务 应⽤服务 战术设计：按模板找对象

这和微服务有什么关系？

限界上下⽂

⼀个划分服务的恰当边界

完全独⽴的限界上下⽂

微服务是设计的结果

不是追求的⽬标

⼀次正常的“微”服务开发过程

1. 开发⼀个单体应⽤

2. 按照战略设计，划分限界上下⽂

3.把不同的限界上下⽂划分到模块中

3.当业务成型之后，按需拆分服务

总结

• 微服务，理想很丰满，现实很⻣感

• 微服务要解决复杂度的问题，但复杂度真正的解决只能依赖于设计

• 今天主流的设计⽅式是 DDD ，包括建⽴通⽤语⾔、战略设计和战 术设计

• 战略设计中的限界上下⽂是很好的服务边界