(轉)每一個架構師都應該研究下康威定律

摘要：這篇文章的分享者楊波具備超過10年的互聯網分佈式系統研發和架構經驗，曾前後就任於 eBay 中國研發中心（eBay CDC）、攜程、惟品會（VIPShop）等。本文由攀爬的蝸牛以及田光整理。

　　今天的分享主要來自我以前的工做經驗以及平時的學習總結和思考。我以前的背景主要是作框架、系統和平臺架構，以前工做過的公司 eBay、攜程、惟品會都是平臺型互聯網公司，因此今天主要帶着平臺架構視角和你們分享心得體會。架構的視角每一個人都不同，能夠說一萬種眼光，有業務架構、安全架構、平臺架構、數據架構，各不相同，這裏僅是個人一家之言，歡迎你們加入『聊聊架構』社羣參與討論。今天聊的話題主要包括如下幾點：

• 我對架構定義的理解
• 架構的迭代和演化性
• 構建閉環反饋架構（Architecting for closed loop feedback）
• 談談微服務架構和最新主題
• 架構和組織文化關係
• 架構師心態和軟技能
• 我對一些架構師爭議主題的見解

　　我對架構定義的理解

　　大概在7~8年前，我曾經有一個美國對口的架構師 mentor，他對我講架構實際上是發現利益相關者（stakeholder），而後解決他們的關注點（concerns），後來我讀到一本書《軟件系統架構：使用視點和視角與利益相關者合做》，裏面提到的理念也是這樣說：系統架構的目標是解決利益相關者的關注點。

　　這是從那本書裏頭的一張截圖，我以前公司分享架構定義經常用這張圖，架構是這樣定義的：

• 每一個系統都有一個架構
• 架構由架構元素以及相互之間的關係構成
• 系統是爲了知足利益相關者（stakeholder）的需求構建的
• 利益相關者都有本身的關注點（concerns）
• 架構由架構文檔描述
• 架構文檔描述了一系列的架構視角
• 每一個視角都解決而且對應到利益相關者的關注點。

　　架構系統前，架構師的首要任務是盡最大可能找出全部利益相關者，業務方，產品經理，客戶 / 用戶，開發經理，工程師，項目經理，測試人員，運維人員，產品運營人員等等都有多是利益相關者，架構師要充分和利益相關者溝通，深刻理解他們的關注點和痛點，並出架構解決這些關注點。架構師常犯錯誤是漏掉重要的利益相關者，溝通不充分，都會形成架構有欠缺，不能知足利益相關者的需求。利益相關者的關注點是有可能衝突的，好比管理層（可管理性）vs 技術方（性能），業務方（多快好省）vs 技術方（可靠穩定），這須要架構師去靈活平衡，如何平衡體現了架構師的水平和價值。

　　關於架構的第二點定義是說架構主要關注非功能性需求（non-functional requirements），即所謂的-abilities。

　　這個是我上次公司內分享的一個圖。

　　這個是 slideshare 一個 ppt 裏頭截取的，兩個圖都是列出了架構的非功能性關注點；關於架構的水平該如何衡量，去年我看到一句話，對我影響很大。

Architecture represents the significant design decisions that shape a system, where significant is measured by cost of change.

　　翻譯爲中文就是，架構表示對一個系統的成型起關鍵做用的設計決策，架構定系統基本就成型了，這裏的關鍵性能夠由變化的成原本決定。這句話是 Grady Booch 說的，他是 UML 的創始人之一。

　　進一步展開講，架構的目標是用於管理複雜性、易變性和不肯定性，以確保在長期的系統演化過程當中，一部分架構的變化不會對架構的其它部分產生沒必要要的負面影響。這樣作能夠確保業務和研發效率的敏捷，讓應用的易變部分可以頻繁地變化，對應用的其它部分的影響儘量地小。

　　我剛入軟件開發這個行業之初，談的架構主要是性能，高可用等等。如今，見過無數遺留系統，特別是國內企業 IT 的現狀，無數耦合性系統的遺留系統，不良的架構象手銬同樣緊緊地限制住業務，升級替換成本很是巨大， 因此我更加關注可理解，可維護性，可擴展性，成本 。我想補充一句，創業公司創業之初得到好的架構師或技術 CTO 很是重要。

　　架構的迭代和演化性

　　我是屬於老一代的架構師，99年參加工做。職業初學了不少 RUP，統一軟件過程的理念。RUP 的理念對個人架構有很深的影響，RUP 總結起來就是三個特色：

• 用例和風險驅動 Use Case and risk driven
• 架構中心 Architecture centric
• 迭代和增量 Iterative and incremental

　　RUP 很注重架構，提倡以架構和風險驅動，該開始必定要作端到端的原型 prototype；經過壓測驗證架構可行性，而後在原型基礎上持續迭代和增量式開發，開發->測試->調整架構->開發，循環，以下圖所示：

