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

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

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

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

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

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

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

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

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

7.每個視角都解決并且對應(yīng)到利益相關(guān)者的關(guān)注點恤左。

架構(gòu)系統(tǒng)前贴唇，架構(gòu)師的首要任務(wù)是盡最大可能找出所有利益相關(guān)者，業(yè)務(wù)方飞袋，產(chǎn)品經(jīng)理戳气，客戶/用戶，開發(fā)經(jīng)理巧鸭，工程師瓶您，項目經(jīng)理，測試人員纲仍，運維人員呀袱，產(chǎn)品運營人員等等都有可能是利益相關(guān)者，架構(gòu)師要充分和利益相關(guān)者溝通巷折，深入理解他們的關(guān)注點和痛點压鉴，并出架構(gòu)解決這些關(guān)注點崖咨。

架構(gòu)師常犯錯誤是漏掉重要的利益相關(guān)者锻拘，溝通不充分，都會造成架構(gòu)有欠缺击蹲，不能滿足利益相關(guān)者的需求署拟。利益相關(guān)者的關(guān)注點是有可能沖突的，比如管理層（可管理性）vs技術(shù)方（性能）歌豺，業(yè)務(wù)方（多快好释魄睢）vs 技術(shù)方（可靠穩(wěn)定），這需要架構(gòu)師去靈活平衡类咧，如何平衡體現(xiàn)了架構(gòu)師的水平和價值馒铃。

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

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

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

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

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

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

我剛?cè)胲浖_發(fā)這個行業(yè)之初，談的架構(gòu)主要是性能盏求，高可用等等《蹲叮現(xiàn)在，見過無數(shù)遺留系統(tǒng)碎罚，特別是國內(nèi)企業(yè)IT的現(xiàn)狀磅废，無數(shù)高耦合的遺留系統(tǒng)，不良的架構(gòu)像手銬一樣牢牢地限制住業(yè)務(wù)荆烈，升級替換成本非常巨大拯勉， 所以我更加關(guān)注可理解，可維護(hù)性憔购，可擴展性宫峦，成本 。我想補充一句玫鸟，創(chuàng)業(yè)公司創(chuàng)業(yè)之初獲得好的架構(gòu)師或技術(shù)CTO非常重要导绷。

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

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

1.用例和風(fēng)險驅(qū)動Use Case and risk driven

2.架構(gòu)中心Architecture centric

3.迭代和增量Iterative and incremental

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

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

第一個圖是講最小可用產(chǎn)品（Minimum Viable Product九孩， MVP）理念，做出最小可用產(chǎn)品发框，盡快丟給用戶試用躺彬，快速獲取客戶反饋，在此基礎(chǔ)上不斷迭代和演化架構(gòu)和產(chǎn)品梅惯。

第二個圖是過度工程（Over Engineering）的問題宪拥，其實也是講產(chǎn)品架構(gòu)和用戶之間沒有形成有效的反饋閉環(huán)，架構(gòu)師想的和客戶想的不在一個方向上铣减，通過最小可用產(chǎn)品她君，快速迭代反饋的策略，可以避免這種問題葫哗。

注意缔刹，在系統(tǒng)真正地投入生產(chǎn)使用之前，再好的架構(gòu)都只是假設(shè)魄梯，產(chǎn)品越晚被使用者使用桨螺，失敗的成本和風(fēng)險就越高宾符，而小步行進(jìn)酿秸，通過MVP快速實驗，獲取客戶反饋魏烫，迭代演化產(chǎn)品辣苏，能有效地減少失敗的成本和風(fēng)險。

在這里順便給大家推薦一個架構(gòu)交流群：650385180哄褒，里面會分享一些資深架構(gòu)師錄制的視頻錄像：有Spring稀蟋，MyBatis，Netty源碼分析呐赡，高并發(fā)退客、高性能、分布式、微服務(wù)架構(gòu)的原理萌狂，JVM性能優(yōu)化這些成為架構(gòu)師必備的知識體系档玻。還能領(lǐng)取免費的學(xué)習(xí)資源。相信對于已經(jīng)工作和遇到技術(shù)瓶頸的碼友茫藏，在這個群里會有你需要的內(nèi)容误趴。

另外，多年的經(jīng)驗告訴我务傲，架構(gòu)凉当，平臺不是買來的，也不是用一個開源就能獲得的售葡，也不是設(shè)計出來看杭，而是長期演化才能落地生根的。

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

先分享一個鏈接挟伙，這幾年對我架構(gòu)影響最深的一篇文章泊窘。這篇文章是關(guān)于DevOps的，但對系統(tǒng)架構(gòu)同樣適用：

http://itrevolution.com /the- three- ways- principles- underpinning- devops/

這篇文章講述了企業(yè)通向DevOps的三條必經(jīng)之路像寒，我們來看看這三條道路對架構(gòu)師的啟示烘豹。

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

