架構(gòu)師都應(yīng)該知道的康威定律

今天的分享主要來(lái)自我之前的工作經(jīng)驗(yàn)以及平時(shí)的學(xué)習(xí)總結(jié)和思考。我之前的背景主要是做框架、系統(tǒng)和平臺(tái)架構(gòu)，之前的工作過(guò)的公司 eBay、攜程、唯品會(huì)都是平臺(tái)型互聯(lián)網(wǎng)公司，所以今天主要帶著平臺(tái)架構(gòu)視角和大家分享心得體會(huì)。架構(gòu)的視角每個(gè)人都不一樣，可以說(shuō)一萬(wàn)種眼光，有業(yè)務(wù)架構(gòu)、安全架構(gòu)、平臺(tái)架構(gòu)、數(shù)據(jù)架構(gòu)，各不相同，這里僅是我的一家之言，歡迎大家加入『聊聊架構(gòu)』社群參與討論。今天聊的話題主要包括以下幾點(diǎn)：

• 我對(duì)架構(gòu)定義的理解

• 架構(gòu)的迭代和演化性

• 構(gòu)建閉環(huán)反饋架構(gòu)（Architecting for closed loop feedback）

• 談?wù)勎⒎?wù)架構(gòu)和最新主題

• 架構(gòu)和組織文化關(guān)系

• 架構(gòu)師心態(tài)和軟技能

• 我對(duì)一些架構(gòu)師爭(zhēng)議主題的看法

我對(duì)架構(gòu)定義的理解

大概在 7~8年 前，我曾經(jīng)有一個(gè)美國(guó)對(duì)口的架構(gòu)師 mentor，他對(duì)我講架構(gòu)其實(shí)是發(fā)現(xiàn)利益相關(guān)者（stakeholder），然后解決他們的關(guān)注點(diǎn)（concerns），后來(lái)我讀到一本書(shū)《軟件系統(tǒng)架構(gòu):使用視點(diǎn)和視角與利益相關(guān)者合作》，里面提到的理念也是這樣說(shuō)：系統(tǒng)架構(gòu)的目標(biāo)是解決利益相關(guān)者的關(guān)注點(diǎn)。

這是從那本書(shū)里頭的一張截圖，我之前公司分享架構(gòu)定義常常用這張圖，架構(gòu)是這樣定義的：

• 每個(gè)系統(tǒng)都有一個(gè)架構(gòu)

• 架構(gòu)由架構(gòu)元素以及相互之間的關(guān)系構(gòu)成

• 系統(tǒng)是為了滿足利益相關(guān)者（stakeholder）的需求要構(gòu)建的

• 利益相關(guān)者都有自己的關(guān)注點(diǎn)（concerns）

• 架構(gòu)由架構(gòu)文檔描述

• 架構(gòu)文檔描述了一系列的架構(gòu)視角

• 每個(gè)視角都解決并且對(duì)應(yīng)到利益相關(guān)者的關(guān)注點(diǎn)。

架構(gòu)系統(tǒng)前，架構(gòu)師的首要任務(wù)是盡最大可能找出所有利益相關(guān)者，業(yè)務(wù)方，產(chǎn)品經(jīng)理，客戶(hù) / 用戶(hù)，開(kāi)發(fā)經(jīng)理，工程師，項(xiàng)目經(jīng)理，測(cè)試人員，運(yùn)維人員，產(chǎn)品運(yùn)營(yíng)人員等等都有可能是利益相關(guān)者，架構(gòu)師要充分和利益相關(guān)者溝通，深入理解他們的關(guān)注點(diǎn)和痛點(diǎn)，并出架構(gòu)解決這些關(guān)注點(diǎn)。架構(gòu)師常犯錯(cuò)誤是漏掉重要的利益相關(guān)者，溝通不充分，都會(huì)造成架構(gòu)有欠缺，不能滿足利益相關(guān)者的需求。利益相關(guān)者的關(guān)注點(diǎn)是有可能沖突的，比如管理層（可管理性）vs 技術(shù)方（性能），業(yè)務(wù)方（多快好?。﹙s 技術(shù)方（可靠穩(wěn)定），這需要架構(gòu)師去靈活平衡，如何平衡體現(xiàn)了架構(gòu)師的水平和價(jià)值。

