康威定律

在设计系统时，组织所交付的方案结构将不可避免地与其沟通结构一致。

 协作问题

根据康威定律，技术架构与组织的职责划分相关，而职责划分从根本上确立了组织的沟通协作方式，这种协作方式最终决定了技术架构的形态。如果你的组织本身是比较松散的协作方式，往往你的架构会变得离散；而如果你的组织是紧耦合的，架构往往也会慢慢向紧耦合的方式发展。

当技术人员将单体应用拆分成多个细粒度服务的时候，就产生了服务之间的协调沟通问题，而这种问题都是建立在组织结构之上的。

组织为了解决协作的问题，就会设置沟通管理方式，当我们对组织划分不合理的时候，解决问题需要跨部门沟通时，就会产生巨大的沟通成本。而康威定律提醒我们，在实施微服务架构时，不仅仅需要关注软件的架构和设计，更要关注团队之间的委派、分配和协作的方式。

如果组织划分不合理将会使我们的工作失焦，导致系统架构与业务沟通协作模式不匹配。

微服务架构倾向于组织架构围绕业务领域边界进行划分，这种协作方式是比较理想的。通过构建与业务架构一致的团队组织，实现每个独立的团队都可以为自己负责的业务和技术负责。这种组织结构的好处在于：需要升级或者变更服务时，各角色成员可以在团队内部进行高效沟通，有利于达成共识和高效协作。只有外部服务之间的接口需要变更时才需要跨部门沟通，如果前期在服务之间的交互上定义了良好的接口，则接口变更的概率并不大，即使接口模式有变更，也可以通过一定的设计模式和规范来协作解决。

组织划分的最终目标是实现每个团队组织都有清晰的边界和职责。通过组织的划分，形成高内聚、可复用的业务形态，聚焦的技术架构有利于功能模块的沉淀积累和迭代演进。把不属于自己职责的业务或者技术，尽量从自己的服务中剔除，通过组织协作的方式实现低耦合，避免职责重复带来的工作重复和效能损失。

康威定律从本质上说明了组织结构对系统架构的影响，强调系统设计与组织结构的不一致导致的危险和协作问题。当我们的系统规模开始扩大时，这种协作问题将会对微服务系统的业务响应、需求变更、质量保证等方面产生更加深刻的影响。

沟通效率问题

《人月神话》中说：一项工作在估算和安排中使用工作单位“人月”来计算成本。这里需要说明的是“成本”虽然可以根据开发产品的人数和时间确定，但是工作的进度却不一定，因为使用“人月”来评估一项工作的规模是存在欺骗性的，人数和时间在一定程度上是无法互换的，一个原因就是忽略了最重要的因素：人员之间的沟通成本。

软件开发本质上是一项系统工作，需要团队成员密切配合才能完成，是错综复杂关系下的一种密集脑力活动实践。沟通、交流的工作量非常大，它很快会消耗任务分解所节省下来的个人时间。而添加更多的人手，实际上增加了沟通的成本，降低了个人的工作效率。

沟通效率往往会受到组织结构的影响。按照康威定律，我们的组织结构应该与我们的应用架构保持一致，最早践行微服务架构的亚马逊和Netflix可以说是执行这条原则的典范，通过小团队的构建提升了沟通的效率。

例如，在Netflix，存在很多小而独立的团队，这些独立的团队创建的服务也是彼此独立的，这最小化了沟通成本，带来了效率的提升。这样，软件架构也可以得到快速迭代和演进。

人与人的沟通是非常复杂的，一个人的沟通精力是有限的，所以当问题太复杂，需要很多人协调解决的时候，我们需要拆分组织来提高沟通效率。团队的组织方式从某种程度上决定了他们设计的系统架构，而高效的沟通不仅有利于为业务人员提供即时的反馈，也能够以最小的代价达成共识，实现降本增效。

组织的演进

在实施微服务初期，管理者一般将大部分精力集中在满足业务和服务的功能性诉求上。很多小型团队在不需要太多精力投入的情况下，通过开源软件搭建注册中心、API网关、容器等微服务基础设施，就可以完成基本的微服务管理功能。

然而，随着业务的快速增长和微服务规模的扩大，以及系统复杂性的上升，维护这样一套基础设施会给业务团队带来额外的压力，在关注业务自身功能的同时，管理者还要将精力消耗在非功能需求和以技术为导向的微服务支撑平台上。这个时候，管理者往往低估了微服务架构的复杂性，以及伴随微服务发展的高可用、高并发、可扩展性等技术诉求。管理者需要重新审视组织结构是否适应公司整体技术架构的发展。微服务架构从某种程度上说是一个CTO工程。

我们需要业务团队更加聚焦于自己的核心业务能力，正如Supercell公司，它是一家典型的以小团队模式进行游戏开发的公司，一般来说两个员工或者5个员工，最多不超过7个员工组成独立的开发团队，称为Cell（细胞），这也是公司名字Supercell（超级细胞）的由来。该公司可以通过这种小团队，快速试错，来检验游戏是否被用户接受和受欢迎程度，实现了小步快跑。

然而Supercell的小团队背后是有一个大的平台组织来做支撑的。

我们说微服务架构同样需要具备平台化的可复用和支撑能力，平台化的思维和支撑能力不仅仅意味着需要建设以技术为导向的微服务架构、自动化发布平台、容器基础设施，还需要组织结构能够根据业务形态进行持续的演进。微服务架构如果想规模化、成体系化发展，甚至像亚马逊和Neftlix这样的公司一样对外输出技术能力，还需要公司做统一的战略规划，需要有以技术为主的平台团队，以及以业务为导向的中台团队。微服务架构的体系化仅从技术维度进行是难以奏效的，最终技术架构一定会受到组织结构的影响，组织结构的演进对企业的竞争力和非线性的增长至关重要。