背景

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

1. 我對(duì)架構(gòu)定義的理解
2. 架構(gòu)的迭代和演化性
3. 構(gòu)建閉環(huán)反饋架構(gòu)（Architecting for closed loop feedback）
4. 談?wù)勎⒎?wù)架構(gòu)和最新主題
5. 架構(gòu)和組織文化關(guān)系
6. 架構(gòu)師心態(tài)和軟技能
7. 我對(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），后來我讀到一本書《軟件系統(tǒng)架構(gòu):使用視點(diǎn)和視角與利益相關(guān)者合作》，里面提到的理念也是這樣說：系統(tǒng)架構(gòu)的目標(biāo)是解決利益相關(guān)者的關(guān)注點(diǎn)。

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

1. 每個(gè)系統(tǒng)都有一個(gè)架構(gòu)
2. 架構(gòu)由架構(gòu)元素以及相互之間的關(guān)系構(gòu)成
3. 系統(tǒng)是為了滿足利益相關(guān)者（stakeholder）的需求要構(gòu)建的
4. 利益相關(guān)者都有自己的關(guān)注點(diǎn)（concerns）
5. 架構(gòu)由架構(gòu)文檔描述
6. 架構(gòu)文檔描述了一系列的架構(gòu)視角
7. 每個(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)理，客戶/用戶，開發(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)定義是說架構(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)鍵性可以由變化的成本來決定。這句話是Grady Booch說的，他是UML的創(chuàng)始人之一。

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

我剛?cè)胲浖_發(fā)這個(gè)行業(yè)之出，談的架構(gòu)主要是性能，高可用等等?，F(xiàn)在，見過無數(shù)遺留系統(tǒng)，特別是國(guó)內(nèi)企業(yè)IT的現(xiàn)狀，無數(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)一軟件過程的理念。RUP的理念對(duì)我的架構(gòu)有很深的影響，RUP總結(jié)起來就是三個(gè)特點(diǎn)：

1. 用例和風(fēng)險(xiǎn)驅(qū)動(dòng)Use Case and risk driven
2. 架構(gòu)中心Architecture centric
3. 迭代和增量Iterative and incremental

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

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

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

另外，多年的經(jīng)驗(yàn)告訴我，架構(gòu)，平臺(tái)不是買來的，也不是用一個(gè)開源就能獲得的，也不是設(shè)計(jì)出來，而是長(zhǎng)期演化才能落地生根的

給大家推薦兩篇不錯(cuò)的微信文章（微信不能插入鏈接，根據(jù)題目google下即可）：

1. 58同城沈劍：好的架構(gòu)源于不停地衍變，而非設(shè)計(jì)
2. 宜人貸系統(tǒng)架構(gòu)–高并發(fā)下的進(jìn)化之路

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

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

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

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

1. no measurement, no improvement沒有測(cè)量，就沒有改進(jìn)和提升
2. What your measure is what you get你測(cè)量什么，就得到什么

沒有監(jiān)控或者監(jiān)控不完善的系統(tǒng)相當(dāng)于裸奔，開車上高速無儀表盤。

這篇文章提出了度量驅(qū)動(dòng)開發(fā)的理念，即所謂MDD，在系統(tǒng)，應(yīng)用和業(yè)務(wù)，通過三級(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)，見下圖：

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

1. 系統(tǒng)層監(jiān)控計(jì)算網(wǎng)絡(luò)存儲(chǔ)，構(gòu)建系統(tǒng)層的反饋環(huán)
2. 應(yīng)用服務(wù)層，監(jiān)控業(yè)務(wù)、應(yīng)用、服務(wù)，甚至整個(gè)研發(fā)流程，構(gòu)建應(yīng)用和服務(wù)層的反饋環(huán)
3. 客戶體驗(yàn)層，監(jiān)控端用戶和分析網(wǎng)站用戶的行為，構(gòu)建和客戶的反饋環(huán)

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

收集->測(cè)量->調(diào)整->閉環(huán)重復(fù)，在有測(cè)量數(shù)據(jù)和反饋的基礎(chǔ)上，系統(tǒng)、應(yīng)用、流程和客戶體驗(yàn)才有可能獲得持續(xù)的提升和改善，否則沒有數(shù)據(jù)的所謂改進(jìn)只能靠拍腦袋或者說猜測(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ù)我想大家都聽得很多了，我本人也非常關(guān)注和推崇微服務(wù)，從技術(shù)角度講，我認(rèn)為微服務(wù)主要體現(xiàn)的是單一職責(zé)和關(guān)注分離的思想，從單進(jìn)程模塊化進(jìn)一步拓展到跨進(jìn)程分布式的模塊化。微服務(wù)是獨(dú)立的開發(fā)、測(cè)試、部署和升級(jí)單元，正如我在第一點(diǎn)架構(gòu)定義中提到的，微服務(wù)中每個(gè)服務(wù)可以獨(dú)立演變，它的cost of change比較小，整體架構(gòu)比較靈活，是一種支持創(chuàng)新的演化式架構(gòu)。

這個(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)是單塊的，開發(fā)，測(cè)試，部署協(xié)調(diào)溝通成本大，嚴(yán)重影響效率，嚴(yán)重時(shí)團(tuán)隊(duì)之間還容易起沖突conflict。

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

可見，組織和系統(tǒng)架構(gòu)之間有一個(gè)映射關(guān)系（1 ~ 1 mApping），兩者不對(duì)齊就會(huì)出各種各樣的問題，一方面，如果你的組織結(jié)構(gòu)和文化結(jié)構(gòu)不支持，你也無法成功建立高效的系統(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），無法形成有效和合作和閉環(huán)。

反過來也是成立的，如果你的系統(tǒng)設(shè)計(jì)或者架構(gòu)不支持，那么你就無法成功建立一個(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)和軟技能

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

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

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

1. soft skills are always hard than hard skills，軟技能比硬技能難
2. choosing relationship over correctness ，注重關(guān)系重于誰對(duì)誰錯(cuò)
3. 架構(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)品，一波人可以做，另一波人也可以做，到底誰做的好，真不好說，不管誰做，都給業(yè)務(wù)套上了一副手銬。

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

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

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

1. 技術(shù)和業(yè)務(wù)的關(guān)系。
2. 架構(gòu)師要寫代碼嗎？

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

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

最后

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

原文作者介紹

楊波，具有超過10年的互聯(lián)網(wǎng)分布式系統(tǒng)研發(fā)和架構(gòu)經(jīng)驗(yàn)，曾先后就職于：eBay中國(guó)研發(fā)中心（eBay CDC），任資深研發(fā)工程師，參與億貝開放API平臺(tái)研發(fā)，攜程旅游網(wǎng)（Ctrip），任技術(shù)研發(fā)總監(jiān)，主導(dǎo)攜程大規(guī)模SOA體系建設(shè)，唯品會(huì)（VIPShop），任資深云平臺(tái)架構(gòu)師，負(fù)責(zé)容器PaaS平臺(tái)的調(diào)研和架構(gòu)，目前就職于法國(guó)LVMH集團(tuán)中國(guó)區(qū)的垂直電商部門，任職電商首席架構(gòu)師，幫助傳統(tǒng)IT向互聯(lián)網(wǎng)轉(zhuǎn)型。

感謝能閱讀完，覺得還不錯(cuò)的可以轉(zhuǎn)發(fā)關(guān)注一波~是對(duì)我最大的支持：私信回復(fù)“架構(gòu)”本人整理的JAVA高級(jí)架構(gòu)資料、源碼、筆記、視頻、BATJ面試視頻資料