關(guān)于架構(gòu)的第二點(diǎn)定義是說(shuō)架構(gòu)主要關(guān)注非功能性需求（non-functional requirements），即所謂的-abilities。

這個(gè)是我上次公司內(nèi)分享的一個(gè)圖。

這個(gè)是 slideshare 一個(gè) ppt 里頭截取的，兩個(gè)圖都是列出了架構(gòu)的非功能性關(guān)注點(diǎn)；關(guān)于架構(gòu)的水平該如何衡量，去年我看到一句話，對(duì)我影響很大。

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

翻譯為中文就是，架構(gòu)表示對(duì)一個(gè)系統(tǒng)的成型起關(guān)鍵作用的設(shè)計(jì)決策，架構(gòu)定系統(tǒng)基本就成型了，這里的關(guān)鍵性可以由變化的成本來(lái)決定。這句話是 Grady Booch 說(shuō)的，他是 UML 的創(chuàng)始人之一。

進(jìn)一步展開(kāi)講，架構(gòu)的目標(biāo)是用于管理復(fù)雜性、易變性和不確定性，以確保在長(zhǎng)期的系統(tǒng)演化過(guò)程中，一部分架構(gòu)的變化不會(huì)對(duì)架構(gòu)的其它部分產(chǎn)生不必要的負(fù)面影響。這樣做可以確保業(yè)務(wù)和研發(fā)效率的敏捷，讓?xiě)?yīng)用的易變部分能夠頻繁地變化，對(duì)應(yīng)用的其它部分的影響盡可能地小。

我剛?cè)胲浖_(kāi)發(fā)這個(gè)行業(yè)之出，談的架構(gòu)主要是性能，高可用等等?，F(xiàn)在，見(jiàn)過(guò)無(wú)數(shù)遺留系統(tǒng)，特別是國(guó)內(nèi)企業(yè) IT 的現(xiàn)狀，無(wú)數(shù)耦合性系統(tǒng)的遺留系統(tǒng)，不良的架構(gòu)象手銬一樣牢牢地限制住業(yè)務(wù)，升級(jí)替換成本非常巨大， 所以我更加關(guān)注可理解，可維護(hù)性，可擴(kuò)展性，成本 。我想補(bǔ)充一句，創(chuàng)業(yè)公司創(chuàng)業(yè)之初獲得好的架構(gòu)師或技術(shù) CTO 非常重要。

架構(gòu)的迭代和演化性

我是屬于老一代的架構(gòu)師，99年 參加工作。職業(yè)初學(xué)了很多 RUP，統(tǒng)一軟件過(guò)程的理念。RUP 的理念對(duì)我的架構(gòu)有很深的影響，RUP 總結(jié)起來(lái)就是三個(gè)特點(diǎn)：

• 用例和風(fēng)險(xiǎn)驅(qū)動(dòng) Use Case and risk driven

• 架構(gòu)中心 Architecture centric

• 迭代和增量 Iterative and incremental

RUP 很注重架構(gòu)，提倡以架構(gòu)和風(fēng)險(xiǎn)驅(qū)動(dòng)，該開(kāi)始一定要做端到端的原型 prototype；通過(guò)壓測(cè)驗(yàn)證架構(gòu)可行性，然后在原型基礎(chǔ)上持續(xù)迭代和增量式開(kāi)發(fā)，開(kāi)發(fā)->測(cè)試->調(diào)整架構(gòu)->開(kāi)發(fā)，循環(huán)，如下圖所示：

從上圖可以看出架構(gòu)師要盡可能寫(xiě)代碼，做測(cè)試，紙上談兵式做架構(gòu)而后丟給團(tuán)隊(duì)的作法非常不靠譜（除非是已經(jīng)非常清晰成熟的領(lǐng)域）。另外，做技術(shù)架構(gòu)的都有點(diǎn)完美主義傾向，一開(kāi)始往往喜歡求大求全，忽視架構(gòu)的演化和迭代性，這種傾向易造產(chǎn)品和用戶(hù)之間不能形成有效快速反饋，產(chǎn)品不滿足最終用戶(hù)需求，繼續(xù)看下面兩個(gè)圖：

