微服务与康威定律

忽略公司的组织结构将带来风险。康威定律普遍适用: 任何组织在设计一套系统时，所交付的设计方案在结构上都与该组织的沟通结构保持一致。

组织的耦合度越低，其创建的系统的模块化就越好，耦合也越低。组织的耦合度越高，其创建的系统的模块化也越差。

组织和架构应该一致。亚马逊相信小团队比大团队的工作更有效，于是产生了著名的两个比萨饼团队。帮助小团队对服务的整个生命周期负责，是驱动亚马逊开发 AWS的一个主要原因，因为团队需要一些工具来自助式地获取相应的计算资源等。网飞确保其本身是由多个小而独立的团队组成，以保证他们创建的服务也能独立于彼此。这确保了系统的架构可以快速优化。实际上，网飞为了所要的系统架构，才设计了这样的组织结构。

设想一个简单的团队，负责系统设计与实现的各个方面。团队内可进行频繁、细粒度的沟通。通过服务拆分，服务内的变化频度远高于服务间变化的频度。服务内部是大量细粒度的方法或函数调用。有着细粒度沟通能力的团队，能够与服务内频繁讨论代码这个需求很好地匹配。

团队需要自己负责部署和维护应用程序，这会激发团队创建易于部署的服务。把决定权给合适的人，赋予团队更多的权力和自治。

多个团队共同维护一个服务的效果不佳。拆分服务的成本太高是多个团队负责单个服务的原因之一。

如果已经尽了最大努力，仍然无法避免共享服务，这时候拥抱内部开源模式可能更合理。一小部分人是核心提交者，是代码的守护者，对代码库负责，是代码库的所有者。核心团队需要对更改进行某种程度的审批。需要确保所有的更改符合该代码库的惯例。好的守护者花费大量的时间和精力与提交者进行清晰地沟通，并对他们的工作方式进行引导。

我们以限界上下文定义服务的边界。希望团队也与限界上下文保持一致。团队在限界上下文中更容易掌握领域的概念，可以简化系统设计和发布的协调工作。

康威定律强调了试图让系统设计跟组织结构不一致所导致的危险。这引导我们试图将服务所有权与团队匹配，与限界上下文匹配。

​