點選上方“芋道原始碼”,選擇“置頂公眾號”
技術文章第一時間送達!
原始碼精品專欄
序
停了很久,繼續上路。計劃寫一個系列,先預告:《如何成為架構師》,《如何做一名好開發》,《如何做系分》,《如何轉型技術管理》。
正文
拿破侖說
不想當將軍計程車兵不是好士兵。
類比到IT行業
不想當架構師的程式員不是好程式員。
雖然此種類比不一定恰當。也許你就想簡簡單單、安安靜靜寫寫程式碼,這種想法沒錯。國外,就有很多老程式員,與世無爭的寫程式碼,把程式碼寫漂亮,沒有那麼功利非要給自己掛一個架構師的頭銜。相比較而言,國內就要現實太多。工作N多年後,如果還是在一線碼農,多數時候也會被鄙視,也許還會被BOSS扣上此人發展潛力不行。還有N多人,換工作的時候,非架構師職位不來。
年前和團隊人開會,有個同事的給他的定位是漸漸可以做更多架構規劃相關的工作。他說,對於如何做架構還有很多迷茫。有些人也許不會選著這條路;有些人正在這條路上,但是很迷茫:我該如何成為一個架構師呢?
視野
記得有個架構師講過
“視野決定格局”
自己還是比較認同這句話,架構師首先要重構的是自己的視野。視野不是裝逼。視野可以作為一個看問題、積累專業領域知識的內在驅動力。
僅僅說視野,未免太虛,如何把視野坐實是很重要。由內在(思維、心態、方法)驅動外在(專業知識)是需要扎扎實實去積澱。
常常聽到這樣的觀點
“做架構師,一定要有全域性的視野或關註”
如何理解全域性?負責幾百個應用就是全域性?負責單個系統就不是全域性?
個人對全域性有如下理解:
-
單點、模組、鏈路
由點到面去積累知識,從全域性和細節兩條路逼近學習;不僅僅關註自我,還超越自我。要做一個架構師,不僅僅需要知道自己能做什麼,還需要知道別人能做什麼,還需要自己不能做什麼。所以要做好,需要超越自我,積累更為全域性的知識,首先是你的上游需要理解,進一步是上游的上游需要瞭解。
-
過去、現在、未來
從過去看為什麼來;從現在看缺什麼;從未來來看走向哪裡。架構師需要看的更遠,比如半年,一年,三年。預知未來的能力。
-
抽象歸納
從全域性、多樣性資訊中去抽象歸納。案例推演越多,越能找到本質,更能經得住推敲。分離關註點,識別關鍵內容。
視野會決定你獲取資訊的寬度和廣度。
假比架構師負責的系統是一個圈,架構師的的視野,不僅僅是站在圈內看圈內,還要站在圈內看圈外。進一步,還可以站在圈外看圈內。進一步,你還可以飛起來,鳥瞰。
架構方法論
對於架構相關的工作不是無方法可循,相反對於企業級架構是有一整套方法論。
1、企業級建模方法ArchiMate
沒有聽過的可以自行搜尋檢視。
業務架構、應用架構、技術架構、資訊架構是常見的劃分視角。技術為業務服務,技術驅動業務。
不同層次/定位的架構師的關註點會有不同:
業務架構對接業務願景,業務架構師不一定需要完全懂技術,或者有很強的技術能力。 如果是強業務型平臺,這類平臺一般會直接面對業務場景,業務分析、建模能力需要更強;共享型平臺,這類平臺一般在各個業務平臺的下層,提供統一的業務支撐和高可用的服務支撐,此類架構師,既需要領域建模,有需要很強的技術能力,一般沒有技術功底的PD也很難規劃、掌控此類平臺;技術型平臺,諸如基礎技術平臺、中介軟體等架構師,需要對技術的深入度,對於技術棧的深度和廣度需要很高的要求,此類架構師對於業務的理解可能不會太強,而且此類架構師可能不喜歡關註業務。
應用架構對標業務架構,應用架構支撐業務架構。兩者關係是相互促進迴圈。應用架構師考慮如何基於當前的技術架構,對業務架構提出的業務模型進行系統支撐。
技術架構是企業的基礎技術棧。訊息中介軟體,服務框架等等都可以納入這一體系。技術架構不是一味的堆砌高大上的概念。業務發展/願景,應用架構遇到的問題會驅動技術架構完善;技術架構的擴充套件能力確保能快速支撐業務爆發增長(比如億級訪問量),或者業務複雜度(比如服務框架或者分散式事務框架)。
資訊架構最難,此部分最容易忽略,最容易被取捨。如果要建立完全的資訊架構也比較困難,第一個困難就是建設成本太高,第二就是可能當前解決還想不清楚,比如業務領域的變化性很大,在模糊階段建立資訊標準存在悖論。一般前期需要業務先行,所以資訊架構,資訊標準會缺失;待系統發展到一定規模後,各個系統資訊互動存在困難時,再來重構的成本也會很高。
2、業務建模樣式
業務功能域拆分,自頂向下的分解功能域。抽象建模是每個層次都需要的能力,不同的業務複雜度級別採取的方案可能不同。
比較簡單的業務,建設初期可能就是單系統。可以採用模組化拆分(包結構也算一種模組化,多工程也是一種模組化);可以使用GoF設計樣式,進行複雜功能的拆分,提供可讀性、可維護性;可以使用OOP面向物件變成進行業務建模等等。
稍微複雜一點的業務,可以使用DDD進行領域分析建模。對於業務領域進行業務物體,領域服務等合理的拆分,確定業務領域的職責範圍。
更複雜的業務綜合體,可以使用基於SOA的架構進行更大範圍的業務功能域的拆分,此部分的拆分樣式其實可以理解為更大範圍的DDD拆分,然後使用技術(SOA)的方式,讓各個業務域進行協作。本質上,建模的方式沒有太大的區別,把相同的業務服務劃分到特定職責的業務域。
3、架構與組織
一般架構師不需要關註這個點,但是架構和組織是配套對齊。只有得到組織的強有力支撐,架構實施才能得到有力實施。相對大型的業務物體會劃分為多個一級業務域,這些域會對應架構師,同時也會配比一定的研發團隊;一級業務域可能劃分為多個二級架構域,二級架構域也會有對應的架構師,組織一般也是配套。
有的架構師是純架構師,不帶團隊,這種架構師需要有加強的架構溝通能力,和各個TL協調資源和架構標的。有的架構師相容TL,這類架構師得到的支撐力度會更順暢。
對於大型的架構團隊,基本上會有架構委員會。一級業務域形成公司級別的架構委員會,對於一級域的重要職責負責;二級業務域也可以形成架構師團隊,便於二級業務域內職責確定和協作。
一個好的架構師需要理解自己,同時理解周邊。一級業務域架構師,需要清楚自己負責的一級業務域,同時也需要很熟悉周邊的一級業務域。架構越大的域,資訊量越大,很考驗架構師的資訊接收、抽象、建模能力。
4、架構規劃閉環
架構規劃、架構實施、架構評估是一個架構閉環。
架構是動態的,在平衡、取捨、演進的架構迭代中不斷演進。
沒有完美的架構,如果你覺得當前的架構是完美的架構,那麼你的業務可能是“死業務”。充滿生命力的業務會帶來業務變化,業務願景/標的也會有調整。業務願景可以直接帶來架構標的(比如要支撐國際化);缺失的平臺能力也帶來架構標的(比如平臺故障頻出)。
對於架構標的的內容進行合理的人員、優先順序、里程碑排布,然後付諸於實施。架構實施的過程一般都是充滿挑戰,實施過程中會有對架構標的的修正,會有和你負責的上下游進行遊說、PK,會有基於當前的困難做的取捨。
達到里程碑點後對於架構標的和實施情況進行評估,反饋,進行架構治理相關工作。
架構師的價值
個人把程式員進階分為如下幾個階段
-
任務明確型階段
多見於初入門的程式員,需要在別人指導下完成編碼工作。部分僅僅完成開發工作,不追求甚解的人可能停留在這個階段。
-
業務明確型階段
對於一個系統/業務的熟悉後,你已經可以完全掌控這個系統的職責。這個時候給你一個應該你做的需求,你會很容易進行系統的功能分解,設計,然後把這個需求完成。這個時候你知道自己該做什麼,不該做什麼。
-
業務模糊型階段
這個階段,你會遇到很多需求,這些需求可以在你這裡做,也可以不在你這裡做。會面對很多模糊領域的問題,解決模糊領域的能力,考驗架構師的能力,在資訊中抽絲剝繭,歸納抽象能力。這個時候,你不僅僅知道自己不該做什麼,還能知道這個不該做的應該放到哪裡去做,比如應該放到哪個系統裡。
-
創造進階階段
這個階段更複雜,帶有更多創造性,視野可能不僅僅侷限在現狀裡,比如現狀劃分了5個功能域。但是這個階段的架構師,也許可以創造出第6個功能域。一種方式是透過業務域重組;一種方式是對未來的識別。
架構師的挑戰和價值在於處理模糊領域的問題,讓模糊的變得不模糊,清晰可觸控。
架構師的軟能力
架構師很愛寫PPT,架構師寫PPT也很愛被一線的工程師詬病,說不乾實事。
但是,架構師很需要溝通表達能力,如何把架構標的清晰的進行表達,對架構職責進行表述,和相關關係人進行溝通,這些都很重要,關乎架構標的是否能達成。
同時,架構師對於資訊的處理能力很重要,對資訊的理解能力會決定架構師走的多遠,能多快、多準的找出架構關鍵點。
架構師也需要協調能力,比如架構師之間的溝通協調,架構師和實施團隊的溝通協調。
架構師該不該寫程式碼
一個好的架構師應該是從實戰中的真知,從實戰和細節中走來;但是,成長為一個架構師後,關註太多細節,會消耗較多的經歷,會影響從更宏觀看問題。技術型架構師這方面一般會好點。
架構師的工作,也是從編碼,架構規劃等工作中的取捨。如果需要關註到很細,架構師需要深入下去;如果不需要深入太細,可以從更宏觀來看問題,比如從功能層面。
如果你對 Dubbo 感興趣,歡迎加入我的知識星球一起交流。
目前在知識星球更新了《Dubbo 原始碼解析》目錄如下:
01. 除錯環境搭建
02. 專案結構一覽
03. 配置 Configuration
04. 核心流程一覽
05. 拓展機制 SPI
06. 執行緒池
07. 服務暴露 Export
08. 服務取用 Refer
09. 註冊中心 Registry
10. 動態編譯 Compile
11. 動態代理 Proxy
12. 服務呼叫 Invoke
13. 呼叫特性
14. 過濾器 Filter
15. NIO 伺服器
16. P2P 伺服器
17. HTTP 伺服器
18. 序列化 Serialization
19. 叢集容錯 Cluster
20. 優雅停機
21. 日誌適配
22. 狀態檢查
23. 監控中心 Monitor
24. 管理中心 Admin
25. 運維命令 QOS
26. 鏈路追蹤 Tracing
… 一共 69+ 篇
目前在知識星球更新了《Netty 原始碼解析》目錄如下:
01. 除錯環境搭建
02. NIO 基礎
03. Netty 簡介
04. 啟動 Bootstrap
05. 事件輪詢 EventLoop
06. 通道管道 ChannelPipeline
07. 通道 Channel
08. 位元組緩衝區 ByteBuf
09. 通道處理器 ChannelHandler
10. 編解碼 Codec
11. 工具類 Util
… 一共 61+ 篇
目前在知識星球更新了《資料庫物體設計》目錄如下:
01. 商品模組
02. 交易模組
03. 營銷模組
04. 公用模組
… 一共 17+ 篇
原始碼不易↓↓↓↓↓
點贊支援老艿艿↓↓