建筑師對主體結構的設計，在軟件工程中便是架構設計；大樓的主體結構在軟件工程中就是架構，它主要處理軟件的子系統和組件的開發和部署方式、技術指標和規范，以及它們之間的相互關系。

很多人多架構師可能有誤解，認為只是做了好多很炫的PPT，各種的架構圖、UML圖、流程圖、模塊拆分、組件拆分、部署圖等，感覺完全是紙上談兵，一行代碼沒寫，夸夸其談。

其實不然，古代帶兵打仗，講究兵馬未動糧草先行，正式開拔前一定要先把準備工作做好。畢竟做設計比寫代碼推翻重來的成本要低得多。

成為一名優秀的架構師需要具備很多條件：

• 業務理解轉化能力

• 思維抽象能力

• 軟件建模能力

• 高并發、高性能、高可用的分布式系統架構設計能力

• 前沿技術選型把控能力

• 系統重構能力

• 快速學習能力

• 此外，還要懂分布式緩存、消息隊列、負載均衡、數據庫、NoSQL、搜索、RPC、容器、分庫分表、注冊中心、分布式配置、鏈路跟蹤、服務治理、系統監控、微服務等等。此處省略1萬字。。。

兵法有云，“戰略上藐視敵人，戰術上重視敵人！”

有一個自信的意識，意味著你一只腳已經邁入成功的大門。

低頭走路，時不時也要抬頭看天。要想做好、做精一件事，不能只局限某一個細節點，要做到既有點也有面。放眼全局，才能更好驗證細節做的好不好，在整體架構中是否合理。否則，很容易導致 木桶效應

如何做好架構設計，有哪些經驗可以遵循，我們簡單來學習下

 一、“拆分” ，降低架構復雜度

世上沒有無緣無故的愛，也沒有無緣無故的恨，一切皆有因果。那為什么要做拆分呢？

人類大腦神經信號傳遞靠的是離子，通過透過鈉與鉀等離子來傳輸，其速度被限制在化學擴散的速率，所以我們的大腦內大部分神經信號是以約 30m/s 的速度傳播。

由于人腦處理問題的能力是有限的，當面對復雜問題時，會主動去尋找一些方法提升效率（這也是人與動物的最大區別，人具有思考能力）。神器就是 拆分 ，將復雜問題拆解為多個相對簡單的小問題。分而治之、各個擊破，這樣做極大地提高了解決復雜問題的可能性和效率。

簡單歸納：應用拆分、服務拆分、數據拆分、應用解耦。

比如常見的電商領域，當用戶發展到一定規模后，會拆分成一系列的業務子域：商戶、商品、庫存、權限、訂單、支付、履約、結算、售后、財務、會員、營銷、采購、倉儲等眾多模塊，項目實戰中可以結合DDD，來幫助我們理清、劃分各個子系統的邊界。

拆分帶來的好處：

• 需求不斷疊加導致并行開發和上線時，通過拆分可以減少相互影響。

• 降低系統的復雜度，讓研發人員適當聚焦，提升專業度。

• 弱化各個模塊間的耦合性，降低整體系統風險

• 大家分工更加明確，各司其職，工作效率更高

• 拆分微服務后，無狀態化部署，更容易橫向擴容，方便我們有針對性補齊某塊性能短板，提升整體系統吞吐量

拆分需注意事項：

• 最好是從 頂層按業務及業務流程來垂直拆分 ，而不是純技術視角維度。畢竟研發更多是跟著產品節奏來走
• 對于拆分得到的具體模塊，可以按 讀寫分離 、 在線離線分離 、 快慢分離 、 場景分離 等方式做進一步的水平拆分。
• 隨著業務的升級演化，不斷調整策略，將 易變與穩定 、 共性與非共性 進行水平拆分

拆分是架構設計大型復雜系統的第一步，對降低系統復雜性有著決定性的意義，它也是架構師的必備技能之一。

 二、認知抽象，架構模式有通用性

認知很重要，認知很重要，認知真的重要，重要的話說三遍。大家應該聽過一個成語：“一通百通”，出自明·吳承恩《西游記》。

原文：這猴王也是他一竅通時百竅通，當時習了口訣，自習自練，將七十二般變化，都學成了。

翻譯過來：一個主要的弄通了，其他的自然也都會弄通。

相信很多人都面試過別人，或者被別人面試過。大家有沒有發現一個現象，簡歷中項目經驗很重要，但是有時想招到一個對口業務的人真的很難，這時考量標準就會轉變為對求職者的基礎技術能力（比如算法）、表達能力、歸納能力、抽象思維能力。正所謂“一通百通”，你在一個行業積累了成功的項目經驗，那么再換一個賽道也不會有問題。

現如今，互聯網行業快速發展，各種垂直化業務如雨后春筍般涌現出來，騰訊的IM即時通訊、阿里巴巴的電商、滴滴的打車、百度的搜索、餓了么的O2O外賣。

看似形態各異，但細細一想，是不是也可以歸納為：讀業務、寫業務、扣減業務。

