大概在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)的目標是解決利益相關(guān)者的關(guān)注點。
這是從那本書里頭的一張截圖，我之前公司分享架構(gòu)定義常常用這張圖，架構(gòu)是這樣定義的：
每個系統(tǒng)都有一個架構(gòu)
架構(gòu)由架構(gòu)元素以及相互之間的關(guān)系構(gòu)成
系統(tǒng)是為了滿足利益相關(guān)者（stakeholder）的需求而構(gòu)建的
利益相關(guān)者都有自己的關(guān)注點（concerns）
架構(gòu)由架構(gòu)文檔描述
架構(gòu)文檔描述了一系列的架構(gòu)視角
每個視角都解決并且對應(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ù)方（多快好?。﹙s 技術(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)始人之一。
進一步展開講，架構(gòu)的目標是用于管理復(fù)雜性、易變性和不確定性，以確保在長期的系統(tǒng)演化過程中，一部分架構(gòu)的變化不會對架構(gòu)的其它部分產(chǎn)生不必要的負面影響。這樣做可以確保業(yè)務(wù)和研發(fā)效率的敏捷，讓應(yīng)用的易變部分能夠頻繁地變化，對應(yīng)用的其它部分的影響盡可能的小。
我剛?cè)胲浖_發(fā)這個行業(yè)之初，談的架構(gòu)主要是性能，高可用等等?，F(xiàn)在，見過無數(shù)遺留系統(tǒng)，特別是國內(nèi)企業(yè)IT的現(xiàn)狀，無數(shù)高耦合的遺留系統(tǒng)，不良的架構(gòu)像手銬一樣牢牢地限制住業(yè)務(wù)，升級替換成本非常巨大， 所以我更加關(guān)注可理解，可維護性，可擴展性，成本 。我想補充一句，創(chuàng)業(yè)公司創(chuàng)業(yè)之初獲得好的架構(gòu)師或技術(shù)CTO非常重要。
我是屬于老一代的架構(gòu)師，99年參加工作。職業(yè)初學(xué)了很多RUP，統(tǒng)一軟件過程的理念。RUP的理念對我的架構(gòu)有很深的影響，RUP總結(jié)起來就是三個特點：
用例和風(fēng)險驅(qū)動Use Case and risk driven
架構(gòu)中心Architecture centric
迭代和增量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)而后丟給團隊的作法非常不靠譜（除非是已經(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)險就越高，而小步行進，通過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)影響最深的一篇文章。這篇文章是關(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)，任何過程改進的目標都是加強和縮短反饋環(huán)。剛?cè)胄械墓こ處煟彩侵袊鴮W(xué)生的普遍問題，就是生產(chǎn)運維意識不足（監(jiān)控是系統(tǒng)反饋的重要環(huán)節(jié)）。有兩句話是這樣講的：
no measurement, no improvement沒有測量，就沒有改進和提升
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ù)改進系統(tǒng)和架構(gòu)，我最近也在參考這個理念設(shè)計一個電商平臺的技術(shù)架構(gòu)，見下圖：
這是一個電商平臺的架構(gòu)，整個體現(xiàn)了閉環(huán)架構(gòu)的思想，右側(cè)是整個平臺的反饋監(jiān)控環(huán)節(jié)。具體如下：
系統(tǒng)層監(jiān)控計算網(wǎng)絡(luò)存儲，構(gòu)建系統(tǒng)層的反饋環(huán)
應(yīng)用服務(wù)層，監(jiān)控業(yè)務(wù)、應(yīng)用、服務(wù)，甚至整個研發(fā)流程，構(gòu)建應(yīng)用和服務(wù)層的反饋環(huán)
客戶體驗層，監(jiān)控端用戶和分析網(wǎng)站用戶的行為，構(gòu)建和客戶的反饋環(huán)
下面這個圖展示了系統(tǒng)提升和改進的一般方法：
收集->測量->調(diào)整->閉環(huán)重復(fù)，在有測量數(shù)據(jù)和反饋的基礎(chǔ)上，系統(tǒng)、應(yīng)用、流程和客戶體驗才有可能獲得持續(xù)的提升和改善，否則沒有數(shù)據(jù)的所謂改進只能靠拍腦袋或者說猜測。
第三條道路，鼓勵勇于承擔(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ù)我想大家都聽得很多了，我本人也非常關(guān)注和推崇微服務(wù)，從技術(shù)角度講，我認為微服務(wù)主要體現(xiàn)的是單一職責(zé)和關(guā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ù)潑冷水的，建議大家好好讀下。
http://martinfowler.com/bliki/MicroservicePrerequisites.html
http://martinfowler.com/bliki/MicroservicePremium.html
這個圖講什么時候該引入微服務(wù)。微服務(wù)有額外成本的，需要搭建框架、發(fā)布、監(jiān)控等基礎(chǔ)設(shè)施。初創(chuàng)和小規(guī)模團隊不建議采用。主要決定是因素系統(tǒng)復(fù)雜性和團隊規(guī)模，當(dāng)?shù)竭_一個點，單塊架構(gòu)嚴重影響效率才考慮 。另外補充一點，微服務(wù)更多是關(guān)于組織和團隊，而不是技術(shù)。
再談一下康威定律：
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)。
團隊是分布式的，系統(tǒng)架構(gòu)是單塊的，開發(fā)，測試，部署協(xié)調(diào)溝通成本大，嚴重影響效率，嚴重時團隊之間還容易起沖突。
將單塊架構(gòu)解耦成微服務(wù)，每個團隊開發(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è)務(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)。
空杯，或者說開放心態(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)會:
soft skills are always hard than hard skills，軟技能比硬技能難
choosing relationship over correctness ，注重關(guān)系重于誰對誰錯
架構(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è)，找好的團隊和項目，總結(jié)分享，學(xué)習(xí)GitHub開源項目，盡可能參與和開創(chuàng)自己的開源項目和產(chǎn)品，并長期積累。
主要爭議是兩個話題：
技術(shù)和業(yè)務(wù)的關(guān)系。
架構(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)師如果寫代碼，要把控度，不要一頭鉆入代碼，花大量時間解決細節(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這樣的大牛神級人物。我們必不可停止探索，而一切探索的盡頭，就是重回起點，并對起點有首次般的認識。
具有超過10年的互聯(lián)網(wǎng)分布式系統(tǒng)研發(fā)和架構(gòu)經(jīng)驗，曾先后就職于：eBay中國研發(fā)中心（eBay CDC），任資深研發(fā)工程師，參與億貝開放API平臺研發(fā)，攜程旅游網(wǎng)（Ctrip），任技術(shù)研發(fā)總監(jiān)，主導(dǎo)攜程大規(guī)模SOA體系建設(shè)，唯品會（VIPShop），任資深云平臺架構(gòu)師，負責(zé)容器PaaS平臺的調(diào)研和架構(gòu)，目前就職于法國LVMH集團中國區(qū)的垂直電商部門，任職電商首席架構(gòu)師，幫助傳統(tǒng)IT向互聯(lián)網(wǎng)轉(zhuǎn)型。
