波波的架構理念

背景

近期我會陸陸續續把我之前在infoq/聊聊架構等媒體上發表的文章，陸續搬到我的CSDN博客上，這個是第一篇。

這篇有特殊的意義，2015年下半年的時候，我還沒有養成定期總結梳理的習慣，是極客邦的郭蕾鼓勵我嘗試。今天回頭看，這個投資有很大價值，這一路積累了不少東西，後面需要持續積累，將價值和影響力進一步擴大化。

我之前的背景主要是做互聯網框架、中間件和平臺架構，之前工作過的公司eBay、攜程、唯品會都是平臺型互聯網公司，所以今天主要帶着系統和平臺架構的視角和大家分享心得體會。架構的視角每個人都不一樣，可以說是一萬種眼光，有業務架構、平臺架構、數據架構、安全架構等等，各不相同，這裏僅僅是我的一家之言，歡迎大家參與討論。今天聊的話題主要包括以下幾點：

1. 我對架構定義的理解
2. 架構的迭代和演化性
3. 構建閉環反饋架構
4. 再談微服務架構
5. 架構和組織文化關係
6. 架構師心態和軟技能
7. 我對一些架構爭議主題的看法

一、我對架構定義的理解

大概10年前，我曾經有一個對口的美國架構導師，他對我講架構其實是要找出干係人（stakeholders），然後解決他們的關注點(concerns)。後來我讀到一本書《軟件系統架構：使用視點和視角與利益相關者合作》，裏面提到的理念也是這樣的：系統架構的目標是解決利益相關者或者關係人的關注點。

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

1. 每個系統都有一個架構，
2. 架構由架構元素以及相互之間的關係構成，
3. 系統是爲了滿足干係人（stakeholder）的需求而構建的，
4. 干係人都有自己的關注點(concerns),
5. 架構由架構文檔描述，
6. 架構文檔描述了一系列的架構視角，
7. 每個視角都對應到並解決干係人的關注點。

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

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

上圖是我上次在公司內分享的一個圖，

上圖是在slideshare上的一個ppt裏頭截取出來，兩個圖都是列出架構師經常需要關注的非功能性需求。

另外，去年我偶爾看到UML創始人Grady Booch是這樣描述架構的：

“Architecture represents the significant design decisions that shape a system, where significant is measured by cost of change”。
翻譯成中文就是，架構表示對一個系統的成型起關鍵作用的設計決策， 架構定系統基本就成型了，這裏的關鍵性可由變化造成的成本來衡量。

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

我進入軟件開發行業之初，關注的架構主要是性能，高可能等方面。如今，見過無數遺留系統，特別是國內企業IT的現狀，無數耦合性高的遺留系統，不良的架構像手銬一樣牢牢地限制住業務，升級替換成本巨大，所以我現在更關注系統可擴展性，可維護性，可替換性，成本。我順便補充一句，創業公司創業之初獲得好的架構師或技術CTO非常重要，這種重要性在創業公司跨過Product/Market Fit之後，進入Scale規模化階段就更加明顯。

二、架構的迭代和演化性

我是屬於老一代的架構師，99年參加工作。職業初期學了很多RUP(Rational Unified Process)，即統一軟件過程的理念，RUP的理念對我的架構有很深的影響，RUP總結起來有三個特點：

1. 用例和風險驅動（Use Case and Risk Driven）
2. 以架構爲中心（Architecture Centric）
3. 迭代和增量式開發（Iterative and Incremental）

RUP注重架構，提倡以架構作爲最大風險之一驅動開發，並提倡一開始要做端到端的原型prototype，通過壓測等手段儘早驗證架構可行性，然後在原型基礎上持續迭代和增量開發，架構->開發->測試->調整架構->開發，循環，如下圖所示：

從上圖看出，架構師要儘可能寫代碼，做測試，純紙上談兵式做架構而後丟給研發團隊的作法非常不靠譜（除非是已經非常成熟清晰的領域）。

另外，做技術架構的都有點完美主義傾向，一開始往往喜歡求大求全，忽視架構的演化和迭代性，這種傾向易造產品和用戶之間不能形成有效的反饋，產品不滿足最終用戶需求，繼續看下面兩個圖：

第一個圖是講最小可用產品（Minimum Viable Product， MVP）理念，做出最小可用產品，儘快丟給用戶試用，快速獲取客戶反饋，在此基礎上不斷迭代和演化架構和產品。第二個圖是過度工程(Over Engineering)的問題，其實也是講產品架構和用戶之間沒有形成有效的反饋閉環，架構師想的和客戶想的不在一個方向上，通過最小可用產品，快速迭代反饋的策略，可以避免這種問題。

注意，在系統真正地投入生產使用之前，再好的架構都只是假設，產品越晚被使用者使用，失敗的成本和風險就越高，而小步行進，通過MVP快速實驗，獲取客戶反饋，迭代演化產品，能有效地減少失敗的風險和成本。

另外，多年的經驗告訴我，架構，平臺不是買來的，不是用一個開源能馬上獲得的，也不是單純設計出來的，而是長期演化才能落地生根的，給大家推薦兩篇不錯的文章(具體鏈接可以用搜索引擎在網上搜一下)：

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

