42、微服务：从康威定律到实践模式

微服务：从康威定律到实践模式

1. 微服务并非万能药

微服务虽有诸多优势，但并非能解决所有问题。在采用微服务时，我们需保持理性，不能盲目跟风。

2. 康威定律的持续影响

康威定律指出，系统的架构会由公司的沟通和组织架构决定。简单来说，设计系统的组织最终会产生与组织沟通结构相似的设计。同时，还有反向康威定律，即团队的规模、成员构成和地理位置会影响团队决策，最终影响团队产出。

比如，微软曾意识到其“相互竞争的业务单元”层级结构不利于创新，反而成为创新的严重制约因素。于是，公司对大部分组织，尤其是产品工程团队进行了彻底重构，使其更像他们所开发的原生网络软件和微服务，具备自给自足、模块化、规模小、紧密协作、扁平化和集中办公等特点。

如果组织采用垂直团队支持应用的模式，会存在协商和交接成本。因为每个团队有自己的优先级，对应用进行更改时，需要在处理 API 层的团队、控制业务逻辑的团队以及锁定数据层的数据库管理员（DBAs）之间进行协调。

而支持微服务的真正跨职能团队则不存在这种后勤拖累。单个团队可以端到端地拥有 API、业务逻辑和数据层，不依赖其他团队，能够按照自己的计划随意发布。API 成为不同垂直团队之间的契约，每个团队可以按照自己的节奏发展，并利用 API 借助其他团队的服务。

微服务可以被看作是“康威定律的一种体现”，它有助于扩展工程组织，而非产品本身。为支持各个微服务会创建更小、更灵活的团队，从而减少沟通开销，提高团队效率。当设计合理时，微服务仅与少数相邻微服务进行通信，这减少了人类沟通模式带来的拖累。

但转向高信任、低沟通型团队（如特警队）也存在问题，即团队隔离。我们需要更加