记一次服务拆分的复盘流程,也只记录思路，不详细分析

抛出问题

1. 顶层的业务服务之间依赖严重,互相依赖,需要重新分层
2. 统计需求在线服务做
3. 管理接口/C端接口没拆分
4. 如何明确核心服务
5. 如何明确核心业务链路
6. 如何明确服务的边界
7. 核心链路如何保障
8. 每个服务的未来方向

架构优化方向

1. 循环依赖（应用分层）
2. 减少调用链路深度（调用层级）
3. 提高数据复用性（缓存）
4. 流量治理（减低流量水位，在线、离线隔离）
   1. 消除重复调用
   2. 合并小接口，消除峰值调用
   3. 隔离在线系统、job、sop、管理后台系统

说到 服务之间依赖严重,互相依赖
每个人都会说：说明你的服务边界没有想清楚
但是,如何找到系统合适的边界，却没有一个好方法，或好的解决方案
如何划分我们的服务

循环依赖原因

1. 数据过度冗余
2. 缺失业务概念
3. 滥用同步调用

如何解决循环依赖？

• 定义出上下游服务，下游可以依赖上游，不能反过来依赖

  1. 下游需要了解上游的领域知识实现业务,上游服务不受下游服务的业务能力和可用性影响，反之则相反
  2. 衡量耦合级别
     • Level4: 领域知识互为上下游，业务可用性互为上下游
     • Level3: 领域知识互为上下游, 业务可用性为单向上下游
     • Level2: 领域知识为单向上下游，业务可用性互为上下游
     • Level1: 领域知识为单向上下游，业务可用性为单向上下游

• 上游服务的变更需要对下游服务产生影响时，通过事件的方式来实现（异步消息、回调）

• 服务间只通过数据id进行关联，不做过多数据冗余

• 一旦出现上游服务需要感知下游服务的执行情况时，考虑清楚上游服务是否缺少业务概念

• 满足前端逻辑的服务间交互逻辑放到 BFF 中，而不是新增服务间调用

结论

架构设计

• 让我们的组件划分尽量靠近变化的原点，对于互联网来说就是用户和业务，这样的划分能够让我们将变化“隔离”在一定的范围（组件）内，从而帮助我们有效减少改变点。
• 组件之间能够互相调用，但彼此之间不应该有强依赖，即各自完成的业务是相对独立的，不会因为一方掉线而牵连另外一方，比如新闻网站挂掉了，聊天网站应该继续正常提供服务，可能提示用户暂时无法提供新闻信息而已。
• 组件在业务上是鼓励复用的，正是这样的复用才成就了今天的互联网，我们不会每个网站都去实现一个强大的搜索引擎。而被“复用”最多的网站显然会受到追捧，成为明星业务。当然架构上这样的网站必然是健壮的。

一文读懂DDD

https://insights.thoughtworks.cn/microservices-bad-smell-circular-dependency/

https://insights.thoughtworks.cn/how-to-use-upstream-downstream-thinking-to-system-decoupling/

https://insights.thoughtworks.cn/ddd-architecture-design/