第一個(gè)圖是講最小可用產(chǎn)品（Minimum Viable Product， MVP）理念，做出最小可用產(chǎn)品，盡快丟給用戶(hù)試用，快速獲取客戶(hù)反饋，在此基礎(chǔ)上不斷迭代和演化架構(gòu)和產(chǎn)品。第二個(gè)圖是過(guò)度工程（Over Engineering）的問(wèn)題，其實(shí)也是講產(chǎn)品架構(gòu)和用戶(hù)之間沒(méi)有形成有效的反饋閉環(huán)，架構(gòu)師想的和客戶(hù)想的不在一個(gè)方向上，通過(guò)最小可用產(chǎn)品，快速迭代反饋的策略，可以避免這種問(wèn)題。注意，在系統(tǒng)真正地投入生產(chǎn)使用之前，再好的架構(gòu)都只是假設(shè)，產(chǎn)品越晚被使用者使用，失敗的成本和風(fēng)險(xiǎn)就越高，而小步行進(jìn)，通過(guò) MVP 快速實(shí)驗(yàn)，獲取客戶(hù)反饋，迭代演化產(chǎn)品，能有效地減少失敗的成本和風(fēng)險(xiǎn)。

另外，多年的經(jīng)驗(yàn)告訴我，架構(gòu)，平臺(tái)不是買(mǎi)來(lái)的，也不是用一個(gè)開(kāi)源就能獲得的，也不是設(shè)計(jì)出來(lái)，而是長(zhǎng)期演化才能落地生根的給大家推薦兩篇不錯(cuò)的微信文章（微信不能插入鏈接，根據(jù)題目 Google 下即可）：

• 58 同城沈劍：好的架構(gòu)源于不停地衍變，而非設(shè)計(jì)

• 宜人貸系統(tǒng)架構(gòu)–高并發(fā)下的進(jìn)化之路

兩篇文章其實(shí)都是講架構(gòu)的迭代和演化性，值得每個(gè)架構(gòu)師學(xué)習(xí)吸收。

構(gòu)建閉環(huán)反饋架構(gòu)

先分享一個(gè)鏈接，這幾年對(duì)我架構(gòu)影響最深的一篇文章。這篇文章是關(guān)于 DevOps 的，但對(duì)系統(tǒng)架構(gòu)同樣適用：http://itrevolution.com/the-three-ways-principles-underpinning-devops/?

第一條道路，系統(tǒng)思維，開(kāi)發(fā)驅(qū)動(dòng)的組織機(jī)體，其能力不是制作軟件，而是持續(xù)的交付客戶(hù)價(jià)值，架構(gòu)師需要有全局視角和系統(tǒng)思維（System Thinking），深入理解整個(gè)價(jià)值交付鏈，從業(yè)務(wù)需求、研發(fā)、測(cè)試、集成，到部署運(yùn)維，這條價(jià)值鏈的效率并不依賴(lài)于單個(gè)或者幾個(gè)環(huán)節(jié)，局部?jī)?yōu)化的結(jié)果往往是全局受損，架構(gòu)師要站在系統(tǒng)高度去優(yōu)化整個(gè)價(jià)值交付鏈，讓企業(yè)和客戶(hù)之間形成快速和高效的價(jià)值傳遞。

聊聊架構(gòu)第二條道路，強(qiáng)化反饋環(huán)，任何過(guò)程改進(jìn)的目標(biāo)都是加強(qiáng)和縮短反饋環(huán)。剛?cè)胄械墓こ處?，也是中?guó)學(xué)生的普遍問(wèn)題，就是生產(chǎn)運(yùn)維意識(shí)不足（監(jiān)控是系統(tǒng)反饋的重要環(huán)節(jié)）。有兩種化這樣講的：

• no measurement, no improvement 沒(méi)有測(cè)量，就沒(méi)有改進(jìn)和提升

• What your measure is what you get 你測(cè)量什么，就得到什么

