為什么大部分工程師都無法成為優(yōu)秀的架構(gòu)師?做到純精通 Coding， 是否能成為***的架構(gòu)師?如果你有這樣的疑惑，就來聽聽螞蟻高級測試開發(fā)專家懿澤怎么說。

[[269236]]

圖片來自包圖網(wǎng)

今天，懿澤跳出大型互聯(lián)網(wǎng)公司技術(shù)體系，從通用角度，談?wù)剬軜?gòu)的理解，相信對想成為優(yōu)秀架構(gòu)師的同學(xué)一定會有所啟發(fā)。

依托豐富的中間件、成熟的框架，在大型互聯(lián)網(wǎng)公司做開發(fā)還是比較便捷的。

一線開發(fā)要做的是持續(xù) CP(COPY、PASTE)，不斷從左邊到右邊的業(yè)務(wù)適配。

什么樣的架構(gòu)師才能稱得上好的架構(gòu)師呢?他至少得親自編寫 OR 維護(hù)一個上百萬行代碼的產(chǎn)品，體驗一下沒有架構(gòu)的痛苦。

反復(fù)痛苦之后，才能深刻理解架構(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è)計出來的，而是演進(jìn)而來的。這就要求我們對技術(shù)保持敏感，時刻關(guān)注***的技術(shù)，時刻保持自己技術(shù)棧的先進(jìn)性，配合公司中長期戰(zhàn)略，并充分考慮未來幾年業(yè)務(wù)的變化和發(fā)展。

作為技術(shù)的***者，就要成為導(dǎo)演而非演員，有一個夢想和愿景，讓大家都能自動 Follow，保持情懷和信仰，并勇于創(chuàng)新。

懂產(chǎn)品

不了解產(chǎn)品的架構(gòu)師無異于閉門造車，無法產(chǎn)生實際的產(chǎn)業(yè)價值，因此，永遠(yuǎn)不要脫離產(chǎn)品，好的架構(gòu)師要清楚地知道自己要選擇什么，做什么，放棄什么。

架構(gòu)師通過業(yè)務(wù)目標(biāo)作出自己的判斷，并有所取舍，這一點非常重要，特別是當(dāng)資源不足、進(jìn)度緊張的時候，更要在關(guān)鍵時刻做決策，果斷放棄部分內(nèi)容。

架構(gòu)師大多數(shù)時候都滿身污垢，能在其中保持初心，保持平衡并不容易。當(dāng)日活只有個位數(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)域模型。

復(fù)雜系統(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 的，在迷茫時沉下心來反復(fù)看。

當(dāng)前主流的微服務(wù)架構(gòu)，服務(wù)拆分粒度難以準(zhǔn)確把握，需要遵循高內(nèi)聚低耦合的基本原則，并清晰定義業(yè)務(wù)邊界和數(shù)據(jù)接口，特別要避免過度設(shè)計。

設(shè)計模式有一個共性，就是如何讓程序設(shè)計巧妙、合理地應(yīng)對未來各種大概率可能的變化，包括需求的變化，技術(shù)的變化等。

Docker 容器化能夠?qū)?SA 的經(jīng)驗標(biāo)準(zhǔn)化并固定下來，有別于傳統(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 大促前，需要進(jìn)行各種調(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è)計出來的，而是不斷打磨演進(jìn)而來的。

后記

在某大型通訊公司干了八年開發(fā)之后，我轉(zhuǎn)到阿里技術(shù)風(fēng)險部。

回想那八年，是一段饑渴的歲月，也沒有覺得有多苦，看到優(yōu)秀的設(shè)計、架構(gòu)，會整夜分析疑難問題，反復(fù)去編寫代碼，困了累了就在桌子下面的行軍床上睡覺。

也在編程考試中失利，覺得自己不適合做開發(fā)，后來在導(dǎo)師耐心的指導(dǎo)下，重拾信心，信奉笨鳥先飛原則，并比以前更注重技術(shù)內(nèi)部實現(xiàn)細(xì)節(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è)計模式，寫出來的代碼圈復(fù)雜度低，閱讀起來也特別舒服。

記得當(dāng)時有同學(xué)改掉了職責(zé)鏈設(shè)計模式，改回 if else 實現(xiàn)形式，我去打了一架，把代碼全部回滾回來。

寫代碼容易，真正能守護(hù)好代碼，卻不容易。當(dāng)時應(yīng)用部署在 Sun 的 Solaris 系統(tǒng)上，在分析疑難問題時，發(fā)現(xiàn)學(xué)的知識還遠(yuǎn)遠(yuǎn)不夠，又啃了很多操作系統(tǒng)、編譯原理，匯編源代碼和 CPU 指令集...

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