　　從上圖能夠看出架構師要儘量寫代碼，作測試，紙上談兵式作架構然後丟給團隊的做法很是不靠譜（除非是已經很是清晰成熟的領域）。另外，作技術架構的都有點完美主義傾向，一開始每每喜歡求大求全，忽視架構的演化和迭代性，這種傾向易造產品和用戶之間不能造成有效快速反饋，產品不知足最終用戶需求，繼續看下面兩個圖：

　　第一個圖是講最小可用產品（Minimum Viable Product， MVP）理念，作出最小可用產品，儘快丟給用戶試用，快速獲取客戶反饋，在此基礎上不斷迭代和演化架構和產品。第二個圖是過分工程（Over Engineering）的問題，其實也是講產品架構和用戶之間沒有造成有效的反饋閉環，架構師想的和客戶想的不在一個方向上，經過最小可用產品，快速迭代反饋的策略，能夠避免這種問題。注意，在系統真正地投入生產使用以前，再好的架構都只是假設，產品越晚被使用者使用，失敗的成本和風險就越高，而小步行進，經過 MVP 快速實驗，獲取客戶反饋，迭代演化產品，能有效地減小失敗的成本和風險。

　　另外，多年的經驗告訴我，架構，平臺不是買來的，也不是用一個開源就能得到的，也不是設計出來的，而是長期演化才能落地生根的。給你們推薦兩篇不錯的微信文章：

• 58 同城沈劍：好的架構源於不停地衍變，而非設計
• 宜人貸系統架構–高併發下的進化之路

　　兩篇文章其實都是講架構的迭代和演化性，值得每一個架構師學習吸取。

　　構建閉環反饋架構

　　先分享一個連接，這幾年對我架構影響最深的一篇文章。這篇文章是關於 DevOps 的，但對系統架構一樣適用：The Three Ways: The Principles Underpinning DevOps

　　第一條道路，系統思惟，開發驅動的組織機體，其能力不是製做軟件，而是持續的交付客戶價值，架構師須要有全局視角和系統思惟（System Thinking），深刻理解整個價值交付鏈，從業務需求、研發、測試、集成，到部署運維，這條價值鏈的效率並不依賴於單個或者幾個環節，局部優化的結果每每是全局受損，架構師要站在系統高度去優化整個價值交付鏈，讓企業和客戶之間造成快速和高效的價值傳遞。

　　第二條道路，強化反饋環，任何過程改進的目標都是增強和縮短反饋環。剛入行的工程師，也是中國學生的廣泛問題，就是生產運維意識不足（監控是系統反饋的重要環節）。有兩種花這樣講的：

• no measurement, no improvement 沒有測量，就沒有改進和提高
• What your measure is what you get 你測量什麼，就獲得什麼

　　沒有監控或者監控不完善的系統至關於裸奔，開車上高速無儀表盤。有一篇不少錯的關於測量驅動開發的文章，在 InfoQ 上的，向你們推薦：度量驅動開發 。

　　這篇文章提出了度量驅動開發的理念，即所謂 MDD，在系統，應用和業務，經過三級監控，構建三個反饋環，在監控測量基礎上持續改進系統和架構，我最近也在參考這個理念設計一個電商平臺的技術架構，見下圖：

　　這是一個電商平臺的架構，整個體現了閉環架構的思想，右側是整個平臺的反饋監控環節。具體以下：

• 系統層監控計算網絡存儲，構建系統層的反饋環
• 應用服務層，監控業務、應用、服務，甚至整個研發流程，構建應用和服務層的反饋環
• 客戶體驗層，監控端用戶和分析網站用戶的行爲，構建和客戶的反饋環

　　下面這個圖展現了系統提高和改進的通常方法：

　　收集->測量->調整->閉環重複，在有測量數據和反饋的基礎上，系統、應用、流程和客戶體驗纔有可能得到持續的提高和改善，不然沒有數據的所謂改進只能靠拍腦殼或者說猜想。

　　第三條道路，鼓勵敢於承擔責任，冒險試錯和持續提高的文化。這點是最難的，通常和企業人才密度有關。工具，技術，流程只是一個公司的冰山浮出水面的部分，而真正對企業效能影響大的則是冰山水下的部分，即企業的人和文化，架構師做爲技術和架構的佈道者，有責任義務鼓勵和推進試錯文化。

　　架構師要深刻領會這三條道路，關注整個價值交付鏈的效率，關注每一個環節的閉環反饋，鼓勵和推進公司的試錯文化，打造全系統的閉環架構（Architecting for closed loop feedback），提高整個系統效能。下圖的 DevOps 和每日交付是每個互聯網系統架構師的夢想和努力的方向。

　　談談微服務架構微服務

　　我想你們都聽得不少了，我本人也很是關注和推崇微服務，從技術角度講，我認爲微服務主要體現的是單一職責和關注分離的思想，從單進程模塊化進一步拓展到跨進程分佈式的模塊化。微服務是獨立的開發、測試、部署和升級單元，正如我在第一點架構定義中提到的，微服務中每一個服務能夠獨立演變，它的 cost of change 比較小，總體架構比較靈活，是一種支持創新的演化式架構。去年 Martin Fowler 寫了兩篇文章，給微服務潑冷水的，建議你們好好讀下。