沒(méi)有監(jiān)控或者監(jiān)控不完善的系統(tǒng)相當(dāng)于裸奔，開(kāi)車(chē)上高速無(wú)儀表盤(pán)。有一篇很多錯(cuò)的關(guān)于測(cè)量驅(qū)動(dòng)開(kāi)發(fā)的文章，在 InfoQ 上的，向大家推薦：

http://www.infoq.com/cn/articles/metrics-driven-development

這篇文章提出了度量驅(qū)動(dòng)開(kāi)發(fā)的理念，即所謂 MDD，在系統(tǒng)，應(yīng)用和業(yè)務(wù)，通過(guò)三級(jí)監(jiān)控，構(gòu)建三個(gè)反饋環(huán)，在監(jiān)控測(cè)量基礎(chǔ)上持續(xù)改進(jìn)系統(tǒng)和架構(gòu)，我最近也在參考這個(gè)理念設(shè)計(jì)一個(gè)電商平臺(tái)的技術(shù)架構(gòu)，見(jiàn)下圖：

這是一個(gè)電商平臺(tái)的架構(gòu)，整個(gè)體現(xiàn)了閉環(huán)架構(gòu)的思想，右側(cè)是整個(gè)平臺(tái)的反饋監(jiān)控環(huán)節(jié)。具體如下：

• 系統(tǒng)層監(jiān)控計(jì)算網(wǎng)絡(luò)存儲(chǔ)，構(gòu)建系統(tǒng)層的反饋環(huán)

• 應(yīng)用服務(wù)層，監(jiān)控業(yè)務(wù)、應(yīng)用、服務(wù)，甚至整個(gè)研發(fā)流程，構(gòu)建應(yīng)用和服務(wù)層的反饋環(huán)

• 客戶(hù)體驗(yàn)層，監(jiān)控端用戶(hù)和分析網(wǎng)站用戶(hù)的行為，構(gòu)建和客戶(hù)的反饋環(huán)

下面這個(gè)圖展示了系統(tǒng)提升和改進(jìn)的一般方法：

收集->測(cè)量->調(diào)整->閉環(huán)重復(fù)，在有測(cè)量數(shù)據(jù)和反饋的基礎(chǔ)上，系統(tǒng)、應(yīng)用、流程和客戶(hù)體驗(yàn)才有可能獲得持續(xù)的提升和改善，否則沒(méi)有數(shù)據(jù)的所謂改進(jìn)只能靠拍腦袋或者說(shuō)猜測(cè)。

第三條道路，鼓勵(lì)勇于承擔(dān)責(zé)任，冒險(xiǎn)試錯(cuò)和持續(xù)提升的文化。這點(diǎn)是最難的，一般和企業(yè)人才密度有關(guān)。工具，技術(shù)，流程只是一個(gè)公司的冰山浮出水面的部分，而真正對(duì)企業(yè)效能影響大的則是冰山水下的部分，即企業(yè)的人和文化，架構(gòu)師作為技術(shù)和架構(gòu)的布道者，有責(zé)任義務(wù)鼓勵(lì)和推動(dòng)試錯(cuò)文化。

架構(gòu)師要深入領(lǐng)會(huì)這三條道路，關(guān)注整個(gè)價(jià)值交付鏈的效率，關(guān)注每個(gè)環(huán)節(jié)的閉環(huán)反饋，鼓勵(lì)和推動(dòng)公司的試錯(cuò)文化，打造全系統(tǒng)的閉環(huán)架構(gòu)（Architecting for closed loop feedback），提升整個(gè)系統(tǒng)效能。下圖的 DevOps 和每日交付是每一個(gè)互聯(lián)網(wǎng)系統(tǒng)架構(gòu)師的夢(mèng)想和努力的方向。

談?wù)勎⒎?wù)架構(gòu)微服務(wù)

