微服务架构的利弊与治理

DiffDay2023-09-122025-11-30

微服务架构的背景

互联网时代的大规模、业务无序、变化发展特别快的背景，导致研发人员规模变大，加上硬件的成本能够持续稳定地下降，自然催动系统架构转向微服务架构。

康威定律（1967）

设计系统的架构受制于产生这些设计的组织的沟通结构
软件架构无法超然跳脱组织架构

复杂性优势

复杂是相对于人而言的，是一个主观标准，每个人都可以有不同的裁量。基于大型软件都是由开发者们互相协作完成的这个基本出发点，用大家较为认可的两个概念来解释复杂性来源。

认知负荷（Cognitive Load）：在软件研发中表现为人接受业务、概念、模型、设计、接口、代码等信息所带来的负担大小。系统中个体的认知负担越大，系统就越复杂，这点解释了为什么蚂蚁族群和国家的人口可能一样多，但治理国家比治理一群蚂蚁要更复杂。认知负荷本质上是来自技术的认知复杂度，拆解看是与概念、模型、业务、代码的规模呈正比关系，这些工作都是由人来做的，最终都能被某种比例系数放大之后反应到人员规模N上。可以认为认知负荷的复杂度是 $\mathcal{O}(k×N)$，k 为复杂度比例系数，微服务架构的 k 要比单体架构的 k 更大。
协作成本（Collaboration Cost）：在软件研发中表现为团队共同研发时付出的沟通、管理成本高低。系统个体间协作的成本越高，系统就越复杂，这点解释了为什么小饭馆和国家的构成个体都同样是人类，但治理国家比治理一家饭馆要更复杂。本质上是来自协作的沟通复杂度，沟通成本=$\frac{n×(n-1)}{2}$，是一种随着规模增长呈平方级增长的复杂度，表示方法那就是 $\mathcal{O}(N^2)$，在微服务架构下，组织的拆分与产品的拆分对齐（康威定律），组织的沟通也被拆分为团队内部的沟通与团队之间的协作，这种分治措施有利于控制沟通成本的增长速度，此时沟通成本的复杂度，能缩减至经典分治算法的时间复杂度，即 $\mathcal{O}(NlogN)$

微服务的认知负荷较高，但是协作成本较低。软件研发的整体复杂度是认知负荷与协作成本两者之和，对于单体架构是 $\mathcal{O}(k×N)+\mathcal{O}(N^2)$，对于微服务架构，整体复杂度就是 $\mathcal{O}(k×N)+\mathcal{O}(NlogN)$，由于高次项的差异，N 的规模增加时单体架构的复杂度增长更快。

硬币的背面

系统复杂度增加
复杂链路监控和排障成本增加
服务间通信开销增加，性能退化
海量服务节点，基础组件推广成本居高不下
服务间接口沟通协作成本增加

架构腐化

治理好蜂群只要求蜂王活着即可，治理好饭馆要依赖老板个人的高明厨技，到了治理国家社稷就要求皇帝圣明大臣贤良才行，可见族群运作的复杂度越高，治理难度也越高。

架构腐化（Architectural Decay）只能延缓，无法避免。架构腐化与生物的衰老过程很像，原因都来自于随时间发生的微妙变化，团队对该项目质量的持续保持能力会逐渐下降。一方面是高级技术专家不可能持续参与软件稳定之后的迭代过程，反过来，如果持续绑定在同一个达到稳定之后的项目上，也很难培养出技术专家。

老人的退出新人的加入使得团队总是需要理解旧代码的同时完成新功能，技术专家偶尔进来救火。另一方面是代码会逐渐失控，时间长了一定会有某些并不适合放进最初设计中的需求出现，工期紧任务重、业务复杂代码不熟悉都会成为欠下一笔技术债的妥协理由，原则底线每一次被细微地突破，不断累计破窗效应撕裂放大，最终累积到每个新人到来就马上能嗅出项目老朽腐臭味道的程度。

治理架构腐化唯一有效的办法是演进式的设计，这点与生物族群的延续也很像，户枢不蠹（$d\grave{u}$），也只有流水，才能不腐。

现实问题与挑战

大应用过大

stateDiagram-v2
  direction LR
  state "应用不断变大" as B
  业务不断发展 --> B
  state B {
    开发人员多 
    流量大
    机器多
  }
  B --> 多人协作阻塞
  B --> 变更影响面大

小应用过多

stateDiagram-v2
  direction LR
  state "小应用过多" as B
  业务萎缩 --> B
  拆分过多 --> B
  B --> 资源成本
  B --> 长期维护成本

微服务系统也是生态，28 定律也发挥功效，极少数大应用占有大量流量

微服务过微，牺牲单体架构优势

熵增（性能损耗、稳定性及故障定位）
资源成本和长期维护成本高

复杂度治理

代码、接口、服务等结构要素及其依赖关系的数量（空间复杂度）应保持在合理的水位
数据度量
- 变更耦合度：过高，需求变更涉及团队数 > 3
- 链路过深：深度 > 6
- 物理结构：风险过高，当 5分钟事故定级影响不能接受时

服务收敛

方法论

隐含的是交付速度与稳定性的要求

核心与非核心拆分
常变与非常变拆分

领域化治理—亲和度较高的上下游服务或业务功能模块合并

迭代效率已经不再是关键因素
目的是降低空间复杂度，管理成本下降，获得机房调度、隐私合规、稳定性、性能、成本上的收益
但真正做领域驱动分析，碰到没有统一的标准，依赖专家分析的问题

更细一点

点：收敛服务、接口与代码
线：通过链路观测，削减重复流量，合并编译，合并部署
面：基础设施统一
- 接入层：屏蔽协议差异、沉淀通用能力、助力研效提升
- 存储层：屏蔽存储差异、内置热点缓存、自带容灾能力
体：核心链路强化、框架沉淀、领域治理

量化策略

团队投入规模上下界[1/3, 3]，超过拆分，少于合并
业务复杂度上下界
- 接口量 [4, 100]
- 有效代码行数 [3k, 3w]

机制化是目标

建立对服务健康度评估的 自动识别体系
建立治理系统复杂度的 机制性解决方案，如无用代码的自动清理

参考

1.凤凰架构治理：理解系统复杂性 ↩