第二條道路悬嗓，強化反饋環(huán)污呼，任何過程改進(jìn)的目標(biāo)都是加強和縮短反饋環(huán)。剛?cè)胄械墓こ處煱瘢彩侵袊鴮W(xué)生的普遍問題燕酷，就是生產(chǎn)運維意識不足（監(jiān)控是系統(tǒng)反饋的重要環(huán)節(jié)）籍凝。有兩句話是這樣講的：

1.no measurement, no improvement沒有測量，就沒有改進(jìn)和提升

2.What your measure is what you get你測量什么苗缩，就得到什么

沒有監(jiān)控或者監(jiān)控不完善的系統(tǒng)相當(dāng)于裸奔静浴，開車上高速無儀表盤。有一篇很不錯的關(guān)于測量驅(qū)動開發(fā)的文章挤渐，在InfoQ上的苹享，向大家推薦：

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

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

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

1.系統(tǒng)層監(jiān)控計算網(wǎng)絡(luò)存儲蝌蹂，構(gòu)建系統(tǒng)層的反饋環(huán)

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

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

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

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

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

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

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

微服務(wù)我想大家都聽得很多了谋作，我本人也非常關(guān)注和推崇微服務(wù)，從技術(shù)角度講乎芳，我認(rèn)為微服務(wù)主要體現(xiàn)的是單一職責(zé)和關(guān)注分離的思想遵蚜，從單進(jìn)程模塊化進(jìn)一步拓展到跨進(jìn)程分布式的模塊化。微服務(wù)是獨立的開發(fā)奈惑、測試吭净、部署和升級單元，正如我在第一點架構(gòu)定義中提到的肴甸，微服務(wù)中每個服務(wù)可以獨立演變攒钳，它的cost of change比較小，整體架構(gòu)比較靈活雷滋，是一種支持創(chuàng)新的演化式架構(gòu)不撑。

在這里順便給大家推薦一個架構(gòu)交流群：650385180，里面會分享一些資深架構(gòu)師錄制的視頻錄像：有Spring晤斩，MyBatis焕檬，Netty源碼分析，高并發(fā)澳泵、高性能实愚、分布式、微服務(wù)架構(gòu)的原理兔辅，JVM性能優(yōu)化這些成為架構(gòu)師必備的知識體系腊敲。還能領(lǐng)取免費的學(xué)習(xí)資源。相信對于已經(jīng)工作和遇到技術(shù)瓶頸的碼友维苔，在這個群里會有你需要的內(nèi)容碰辅。

去年MartinFowler寫了兩篇文章，給微服務(wù)潑冷水的介时，建議大家好好讀下没宾。

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

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

這個圖講什么時候該引入微服務(wù)凌彬。微服務(wù)有額外成本的，需要搭建框架循衰、發(fā)布铲敛、監(jiān)控等基礎(chǔ)設(shè)施。初創(chuàng)和小規(guī)模團(tuán)隊不建議采用会钝。主要決定是因素系統(tǒng)復(fù)雜性和團(tuán)隊規(guī)模伐蒋，當(dāng)?shù)竭_(dá)一個點，單塊架構(gòu)嚴(yán)重影響效率才考慮 迁酸。另外補充一點先鱼，微服務(wù)更多是關(guān)于組織和團(tuán)隊，而不是技術(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è)計系統(tǒng)的組織型型，其產(chǎn)生的設(shè)計和架構(gòu)等價于組織間的溝通結(jié)構(gòu)。 )

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

團(tuán)隊是分布式的闹蒜，系統(tǒng)架構(gòu)是單塊的，開發(fā)抑淫，測試绷落，部署協(xié)調(diào)溝通成本大，嚴(yán)重影響效率始苇，嚴(yán)重時團(tuán)隊之間還容易起沖突砌烁。

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

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

反過來也是成立的晶框，如果你的系統(tǒng)設(shè)計或者架構(gòu)不支持排抬，那么你就無法成功建立一個有效的組織懂从；作為系統(tǒng)架構(gòu)師授段，一定要深入領(lǐng)會康威定律蹲蒲，設(shè)計系統(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òu)師的應(yīng)有心態(tài)表锻，stay hungry, stay foolish， 心態(tài)有多開放乞娄，視野就有多開闊瞬逊。來自《高效能人士的七個習(xí)慣~史蒂芬~柯維》的一句話送給每一個架構(gòu)師 :

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

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

1.soft skills are always hard than hard skills采呐，軟技能比硬技能難

2.choosing relationship over correctness ，注重關(guān)系重于誰對誰錯

3.架構(gòu)的政治性昔汉，在中大型公司里工作的架構(gòu)師尤其要學(xué)習(xí)

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

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

我對一些架構(gòu)師爭議主題的看法

主要爭議是兩個話題：

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

2.架構(gòu)師要寫代碼嗎怀挠？

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

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

最后

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