可能出乎很多人意料之外的一個事實是，微服務很多核心理念其實在半個世紀前的一篇文章中就被闡述過了，而且這篇文章中的很多論點在軟件開發飛速發展的這半個世紀中竟然一再被驗證，這就是康威定律（Conway's Law）。

康威定律詳解

第一定律：組織溝通方式決定系統設計

人是複雜社會動物，解決好人與人的溝通問題，才能有一個好的系統設計，溝通成本隨著項目或者組織的人員增加呈指數級增長。

生物學家發現靈長類的大腦容量和其對應的族群大小有一定關聯，進而推斷出人類的大腦能維繫的關係的一些有趣估計。舉例來說:

• 親密（intimate）朋友: 5
• 信任（trusted）朋友: 15
• 酒肉（close）朋友: 35
• 照面（casual）朋友: 150

第二定律：時間再多一件事情也不可能做的完美，但總有時間做完一件事情

一口氣吃不成胖子，先搞定能搞定的

先做出來，在不斷迭代優化。複雜的系統需要通過容錯彈性的方式持續優化，不要指望一個大而全的設計或架構，好的架構和設計都是慢慢迭代出來的。

針對問題，解決方法不是消滅這些問題，而是容忍這些問題，在問題發生時，能自動回覆，微服務組成的系統，每一個微服務都可能掛掉，這是常態，我們只有有足夠的冗餘和備份即可。即所謂的 彈性設計（Resilience） 或者叫高可用設計（High Availability）。

這不就是 持續集成 和敏捷開發嗎？的確就是。

第三定律：線型系統和線型組織架構間有潛在的異質同態特性

種瓜得瓜，做獨立自治的子系統減少溝通成本

更直白的說，你想要什麼樣的系統，就搭建什麼樣的團隊。如果你的團隊分成前端團隊，Java後臺開發團隊，DBA團隊，運維團隊，你的系統就會長成下面的樣子：

相反，如果你的系統是按照業務邊界劃分的，大家按照一個業務目標去把自己的模塊做出小系統，小產品的話，你的大系統就會長成下面的樣子，即微服務的架構

在一個團隊內全棧，讓團隊自治，原因就是因為如果團隊按照這樣的方式組建，將溝通的成本維持在系統內部，每個子系統就會更加內聚，彼此的依賴耦合能變弱，跨系統的溝通成本也就能降低。

第四定律 大的系統組織總是比小系統更傾向於分解

合久必分，分而治之,一個大的組織因為溝通成本/管理問題，總為被拆分成一個個小團隊。

做小而美的團隊，人多會帶來溝通的成本，讓效率下降。用一切手段提升溝通效率，能2個人講清楚的事情，就不要拉更多人，每個人每個系統都有明確的分工，出了問題知道馬上找誰，避免踢皮球的問題。

康威定律 告訴我們組織溝通的方式會在系統設計上有所表達，每個子系統都被賦予一定的職責去做大系統的某一小部分，他們和大系統便有了溝通的邊界，所以大的系統也會因此被拆分成一個個小團隊負責的小系統（微服務是一種好的模式）

參考原文：https://yq.aliyun.com/articles/8611

閱讀更多 全民學編程 的文章

關鍵字: 核心理念 溝通 康威