我想大家都聽(tīng)得很多了，我本人也非常關(guān)注和推崇微服務(wù)，從技術(shù)角度講，我認(rèn)為微服務(wù)主要體現(xiàn)的是單一職責(zé)和關(guān)注分離的思想，從單進(jìn)程模塊化進(jìn)一步拓展到跨進(jìn)程分布式的模塊化。微服務(wù)是獨(dú)立的開(kāi)發(fā)、測(cè)試、部署和升級(jí)單元，正如我在第一點(diǎn)架構(gòu)定義中提到的，微服務(wù)中每個(gè)服務(wù)可以獨(dú)立演變，它的 cost of change 比較小，整體架構(gòu)比較靈活，是一種支持創(chuàng)新的演化式架構(gòu)。去年MartinFowler 寫(xiě)了兩篇文章，給微服務(wù)潑冷水的，建議大家好好讀下。

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

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

這個(gè)圖講什么時(shí)候該引入微服務(wù)。微服務(wù)有額外成本的，需要搭建框架、發(fā)布、監(jiān)控等基礎(chǔ)設(shè)施。初創(chuàng)和小規(guī)模團(tuán)隊(duì)不建議采用。主要決定因素系統(tǒng)復(fù)雜性和團(tuán)隊(duì)規(guī)模，當(dāng)?shù)竭_(dá)一個(gè)點(diǎn)，單塊架構(gòu)嚴(yán)重影響效率才考慮 。另外補(bǔ)充一點(diǎn)，微服務(wù)更多是關(guān)于組織和團(tuán)隊(duì)，而不是技術(shù)。

架構(gòu)和組織文化關(guān)系

再談一下康威定律：

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

（設(shè)計(jì)系統(tǒng)的組織，其產(chǎn)生的設(shè)計(jì)和架構(gòu)等價(jià)于組織間的溝通結(jié)構(gòu)。)

從單塊架構(gòu)到微服務(wù)架構(gòu)是這個(gè)定律的很到體現(xiàn)。

團(tuán)隊(duì)是分布式的，系統(tǒng)架構(gòu)是單塊的，開(kāi)發(fā)，測(cè)試，部署協(xié)調(diào)溝通成本大，嚴(yán)重影響效率，嚴(yán)重時(shí)團(tuán)隊(duì)之間還容易起沖突 conflict。

將單塊架構(gòu)解耦成微服務(wù)，每個(gè)團(tuán)隊(duì)開(kāi)發(fā)，測(cè)試和發(fā)布自己負(fù)責(zé)的微服務(wù)，互不干擾，系統(tǒng)效率得到提升。

可見(jiàn)，組織和系統(tǒng)架構(gòu)之間有一個(gè)映射關(guān)系（1 ~ 1 mapping），兩者不對(duì)齊就會(huì)出各種各樣的問(wèn)題，一方面，如果你的組織結(jié)構(gòu)和文化結(jié)構(gòu)不支持，你也無(wú)法成功建立高效的系統(tǒng)架構(gòu)，例如集中式和嚴(yán)格職能（業(yè)務(wù), Dev, QA, Deployment, Ops）的企業(yè)，很難推行微服服務(wù)和 DevOps，推行 Docker/PaaS 平臺(tái)也會(huì)比較困難，這樣的組織職能之間都傾向于局部?jī)?yōu)化（local optimization），無(wú)法形成有效和合作和閉環(huán)。

反過(guò)來(lái)也是成立的，如果你的系統(tǒng)設(shè)計(jì)或者架構(gòu)不支持，那么你就無(wú)法成功建立一個(gè)有效的組織；作為系統(tǒng)架構(gòu)師，一定要深入領(lǐng)會(huì)康威定律，設(shè)計(jì)系統(tǒng)架構(gòu)之前，先看清組織結(jié)構(gòu)，也要看組織文化（民主合作式，集權(quán)式，叢林法則式，人才密度），再根據(jù)情況調(diào)整系統(tǒng)架構(gòu)或者組織架構(gòu)。

架構(gòu)師心態(tài)和軟技能

空杯，或者說(shuō)開(kāi)放心態(tài)（open minded）是一個(gè)成熟架構(gòu)師的應(yīng)有心態(tài)，stay hungry, stay foolish， 心態(tài)有多開(kāi)放，視野就有多開(kāi)闊。來(lái)自《高效能人士的七個(gè)習(xí)慣~史蒂芬~柯維》的一句話送給每一個(gè)架構(gòu)師 :