兩篇文章都是講互聯網系統的迭代演化之路，值得每個架構師學習吸收。

三、構建閉環反饋架構

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

這篇文章講述了企業通向DevOps的三條必經之路，我們來看看這三條道路對架構師的啓示：

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

第二條道路，強化反饋環，任何過程改進都是通過加強和縮短反饋環來達成的，而反饋需要測量和數據，有兩句話值得推薦給大家：

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

沒有監控或者監控不完善的系統相當於開車上高速卻無儀表盤，看不到反饋。Infoq上有一篇很不錯的關於測量驅動開發的文章，推薦閱讀。

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

該體系同樣採用了三級監控和閉環反饋的理念：

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

下面這個圖展示了系統提升和改進的一般方法，

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

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

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

四、再談微服務

微服務我想大家都聽得很多了，我本人也非常關注和推崇微服務。從技術角度講，我認爲微服務主要體現的是單一職責和關注分離的思想，從單進程模塊化進一步擴展到跨進程分佈式的模塊化。微服務是獨立的開發、測試、部署和升級單元，正如我在第一點架構定義中提到的，微服務中每個服務可以獨立演變，它的cost of change比較小，整體架構比較靈活，是一種支持創新的演化式架構。

MartinFowler之前寫過兩篇文章，給微服務潑涼水，建議大家好好讀讀：

• 微服務先決條件
• 微服務的額外成本

第二篇文章裏有個圖，講企業在什麼時候引入微服務合適，

微服務有額外成本，需要搭建配套的框架、發佈和監控等基礎設施。初創和小規模團隊不建議採用。主要決定因素是系統複雜性和團隊規模，當到達一個點，單塊架構嚴重影響效率才考慮引入微服務。

另外補充一點，微服務更多是關於組織和團隊的，而不是技術。

五、架構和組織文化關係

再談一下康威定律：

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，這樣的組織職能之間都傾向於局部優化（local optimization），難於形成有效的合作和閉環。

反過來也是成立的，如果你的系統設計或者架構不支持，那麼你也就無法成功建立一個高效的組織。

作爲系統架構師，一定要深入領會康威定律，設計系統架構之前，先看清組織結構，也要看組織文化（民主合作式、集權式、叢林法則式和人才密度等），再根據情況調整系統架構甚至是組織架構。

六、架構師心態和軟技能

空杯，或者說開放（open minded）心態，是一個成熟架構師的應有心態。你的杯子是空的，才能容納新的東西，保持愚蠢，保持飢餓，心態有多開放，視野就有多開闊。與人溝通協作是不少技術型架構師的軟肋，尤其在聽到不同意見和不同視角觀點的時候。這裏有來自《高效能人士的七個習慣~史蒂芬.柯維》的一句話送給每一個架構師：

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

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

1. Soft skills are always hard than hard skills，軟技能比硬技能難
2. Choosing relationship over correctness，注重關係重於爭論孰對孰錯
3. 架構的政治性，在大中型公司裏工作的架構師尤其要學習。政治指的是和他人協作並將事情搞定的藝術，架構是一種社交活動，在技術的世界裏，個人主義很容易被打敗，即使你的目的是好的技術是最優的。技術決策是政治決策（technical decisions are political decisions），一個技術產品，一波人可以做，另一波人也可以做，到底誰做的好，真不好說，但不管誰做，都給業務套上了一副手銬。

架構師如何提升？實戰，實戰，實戰！管理好自己的時間，規劃職業，找好的團隊和項目，總結分享，學習GitHub開源項目，儘可能參與和開創自己的開源項目和產品，並長期積累。

七、我對一些架構爭議主題的看法

主要有兩個爭議主題：

1. 技術和業務的關係，
2. 架構師要寫代碼嗎？

對於這類問題，一個聰明和有經驗的回答是：視情況而定，不一定，是也不是，it depends。

技術和業務，架構師要理解業務嗎？看產品和客戶，如果是業務型產品，肯定要理解業務，如果是技術型產品，就不一定。但是技術產品也是有客戶的，所以技術也好，業務也好，找準客戶滿足他們的需求是關鍵，脫離客戶和產品，空談技術或業務無意義。

架構師要寫代碼？也不一定，個人覺得儘可能要寫，如果你寫過十年以上代碼了，每年不少於2萬行，都玩通了，可以不寫。另外架構師如果寫代碼，要把控度，不要一頭鑽入代碼，花大量時間解決細節和複雜性問題，忽視全局和系統性問題。

最後

我想說中國現在的互聯網發展趨勢很好，越來越多的人加入架構師這個行業，這個行業正在"萬物生長"。 但是我們現在還沒有馬丁福勒，adrian cockcroft這樣的架構大牛人物。我輩仍需不斷努力，期待中國10~20年後出現超過十個馬丁福勒，adrian cockcroft這樣的大牛級人物。

我們必不可停止探索，而一切探索的盡頭，就是重回起點，並對起點有首次般的認識。