其它 發(fā)表時間:2019/6/6 9:25:06??來源:阿里技術(shù)??作者:jixwe??
其它 發(fā)表時間:2019/6/6 9:25:06??來源:阿里技術(shù)??作者:jixwe??
為什么大部分工程師都無法成為優(yōu)秀的架構(gòu)師?做到純精通 coding, 是否能成為一流的架構(gòu)師?如果你有這樣的疑惑,就來聽聽螞蟻高級測試開發(fā)專家懿澤怎么說。今天,懿澤跳出大型互聯(lián)網(wǎng)公司技術(shù)體系,從通用角度,談談對架構(gòu)的理解,相信對想成為優(yōu)秀架構(gòu)師的同學一定會有所啟發(fā)。
依托豐富的中間件、成熟的框架,在大型互聯(lián)網(wǎng)公司做開發(fā)還是比較便捷的。一線開發(fā)要做的是持續(xù) CP(COPY、PASTE),不斷從左邊到右邊的業(yè)務適配。什么樣的架構(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è)務的變化和發(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è)務目標作出自己的判斷,并有所取舍,這一點非常重要,特別是當資源不足、進度緊張的時候,更要在關(guān)鍵時刻做決策,果斷放棄部分內(nèi)容。架構(gòu)師大多數(shù)時候都滿身污垢,能在其中保持初心,保持平衡并不容易。當日活只有個位數(shù)的時候,不要談千萬級 DAU 的架構(gòu)。
領(lǐng)域建模
在邊界清晰、耦合低、內(nèi)聚高的情況下,各種改動帶來的成本就會比較低,領(lǐng)域模型劃分盡量保證業(yè)務的高內(nèi)聚和低耦合,劃定領(lǐng)域邊界,保證一個業(yè)務邏輯盡量在一個領(lǐng)域模型內(nèi)部,領(lǐng)域模型之間盡量減少業(yè)務來往,并保證一次業(yè)務流程涉及盡可能少的領(lǐng)域模型。復雜系統(tǒng)領(lǐng)域建模能力:特別是業(yè)務域邊界劃分的問題,業(yè)務域邊界會直接決定架構(gòu)中相關(guān)系統(tǒng)的邊界,如果業(yè)務域邊界沒有整理清楚,那么系統(tǒng)邊界也會因為模糊從而帶來一系列的問題。
技術(shù)能力
技術(shù)能力是最硬核的,前面提到寫業(yè)務代碼要做的是持續(xù) CP,并不是說業(yè)務代碼沒有含金量,寫好業(yè)務代碼是最基礎(chǔ)的一步,在寫好業(yè)務代碼后,再一步一步,由淺入深,掌握設(shè)計模式、分布式、微服務化、性能優(yōu)化,逐步熟悉并了解架構(gòu)設(shè)計,然而架構(gòu)之路是艱辛的、孤獨的,注定需要付出更多。
技術(shù)能力也決定了架構(gòu)的深度:操作系統(tǒng)、編譯原理是最基礎(chǔ)的知識,不管編程語言怎么發(fā)展,這些都是最 base 的,在迷茫時沉下心來反復看。當前主流的微服務架構(gòu),服務拆分粒度難以準確把握,需要遵循高內(nèi)聚低耦合的基本原則,并清晰定義業(yè)務邊界和數(shù)據(jù)接口,特別要避免過度設(shè)計。設(shè)計模式有一個共性,就是如何讓程序設(shè)計巧妙、合理地應對未來各種大概率可能的變化,包括需求的變化,技術(shù)的變化等。docker 容器化能夠?qū)?SA 的經(jīng)驗標準化并固定下來,有別于傳統(tǒng)虛擬機,它并不去虛擬任何硬件,而是對硬件資源在不同的 docker container 之間作了隔離。智能化依托大數(shù)據(jù)和算法,在解一些特定的業(yè)務場景有效果,但不可過度,放眼望去,現(xiàn)在很多產(chǎn)品和工具無不帶著智能兩字的,手里拿個錘子,看什么都像釘子。
高可用、高性能
高可用、高性能是一個優(yōu)秀的架構(gòu)必須具備的,解決互聯(lián)網(wǎng)架構(gòu)中的高并發(fā)和高可用的問題,也是最能體現(xiàn)工匠精神的。在架構(gòu)設(shè)計之初就應該考慮容災能力、資損防控、自愈能力等。系統(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)手段(全鏈路壓測、容災演練、資損演練)發(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)化、應用大小、應用啟停速度、JVM優(yōu)化等等)、疑難問題攻關(guān)、新技術(shù)探索等。
最喜歡泛型編程與 STL,再結(jié)合設(shè)計模式,寫出來的代碼圈復雜度低,閱讀起來也特別舒服。記得當時有同學改掉了職責鏈設(shè)計模式,改回 if else 實現(xiàn)形式,我去打了一架,把代碼全部回滾回來。寫代碼容易,真正能守護好代碼,卻不容易。當時應用部署在 sun 的 Solaris 系統(tǒng)上,在分析疑難問題,發(fā)現(xiàn)學的知識還遠遠不夠,又啃了很多操作系統(tǒng)、編譯原理,匯編源代碼和 CPU 指令集...
最近幾年負責新產(chǎn)品研發(fā),也深刻地認識到技術(shù)永遠是為業(yè)務服務的,如果為了技術(shù)而技術(shù),那是自 high,牛逼的技術(shù)都是需要通過業(yè)務價值來體現(xiàn)。產(chǎn)品設(shè)計以用戶體驗貫穿始終,并依托著技術(shù)讓用戶尖叫。