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

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

前瞻性

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

懂產(chǎn)品

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

領(lǐng)域建模

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

技術(shù)能力

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

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

高可用、高性能

高可用、高性能是一個(gè)優(yōu)秀的架構(gòu)必須具備的，解決互聯(lián)網(wǎng)架構(gòu)中的高并發(fā)和高可用的問題，也是最能體現(xiàn)工匠精神的。在架構(gòu)設(shè)計(jì)之初就應(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)、強(qiáng)弱依賴治理等，并通過主動(dòng)發(fā)現(xiàn)手段(全鏈路壓測(cè)、容災(zāi)演練、資損演練)發(fā)現(xiàn)架構(gòu) OR 設(shè)計(jì)的不合理的地方。優(yōu)秀的架構(gòu)不是設(shè)計(jì)出來的，而是不斷打磨演進(jìn)而來的。

后記

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

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

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

【本文為51CTO專欄作者“阿里巴巴官方技術(shù)”原創(chuàng)稿件，轉(zhuǎn)載請(qǐng)聯(lián)系原作者】

??戳這里，看該作者更多好文??