• 讀業務：對于讀的SLA（服務等級協議）要求非常高。但考慮到數據更改的頻率低，通常采用 數據盡量前置 應對性能要求。
• 寫業務：對寫的SLA要求高， 寫業務的特點是寫入的數據是用戶私有的而不是共享的 ，同時寫入不需要依賴已有的數據。對于 UGC 寫業務，只要盡最大可能將數據存儲下來即可。
• 扣減業務：與上面寫業務類似，但是寫入的內容要少很多，但是對單個數值的并發修改能力要求很高， 可以考慮將大庫存拆分N份小庫存，從而降低并發寫壓力。

假如你在微博工作做，知道微博的熱搜事件（讀事件）如何架構，緩存的熱點問題如何解決。那么同樣切到電商業務，對一些爆款商品的展示，我們也是有很多 共性化 的技術方案可以參考，我們要學會舉一反三。

 三、一圖勝千言，畫各種類型圖

為什么架構師都喜歡畫圖呢，一圖勝千言啊。人的生理結構更容易接受視覺型知識輸入。

《五視圖法》描述架構：

• 邏輯視圖：對應邏輯架構，主要關注功能需求，以及系統職責和行為的劃分。邏輯視圖不僅包括用戶可見的功能，還包括相應的輔助功能。比如秒殺系統中的活動場次切換、商品列表、用戶登錄、活動管理、后臺權限等功能

• 開發視圖：對應開發架構，主要關注系統開發過程中的質量屬性。它包括軟件源碼的組織方式、引入開源框架、配置方式、編譯打包方式以及與第三方包的依賴關系等。

• 運行視圖：對應運行架構，主要關注軟件運行過程中的質量屬性，它包括進程、線程、協程、對象之間的并發、同步、通信的問題等。

• 物理視圖：對應物理架構，主要關注安裝和部署需求。它包括軟件運行時的系統、網絡、服務器等基礎設施和相關配置，以及如何利用基礎設施來實現應用程序的高可用、可伸縮等。

• 數據視圖：對應數據架構，通常用 E-R 圖（Entity Relationship Diagram，實體-聯系圖）表示。主要關注數據需求，它包括數據的格式、屬性、關系等。

四、系統是演化來的，切勿初期就翻天覆地

隨著公司業務的擴大，系統也會經歷一個演化過程。大致分為這么幾個階段：煙囪式架構 --> 平臺化 --> 中臺化

就像人一樣，每個階段也都有自己的優點和不足，業務早期追求速度，講究快速落地，搶占市場，時間就是生命，我們可能采用集中式架構，系統快速落地，后期在慢慢優化、架構升級。

早期的系統很多都是煙囪式架構，自上而下一體化，存在大量的模塊重復，導致維護成本很高。另外模塊割裂對業務也有很大影響，比如：會員模塊，每個渠道都有自己的獨立用戶體系，用戶登錄網站系統時需要記住多套賬號，體驗較差。也不利于數據互通、共享，無法最大化發揮數據的價值。 此時，便有了從煙囪式架構朝著平臺化演化。

平臺化是從降低技術重復的角度出發，將重復模塊進行融合，從而提升效率。

中臺化，也稱為企業級的能力復用平臺。從業務復用的角度出發，進一步提升業務落地的效率。

中臺的搭建思路：

• 從平臺化到中臺化演化升級，可以從 業務能力可視化 、 業務能力在線配置化 的方法進行落地改造。
• 開發建設一套 業務可視化平臺 ，將業務平臺中的代碼流程可視化地 登記 到可視化系統中，按照一定的 連線規則 或 流程引擎規則 ，形成 業務流 。另外要保證可視化平臺能夠在業務代碼修改后，實時感知更新相對應的流程。

可視化之后，業務邏輯可以直接在可視化平臺上展現出來，業務方和產品經理不需要頻繁和研發溝通確認需求，可以極大地減少溝通時間，有助于 業務快速落地 。

中臺價值：當面對不斷出現的新的業務場景和形態時（如電商里新出現的社區團購等），中臺需要快速地復用已有能力，去滿足業務新建站點或不斷擴寬業務邊界的訴求。

最后，聊聊關于 “道” 認知

不管是設計什么樣的系統，在做技術方案前一定要充分了解業務背景、客戶需求，否則很容易走偏。最終開發出來的系統不是客戶想要的。

除了分析功能需求外，還要深入挖掘背后的非功能需求，如：面向的客戶群體是哪些？有多少用戶？一般什么時候訪問系統？可能會做出哪些危害系統的操作？

有針對性的加固系統，如果是秒殺性質，要思考系統如何不被瞬間洪峰流量沖垮。提前準備降級方案，舍小保大。在保證系統的高并發輸出外，也要兼顧系統的穩定性。

架構和歷史也是一樣， 分久必合合久必分，但在分分合合的過程中一定要結合業務現狀來設計演化。 千萬不要脫離業務，純技術或心性自由發揮，這樣很容易受挫。

最后，這個世界上沒有什么是完美的，架構設計也是一樣的， 比如拆分后帶來的分布式事務、調用鏈路變長、模塊變多，線上服務器增多，排查問題復雜，跨團隊溝通成本增加等問題。 不管怎樣，滿足當前業務發展，且預留一定的擴展性，滿足未來短期內的發展需要，這樣的架構設計就是合格的架構設計。