大概在7~8年前，我曾經(jīng)有一個美國對口的架構(gòu)師導師斑胜，他對我講架構(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)視角
每個視角都解決并且對應到利益相關(guān)者的關(guān)注點涧狮。
架構(gòu)系統(tǒng)前，架構(gòu)師的首要任務是盡最大可能找出所有利益相關(guān)者么夫，業(yè)務方者冤，產(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è)務方（多快好手雀浴）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)始人之一。
進一步展開講馁启，架構(gòu)的目標是用于管理復雜性驾孔、易變性和不確定性，以確保在長期的系統(tǒng)演化過程中惯疙，一部分架構(gòu)的變化不會對架構(gòu)的其它部分產(chǎn)生不必要的負面影響。這樣做可以確保業(yè)務和研發(fā)效率的敏捷妖啥，讓應用的易變部分能夠頻繁地變化霉颠，對應用的其它部分的影響盡可能的小。
我剛?cè)胲浖_發(fā)這個行業(yè)之初荆虱，談的架構(gòu)主要是性能蒿偎，高可用等等。現(xiàn)在怀读，見過無數(shù)遺留系統(tǒng)诉位，特別是國內(nèi)企業(yè)IT的現(xiàn)狀，無數(shù)高耦合的遺留系統(tǒng)菜枷，不良的架構(gòu)像手銬一樣牢牢地限制住業(yè)務苍糠，升級替換成本非常巨大， 所以我更加關(guān)注可理解啤誊，可維護性岳瞭，可擴展性拥娄，成本 。我想補充一句瞳筏，創(chuàng)業(yè)公司創(chuàng)業(yè)之初獲得好的架構(gòu)師或技術(shù)CTO非常重要稚瘾。
我是屬于老一代的架構(gòu)師，99年參加工作姚炕。職業(yè)初學了很多RUP摊欠，統(tǒng)一軟件過程的理念。RUP的理念對我的架構(gòu)有很深的影響柱宦，RUP總結(jié)起來就是三個特點：
用例和風險驅(qū)動Use Case and risk driven
架構(gòu)中心Architecture centric
迭代和增量Iterative and incremental
RUP很注重架構(gòu)些椒，提倡以架構(gòu)和風險驅(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)品越晚被使用者使用搀暑，失敗的成本和風險就越高，而小步行進跨琳，通過MVP快速實驗自点，獲取客戶反饋，迭代演化產(chǎn)品脉让，能有效地減少失敗的成本和風險桂敛。
在這里順便給大家推薦一個架構(gòu)交流群：650385180，里面會分享一些資深架構(gòu)師錄制的視頻錄像：有Spring溅潜，MyBatis术唬，Netty源碼分析，高并發(fā)滚澜、高性能粗仓、分布式、微服務架構(gòu)的原理设捐，JVM性能優(yōu)化這些成為架構(gòu)師必備的知識體系借浊。還能領(lǐng)取免費的學習資源。相信對于已經(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è)務需求宛畦、研發(fā)瘸洛、測試、集成次和，到部署運維反肋，這條價值鏈的效率并不依賴于單個或者幾個環(huán)節(jié)，局部優(yōu)化的結(jié)果往往是全局受損踏施，架構(gòu)師要站在系統(tǒng)高度去優(yōu)化整個價值交付鏈石蔗，讓企業(yè)和客戶之間形成快速和高效的價值傳遞。
第二條道路畅形，強化反饋環(huán)养距，任何過程改進的目標都是加強和縮短反饋環(huán)。剛?cè)胄械墓こ處熑瞻荆彩侵袊鴮W生的普遍問題棍厌，就是生產(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)相當于裸奔，開車上高速無儀表盤怕敬。有一篇很不錯的關(guān)于測量驅(qū)動開發(fā)的文章揣炕，在InfoQ上的，向大家推薦：
http://www.infoq.com/cn/articles/metrics-driven-development
這篇文章提出了度量驅(qū)動開發(fā)的理念东跪，即所謂MDD畸陡，在系統(tǒng)，應用和業(yè)務三個層次虽填，通過三級監(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)
應用服務層兔港，監(jiān)控業(yè)務庸毫、應用、服務衫樊，甚至整個研發(fā)流程飒赃，構(gòu)建應用和服務層的反饋環(huán)
客戶體驗層利花，監(jiān)控端用戶和分析網(wǎng)站用戶的行為，構(gòu)建和客戶的反饋環(huán)
下面這個圖展示了系統(tǒng)提升和改進的一般方法：
收集->測量->調(diào)整->閉環(huán)重復载佳，在有測量數(shù)據(jù)和反饋的基礎(chǔ)上炒事，系統(tǒng)、應用蔫慧、流程和客戶體驗才有可能獲得持續(xù)的提升和改善挠乳，否則沒有數(shù)據(jù)的所謂改進只能靠拍腦袋或者說猜測。
第三條道路藕漱，鼓勵勇于承擔責任欲侮，冒險試錯和持續(xù)提升的文化。這點是最難的肋联，一般和企業(yè)人才密度有關(guān)威蕉。工具，技術(shù)橄仍，流程只是一個公司的冰山浮出水面的部分韧涨，而真正對企業(yè)效能影響大的則是冰山水下的部分，即企業(yè)的人和文化侮繁，架構(gòu)師作為技術(shù)和架構(gòu)的布道者虑粥，有責任義務鼓勵和推動試錯文化。
架構(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)師的夢想和努力的方向品抽。
微服務我想大家都聽得很多了储笑，我本人也非常關(guān)注和推崇微服務，從技術(shù)角度講圆恤，我認為微服務主要體現(xiàn)的是單一職責和關(guān)注分離的思想突倍，從單進程模塊化進一步拓展到跨進程分布式的模塊化。微服務是獨立的開發(fā)盆昙、測試羽历、部署和升級單元，正如我在第一點架構(gòu)定義中提到的淡喜，微服務中每個服務可以獨立演變窄陡，它的cost of change比較小，整體架構(gòu)比較靈活拆火，是一種支持創(chuàng)新的演化式架構(gòu)。
在這里順便給大家推薦一個架構(gòu)交流群：650385180，里面會分享一些資深架構(gòu)師錄制的視頻錄像：有Spring们镜，MyBatis币叹，Netty源碼分析，高并發(fā)模狭、高性能颈抚、分布式、微服務架構(gòu)的原理嚼鹉，JVM性能優(yōu)化這些成為架構(gòu)師必備的知識體系贩汉。還能領(lǐng)取免費的學習資源。相信對于已經(jīng)工作和遇到技術(shù)瓶頸的碼友锚赤，在這個群里會有你需要的內(nèi)容匹舞。
去年MartinFowler寫了兩篇文章，給微服務潑冷水的线脚，建議大家好好讀下赐稽。
http://martinfowler.com/bliki/MicroservicePrerequisites.html
http://martinfowler.com/bliki/MicroservicePremium.html
這個圖講什么時候該引入微服務。微服務有額外成本的浑侥，需要搭建框架姊舵、發(fā)布、監(jiān)控等基礎(chǔ)設(shè)施寓落。初創(chuàng)和小規(guī)模團隊不建議采用括丁。主要決定是因素系統(tǒng)復雜性和團隊規(guī)模，當?shù)竭_一個點伶选，單塊架構(gòu)嚴重影響效率才考慮 史飞。另外補充一點，微服務更多是關(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)到微服務架構(gòu)是這個定律的很好體現(xiàn)蚯窥。
團隊是分布式的，系統(tǒng)架構(gòu)是單塊的塞帐，開發(fā)拦赠，測試，部署協(xié)調(diào)溝通成本大葵姥，嚴重影響效率荷鼠，嚴重時團隊之間還容易起沖突。
將單塊架構(gòu)解耦成微服務榔幸，每個團隊開發(fā)允乐，測試和發(fā)布自己負責的微服務矮嫉，互不干擾，系統(tǒng)效率得到提升牍疏。
可見蠢笋，組織和系統(tǒng)架構(gòu)之間有一個映射關(guān)系（1 ~ 1 mapping），兩者不對齊就會出各種各樣的問題鳞陨，一方面昨寞，如果你的組織結(jié)構(gòu)和文化結(jié)構(gòu)不支持，你也無法成功建立高效的系統(tǒng)架構(gòu)厦滤，例如集中式和嚴格職能（業(yè)務, Dev, QA, Deployment, Ops）的企業(yè)服赎，很難推行微服務和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)師的應有心態(tài)翁脆，stay hungry, stay foolish眷蚓， 心態(tài)有多開放，視野就有多開闊反番。來自《高效能人士的七個習慣~史蒂芬~柯維》的一句話送給每一個架構(gòu)師 :
如果一位具有相當聰明才智的人跟我意見不同沙热，那么對方的主張必有我尚未體會的奧秘，值得加以了解罢缸。與人合作最重要的是篙贸，重視不同個體的不同心理、情緒與智能枫疆，以及個人眼中所見的不同世界爵川。與所見略同的人溝通，益處不大息楔，要有分歧才有收獲寝贡。
另外再推薦一個本書《軟件架構(gòu)師的12項修煉》扒披，這書中三個觀點很值得每個架構(gòu)師學習領(lǐng)會:
soft skills are always hard than hard skills，軟技能比硬技能難
choosing relationship over correctness 兔甘，注重關(guān)系重于誰對誰錯
架構(gòu)的政治性谎碍，在中大型公司里工作的架構(gòu)師尤其要學習
政治指的是和他人協(xié)作將事情搞定的藝術(shù)，架構(gòu)是一種社交活動洞焙，在技術(shù)的世界里，個人主義很容易被打敗拯啦，即使你的目的是好的技術(shù)是最優(yōu)的澡匪，技術(shù)決策是政治決策（technical decisions are political decisions），一個技術(shù)產(chǎn)品褒链，一波人可以做唁情，另一波人也可以做，到底誰做的好甫匹，真不好說甸鸟，不管誰做，都給業(yè)務套上了一副手銬兵迅。
架構(gòu)師如何提升抢韭？實戰(zhàn)，實戰(zhàn)恍箭，實戰(zhàn)刻恭！規(guī)劃職業(yè)，找好的團隊和項目扯夭，總結(jié)分享鳍贾，學習GitHub開源項目，盡可能參與和開創(chuàng)自己的開源項目和產(chǎn)品交洗，并長期積累骑科。
主要爭議是兩個話題：
技術(shù)和業(yè)務的關(guān)系。
架構(gòu)師要寫代碼嗎构拳？
架構(gòu)師怎么回答這類問題咆爽？一個成熟架構(gòu)師的口頭禪：視情況而定，不一定隐圾，是也不是伍掀，it depends。技術(shù)和業(yè)務暇藏，架構(gòu)師要理解業(yè)務嗎蜜笤？看產(chǎn)品和客戶，如果是業(yè)務性產(chǎn)品盐碱，肯定要理解業(yè)務把兔，如果是技術(shù)型產(chǎn)品沪伙，就不一定。
架構(gòu)師要寫代碼县好？也不一定围橡，個人覺得盡可能要寫，如果你寫過十年以上代碼了缕贡，每年不少于2萬行翁授，都玩通了，可以不寫晾咪。另外架構(gòu)師如果寫代碼收擦，要把控度，不要一頭鉆入代碼谍倦，花大量時間解決細節(jié)和復雜性問題塞赂，忽視全局和系統(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)，主導攜程大規(guī)模SOA體系建設(shè)笤喳，唯品會（VIPShop）为居，任資深云平臺架構(gòu)師，負責容器PaaS平臺的調(diào)研和架構(gòu)杀狡，目前就職于法國LVMH集團中國區(qū)的垂直電商部門蒙畴，任職電商首席架構(gòu)師，幫助傳統(tǒng)IT向互聯(lián)網(wǎng)轉(zhuǎn)型。
