為什么大部分工程師都無法成為優(yōu)秀的架構(gòu)師？做到純精通 coding， 是否能成為一流的架構(gòu)師？如果你有這樣的疑惑，就來聽聽螞蟻高級測試開發(fā)專家懿澤怎么說。今天，懿澤跳出大型互聯(lián)網(wǎng)公司技術(shù)體系，從通用角度，談?wù)剬軜?gòu)的理解，相信對想成為優(yōu)秀架構(gòu)師的同學一定會有所啟發(fā)。

依托豐富的中間件、成熟的框架，在大型互聯(lián)網(wǎng)公司做開發(fā)還是比較便捷的。一線開發(fā)要做的是持續(xù) CP（COPY、PASTE），不斷從左邊到右邊的業(yè)務(wù)適配。什么樣的架構(gòu)師才能稱得上好的架構(gòu)師呢？他至少得親自編寫 OR 維護一個上百萬行代碼的產(chǎn)品，體驗一下沒有架構(gòu)的痛苦。反復痛苦之后，才能深刻理解架構(gòu)的好處，才會有架構(gòu)意識，才能更快地提高。踩的坑多了，自然就懂得避坑了。

前瞻性

如何保持架構(gòu)3-5年的領(lǐng)先？在實際項目中，經(jīng)常見到有人把以前埋的坑填平，改個名字：XX 架構(gòu)1.0 ? XX 架構(gòu)2.0 ，就成了新架構(gòu)了。然而，只是在原本有問題的架構(gòu)上打了個補丁，架構(gòu)在本質(zhì)上并沒有變化，舊坑未平，新坑不斷。好的架構(gòu)不是設(shè)計出來的，而是演進而來的。這就要求我們對技術(shù)保持敏感，時刻關(guān)注最新的技術(shù)，時刻保持自己技術(shù)棧的先進性，配合公司中長期戰(zhàn)略，并充分考慮未來幾年業(yè)務(wù)的變化和發(fā)展。作為技術(shù)的引領(lǐng)者，就要成為導演而非演員，有一個夢想和愿景，讓大家都能自動 follow，保持情懷和信仰，并勇于創(chuàng)新。

懂產(chǎn)品

不了解產(chǎn)品的架構(gòu)師無異于閉門造車，無法產(chǎn)生實際的產(chǎn)業(yè)價值，因此，永遠不要脫離產(chǎn)品，好的架構(gòu)師要清楚地知道自己要選擇什么，做什么，放棄什么。架構(gòu)師通過業(yè)務(wù)目標作出自己的判斷，并有所取舍，這一點非常重要，特別是當資源不足、進度緊張的時候，更要在關(guān)鍵時刻做決策，果斷放棄部分內(nèi)容。架構(gòu)師大多數(shù)時候都滿身污垢，能在其中保持初心，保持平衡并不容易。當日活只有個位數(shù)的時候，不要談千萬級 DAU 的架構(gòu)。

領(lǐng)域建模

在邊界清晰、耦合低、內(nèi)聚高的情況下，各種改動帶來的成本就會比較低，領(lǐng)域模型劃分盡量保證業(yè)務(wù)的高內(nèi)聚和低耦合，劃定領(lǐng)域邊界，保證一個業(yè)務(wù)邏輯盡量在一個領(lǐng)域模型內(nèi)部，領(lǐng)域模型之間盡量減少業(yè)務(wù)來往，并保證一次業(yè)務(wù)流程涉及盡可能少的領(lǐng)域模型。復雜系統(tǒng)領(lǐng)域建模能力：特別是業(yè)務(wù)域邊界劃分的問題，業(yè)務(wù)域邊界會直接決定架構(gòu)中相關(guān)系統(tǒng)的邊界，如果業(yè)務(wù)域邊界沒有整理清楚，那么系統(tǒng)邊界也會因為模糊從而帶來一系列的問題。

技術(shù)能力

技術(shù)能力是最硬核的，前面提到寫業(yè)務(wù)代碼要做的是持續(xù) CP，并不是說業(yè)務(wù)代碼沒有含金量，寫好業(yè)務(wù)代碼是最基礎(chǔ)的一步，在寫好業(yè)務(wù)代碼后，再一步一步，由淺入深，掌握設(shè)計模式、分布式、微服務(wù)化、性能優(yōu)化，逐步熟悉并了解架構(gòu)設(shè)計，然而架構(gòu)之路是艱辛的、孤獨的，注定需要付出更多。