如果一位具有相當(dāng)聰明才智的人跟我意見(jiàn)不同，那么對(duì)方的主張必有我尚未體會(huì)的奧秘，值得加以了解。與人合作最重要的是，重視不同個(gè)體的不同心理、情緒與智能，以及個(gè)人眼中所見(jiàn)的不同世界。與所見(jiàn)略同的人溝通，益處不大，要有分歧才有收獲。

另外再推薦一個(gè)本書(shū)《軟件架構(gòu)師的 12 項(xiàng)修煉》，這書(shū)中三個(gè)觀點(diǎn)很值得每個(gè)架構(gòu)師學(xué)習(xí)領(lǐng)會(huì):

• soft skills are always hard than hard skills，軟技能比硬技能難

• choosing relationship over correctness ，注重關(guān)系重于誰(shuí)對(duì)誰(shuí)錯(cuò)

• 架構(gòu)的政治性，在中大型公司里混的架構(gòu)師尤其要學(xué)習(xí)

政治指的是和他人協(xié)作將事情搞定的藝術(shù)，架構(gòu)是一種社交活動(dòng)，在技術(shù)的世界里，個(gè)人主義很容易被打敗，即使你的目的是好的技術(shù)是最優(yōu)的，技術(shù)決策是政治決策（technical decisions are political decisions），一個(gè)技術(shù)產(chǎn)品，一波人可以做，另一波人也可以做，到底誰(shuí)做的好，真不好說(shuō)，不管誰(shuí)做，都給業(yè)務(wù)套上了一副手銬。

架構(gòu)師如何提升？實(shí)戰(zhàn)，實(shí)戰(zhàn)，實(shí)戰(zhàn)！規(guī)劃職業(yè)，找好的團(tuán)隊(duì)和項(xiàng)目，總結(jié)分享，學(xué)習(xí) GitHub 開(kāi)源項(xiàng)目，盡可能參與和開(kāi)創(chuàng)自己的開(kāi)源項(xiàng)目和產(chǎn)品，并長(zhǎng)期積累。

我對(duì)一些架構(gòu)師爭(zhēng)議主題的看法

主要爭(zhēng)議是兩個(gè)話題：

• 技術(shù)和業(yè)務(wù)的關(guān)系。

• 架構(gòu)師要寫(xiě)代碼嗎？

架構(gòu)師怎么回答這類(lèi)問(wèn)題？一個(gè)成熟架構(gòu)師的口頭禪：視情況而定，不一定，是也不是，it depends。技術(shù)和業(yè)務(wù)，架構(gòu)師要理解業(yè)務(wù)嗎，看產(chǎn)品和客戶(hù)，如果是業(yè)務(wù)性產(chǎn)品，肯定要理解業(yè)務(wù)，如果是技術(shù)型產(chǎn)品，就不一定。

架構(gòu)師要寫(xiě)代碼？也不一定，個(gè)人覺(jué)得盡可能要寫(xiě)，如果你寫(xiě)過(guò)十年以上代碼了，每年不少于 2 萬(wàn)行，都玩通了，可以不寫(xiě)。另外架構(gòu)師如果寫(xiě)代碼，要把控度，不要一頭鉆入代碼，花大量時(shí)間解決細(xì)節(jié)和復(fù)雜性問(wèn)題，忽視全局和系統(tǒng)性問(wèn)題。

最后

我想說(shuō)中國(guó)現(xiàn)在的互聯(lián)網(wǎng)發(fā)展趨勢(shì)很好，越來(lái)越多的人加入架構(gòu)師這個(gè)行業(yè)，這個(gè)行業(yè)正在 “萬(wàn)物生長(zhǎng)”。但是我們現(xiàn)在還沒(méi)有馬丁福勒，adrian cockcroft 這樣的架構(gòu)牛人物，我輩需不斷努力，期待中國(guó) 10~20年 后出現(xiàn)超過(guò)十個(gè)馬丁福勒，adrian cockcroft 這樣的大牛神級(jí)人物。我們必不可停止探索，而一切探索的盡頭，就是重回起點(diǎn)，并對(duì)起點(diǎn)有首次般的認(rèn)識(shí)。