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

[[269236]]

圖片來自包圖網

今天，懿澤跳出大型互聯網公司技術體系，從通用角度，談談對架構的理解，相信對想成為優秀架構師的同學一定會有所啟發。

依托豐富的中間件、成熟的框架，在大型互聯網公司做開發還是比較便捷的。

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

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

反復痛苦之后，才能深刻理解架構的好處，才會有架構意識，才能更快地提高。踩的坑多了，自然就懂得避坑了。

前瞻性

如何保持架構 3-5 年的領先?在實際項目中，經常見到有人把以前埋的坑填平，改個名字：XX 架構 1.0 ➝ XX 架構 2.0 ，就成了新架構了。

然而，只是在原本有問題的架構上打了個補丁，架構在本質上并沒有變化，舊坑未平，新坑不斷。

好的架構不是設計出來的，而是演進而來的。這就要求我們對技術保持敏感，時刻關注***的技術，時刻保持自己技術棧的先進性，配合公司中長期戰略，并充分考慮未來幾年業務的變化和發展。

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

懂產品

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

架構師通過業務目標作出自己的判斷，并有所取舍，這一點非常重要，特別是當資源不足、進度緊張的時候，更要在關鍵時刻做決策，果斷放棄部分內容。

架構師大多數時候都滿身污垢，能在其中保持初心，保持平衡并不容易。當日活只有個位數的時候，不要談*** DAU 的架構。

領域建模

在邊界清晰、耦合低、內聚高的情況下，各種改動帶來的成本就會比較低，領域模型劃分盡量保證業務的高內聚和低耦合，劃定領域邊界，保證一個業務邏輯盡量在一個領域模型內部。

領域模型之間盡量減少業務來往，并保證一次業務流程涉及盡可能少的領域模型。

復雜系統領域建模能力：特別是業務域邊界劃分的問題，業務域邊界會直接決定架構中相關系統的邊界，如果業務域邊界沒有整理清楚，那么系統邊界也會因為模糊從而帶來一系列的問題。

技術能力

技術能力是最硬核的，前面提到寫業務代碼要做的是持續 CP，并不是說業務代碼沒有含金量，寫好業務代碼是最基礎的一步。

在寫好業務代碼后，再一步一步，由淺入深，掌握設計模式、分布式、微服務化、性能優化，逐步熟悉并了解架構設計，然而架構之路是艱辛的、孤獨的，注定需要付出更多。

技術能力也決定了架構的深度：操作系統、編譯原理是最基礎的知識，不管編程語言怎么發展，這些都是最 Base 的，在迷茫時沉下心來反復看。

當前主流的微服務架構，服務拆分粒度難以準確把握，需要遵循高內聚低耦合的基本原則，并清晰定義業務邊界和數據接口，特別要避免過度設計。

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

Docker 容器化能夠將 SA 的經驗標準化并固定下來，有別于傳統虛擬機，它并不去虛擬任何硬件，而是對硬件資源在不同的 Docker Container 之間作了隔離。

智能化依托大數據和算法，在解一些特定的業務場景時有效果，但不可過度，放眼望去，現在很多產品和工具無不帶著智能兩字的，手里拿個錘子，看什么都像釘子。

高可用、高性能

高可用、高性能是一個優秀的架構必須具備的，解決互聯網架構中的高并發和高可用的問題，也是最能體現工匠精神的。

在架構設計之初就應該考慮容災能力、資損防控、自愈能力等。系統上線前 OR 大促前，需要進行各種調優：性能調優、Web 調優、JVM 調優、DB 調優、強弱依賴治理等。

并通過主動發現手段(全鏈路壓測、容災演練、資損演練)發現架構 OR 設計的不合理的地方。

優秀的架構不是設計出來的，而是不斷打磨演進而來的。

后記

在某大型通訊公司干了八年開發之后，我轉到阿里技術風險部。

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

也在編程考試中失利，覺得自己不適合做開發，后來在導師耐心的指導下，重拾信心，信奉笨鳥先飛原則，并比以前更注重技術內部實現細節，隨后在大部門(1000 多人)編程競賽中拿了第二名。

破土重生之后，更致力于大網效率、瘦身(運行時內存優化、堆內存優化、應用大小、應用啟停速度、JVM 優化等等)、疑難問題攻關、新技術探索等。

最喜歡泛型編程與 STL，再結合設計模式，寫出來的代碼圈復雜度低，閱讀起來也特別舒服。

記得當時有同學改掉了職責鏈設計模式，改回 if else 實現形式，我去打了一架，把代碼全部回滾回來。

寫代碼容易，真正能守護好代碼，卻不容易。當時應用部署在 Sun 的 Solaris 系統上，在分析疑難問題時，發現學的知識還遠遠不夠，又啃了很多操作系統、編譯原理，匯編源代碼和 CPU 指令集...

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