技術(shù)能力也決定了架構(gòu)的深度：操作系統(tǒng)、編譯原理是最基礎(chǔ)的知識，不管編程語言怎么發(fā)展，這些都是最 base 的，在迷茫時沉下心來反復看。當前主流的微服務(wù)架構(gòu)，服務(wù)拆分粒度難以準確把握，需要遵循高內(nèi)聚低耦合的基本原則，并清晰定義業(yè)務(wù)邊界和數(shù)據(jù)接口，特別要避免過度設(shè)計。設(shè)計模式有一個共性，就是如何讓程序設(shè)計巧妙、合理地應(yīng)對未來各種大概率可能的變化，包括需求的變化，技術(shù)的變化等。docker 容器化能夠?qū)?SA 的經(jīng)驗標準化并固定下來，有別于傳統(tǒng)虛擬機，它并不去虛擬任何硬件，而是對硬件資源在不同的 docker container 之間作了隔離。智能化依托大數(shù)據(jù)和算法，在解一些特定的業(yè)務(wù)場景有效果，但不可過度，放眼望去，現(xiàn)在很多產(chǎn)品和工具無不帶著智能兩字的，手里拿個錘子，看什么都像釘子。

高可用、高性能

高可用、高性能是一個優(yōu)秀的架構(gòu)必須具備的，解決互聯(lián)網(wǎng)架構(gòu)中的高并發(fā)和高可用的問題，也是最能體現(xiàn)工匠精神的。在架構(gòu)設(shè)計之初就應(yīng)該考慮容災(zāi)能力、資損防控、自愈能力等。系統(tǒng)上線前 OR 大促前，需要進行各種調(diào)優(yōu)：性能調(diào)優(yōu)、WEB 調(diào)優(yōu)、JVM 調(diào)優(yōu)、DB 調(diào)優(yōu)、強弱依賴治理等，并通過主動發(fā)現(xiàn)手段（全鏈路壓測、容災(zāi)演練、資損演練）發(fā)現(xiàn)架構(gòu) OR 設(shè)計的不合理的地方。優(yōu)秀的架構(gòu)不是設(shè)計出來的，而是不斷打磨演進而來的。

后記

在某大型通訊公司干了八年開發(fā)之后，我轉(zhuǎn)到阿里技術(shù)風險部。回想那八年，是一段饑渴的歲月，也沒有覺得有多苦，看到優(yōu)秀的設(shè)計、架構(gòu)，會整夜分析疑難問題，反復去編寫代碼，困了累了就在桌子下面的行軍床上睡覺。也在編程考試中失利，覺得自己不適合做開發(fā)，后來在導師耐心的指導下，重拾信心，信奉笨鳥先飛原則，并比以前更注重技術(shù)內(nèi)部實現(xiàn)細節(jié)，隨后在大部門（1000多人）編程競賽中拿了第二名。破土重生之后，更致力于大網(wǎng)效率、瘦身（運行時內(nèi)存優(yōu)化、堆內(nèi)存優(yōu)化、應(yīng)用大小、應(yīng)用啟停速度、JVM優(yōu)化等等）、疑難問題攻關(guān)、新技術(shù)探索等。

最喜歡泛型編程與 STL，再結(jié)合設(shè)計模式，寫出來的代碼圈復雜度低，閱讀起來也特別舒服。記得當時有同學改掉了職責鏈設(shè)計模式，改回 if else 實現(xiàn)形式，我去打了一架，把代碼全部回滾回來。寫代碼容易，真正能守護好代碼，卻不容易。當時應(yīng)用部署在 sun 的 Solaris 系統(tǒng)上，在分析疑難問題，發(fā)現(xiàn)學的知識還遠遠不夠，又啃了很多操作系統(tǒng)、編譯原理，匯編源代碼和 CPU 指令集...

最近幾年負責新產(chǎn)品研發(fā)，也深刻地認識到技術(shù)永遠是為業(yè)務(wù)服務(wù)的，如果為了技術(shù)而技術(shù)，那是自 high，牛逼的技術(shù)都是需要通過業(yè)務(wù)價值來體現(xiàn)。產(chǎn)品設(shè)計以用戶體驗貫穿始終，并依托著技術(shù)讓用戶尖叫。