• http://martinfowler.com/bliki/MicroservicePrerequisites.html
• http://martinfowler.com/bliki/MicroservicePremium.html

　　這個圖講何時該引入微服務。微服務有額外成本的，須要搭建框架、發佈、監控等基礎設施。初創和小規模團隊不建議採用。主要決定因素系統複雜性和團隊規模，當到達一個點，單塊架構嚴重影響效率才考慮 。另外補充一點，微服務更可能是關於組織和團隊，而不是技術。

　　架構和組織文化關係

　　再談一下康威定律：

Conway’ s law: Organizations which design systems [...] are constrained to produce designs which are copies of the communication structures of these organizations.

（設計系統的組織，其產生的設計和架構等價於組織間的溝通結構。 )

　　從單塊架構到微服務架構是這個定律的很到體現。

　　團隊是分佈式的，系統架構是單塊的，開發，測試，部署協調溝通成本大，嚴重影響效率，嚴重時團隊之間還容易起衝突 conflict。

　　將單塊架構解耦成微服務，每一個團隊開發，測試和發佈本身負責的微服務，互不干擾，系統效率獲得提高。

　　可見，組織和系統架構之間有一個映射關係（1 ~ 1 mapping），二者不對齊就會出各類各樣的問題，一方面，若是你的組織結構和文化結構不支持，你也沒法成功創建高效的系統架構，例如集中式和嚴格職能（業務， Dev， QA, Deployment, Ops）的企業，很難推行微服服務和 DevOps，推行 Docker/PaaS 平臺也會比較困難，這樣的組織職能之間都傾向於局部優化（local optimization），沒法造成有效和合做和閉環。

　　反過來也是成立的，若是你的系統設計或者架構不支持，那麼你就沒法成功創建一個有效的組織；做爲系統架構師，必定要深刻領會康威定律，設計系統架構以前，先看清組織結構，也要看組織文化（民主合做式，集權式，叢林法則式，人才密度），再根據狀況調整系統架構或者組織架構。

　　架構師心態和軟技能

　　空杯，或者說開放心態（open minded）是一個成熟架構師的應有心態，stay hungry，stay foolish， 心態有多開放，視野就有多開闊。來自《高效能人士的七個習慣~史蒂芬~柯維》的一句話送給每個架構師 :

若是一位具備至關聰明才智的人跟我意見不一樣，那麼對方的主張必有我還沒有體會的奧祕，值得加以瞭解。與人合做最重要的是，重視不一樣個體的不一樣心理、情緒與智能，以及我的眼中所見的不一樣世界。與所見略同的人溝通，益處不大，要有分歧纔有收穫。

　　另外再推薦一個本書《軟件架構師的 12 項修煉》，這書中三個觀點很值得每一個架構師學習領會:

• soft skills are always hard than hard skills，軟技能比硬技能難
• choosing relationship over correctness ，注重關係重於誰對誰錯
• 架構的政治性，在中大型公司裏混的架構師尤爲要學習

　　政治指的是和他人協做將事情搞定的藝術，架構是一種社交活動，在技術的世界裏，我的主義很容易被戰勝，即便你的目的是好的技術是最優的，技術決策是政治決策（technical decisions are political decisions），一個技術產品，一波人能夠作，另外一波人也能夠作，到底誰作的好，真很差說，無論誰作，都給業務套上了一副手銬。

　　架構師如何提高？實戰，實戰，實戰！規劃職業，找好的團隊和項目，總結分享，學習 GitHub 開源項目，儘量參與和開創本身的開源項目和產品，並長期積累。

　　我對一些架構師爭議主題的見解

　　主要爭議是兩個話題：

• 技術和業務的關係。
• 架構師要寫代碼嗎？

　　架構師怎麼回答這類問題？一個成熟架構師的口頭禪：視狀況而定，不必定，是也不是，it depends。技術和業務，架構師要理解業務嗎，看產品和客戶，若是是業務性產品，確定要理解業務，若是是技術型產品，就不必定。

　　架構師要寫代碼？也不必定，我的以爲儘量要寫，若是你寫過十年以上代碼了，每一年很多於 2 萬行，都玩通了，能夠不寫。另外架構師若是寫代碼，要把控度，不要一頭鑽入代碼，花大量時間解決細節和複雜性問題，忽視全局和系統性問題。

　　最後

　　我想說中國如今的互聯網發展趨勢很好，愈來愈多的人加入架構師這個行業，這個行業正在 「萬物生長」。 可是咱們如今尚未馬丁·福勒，adrian cockcroft 這樣的架構牛人物，我輩需不斷努力，期待中國 10~20年後出現超過十個馬丁福勒，adrian cockcroft 這樣的大牛神級人物。咱們必不可中止探索，而一切探索的盡頭，就是重回起點，並對起點有首次般的認識。