微服務的災難-康威定律和 KPI 衝突
架構師們常講的設計定律之中最為重要的是康威定律，康威定律的定義：
Conway's law is an adage named after computer programmer Melvin Conway, who introduced the idea in 1967. It states that. organizations which design systems ... are constrained to produce designs which are copies of the communication structures of these organizations.
這裡的 'are constrained to' 即是該定律的精髓所在。如果一個公司的組織架構已經基本成型了，那麼基本上設計出的系統架構和其人員組織架構必然是一致的。
在微服務場景下，團隊會按照其所負責的模組被依次切開成為一個 5-10 人小團隊，然後再由更為頂層的架構少來按照組織架構設計相應的系統。但是這裡面有一個先後關係，是先設計系統，再根據系統來形成對應的團隊。但很多時候也並不一定是如此，因為某些公司招聘速度過快(笑)，可能團隊先形成了，然後才有系統設計，這時候，系統設計可能甚至會被團隊架構所反作用(大概)。還是比較荒唐的。
即使是正常的設計流程，業務需求總是難以預測的。架構師們一般在設計完最初版本的系統架構之後，便會抽身到新的系統中繼續挖坑。新的需求卻在後續的實現過程中漸漸發現無法與最初的架構設計相匹配，具體體現在很難在當前架構上實現，或實現成本過於高昂，單模組幾人天的事情，在當前架構上需要以月計的工時，這顯然是不可接受的。
這時候該怎麼辦呢？沒什麼好辦法。一套系統的架構一旦形成了，如果不是發生重大事件(例如迭代龜速導致公司在響應速度上跟不上競爭對手的步調；或者發生輿論事件，導致公司陷入風口浪尖，高層承諾短時間無法兌現)，一般系統本身並不會有架構上的變動。一線的開發人員最能體會這時候的痛苦，但是痛苦也沒有什麼卵用，因為這時候沒有人有動力去推進架構上的變動。試想，在風平浪靜的平日，沒有任何一個一線 RD 能有能力去推動一堆比他們高兩三級的“專家”做事。而一線的 leader 也沒有動力去做這種於自己於自己組完全無益的變動，哪怕明知道現行架構已完全無法滿足業務需求，多一鍋不如少一鍋。Manager 們就更不用說了，多一事不如少一事，能堆人解決的問題就儘量不用技術去解決。
所以你也看到了，這種問題是無法解決的。曾經在和同事討論的時候，同事提出，按照這種說法來看的話，小公司的架構可能比大公司還要靠譜？
這當然也不一定，小公司一般開不出優秀人才的價格，所以優秀的架構師基本上是不會去小公司的，這就意味著大多數小公司的架構，肯定更加不靠譜。除非他們能持續發展壯大，公司財務健康，在不進行服務治理沒有辦法繼續做業務的困境時，招入了合適的架構師來做全域性把控，完成一次大的整體重構，徹底償還歷史技術棧，才會慢慢有所好轉。當然這也只是個空想，業務驅動的公司不可能把業務完全停下來支援這種技術上的整體重構，記得阿里的人說在 09 年的時候進行公司的服務化，讓整個公司的業務停了半年？這種專案如果最後效果不好，那負責人肯定是要離職謝罪的。大多數技術老闆也是一定沒有這個魄力讓業務半年沒有進展的，這樣搞不好直接就被 CEO 幹掉了好嗎。
從技術上來講有解決方案的問題，如果把政治也考慮在內，可能就變成了無解的問題。大多數公司內的業務系統所要承受的這個痛苦的過程從公司發展的歷程上來講，是必然的。所以各位技術同學，就不要抱怨業務程式碼寫得亂了。
技術人員所能發揮作用的範圍被限制於自己的模組內，或者那些願意接自己需求的其它支援系統間。除了前面說的組織架構的問題，還需要考慮 KPI 的問題。
之前和同事一起得到了一個在大公司內推進事情的靠譜結論，如果一件事情在一個部門內就可以解決，那可以開開心心地推動它解決。如果一件事情需要跨部門，那還需要本部門的大領匯出面才能解決，哪怕這事情再小。如果一件事情需要跨兩個部門，那就沒治了，誰出面都不行。這種事情做不了的。而如果一件事情和你要跨的部門 KPI 有衝突，那就更別想了，把部門重組了才能解決，這是 CTO 才能乾的事情。
如果想要在大公司得到較好的績效，遵循 KPI 規則是必然的。沒有辦法。