建筑師對(duì)主體結(jié)構(gòu)的設(shè)計(jì)，在軟件工程中便是架構(gòu)設(shè)計(jì)；大樓的主體結(jié)構(gòu)在軟件工程中就是架構(gòu)，它主要處理軟件的子系統(tǒng)和組件的開發(fā)和部署方式、技術(shù)指標(biāo)和規(guī)范，以及它們之間的相互關(guān)系。

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

其實(shí)不然，古代帶兵打仗，講究兵馬未動(dòng)糧草先行，正式開拔前一定要先把準(zhǔn)備工作做好。畢竟做設(shè)計(jì)比寫代碼推翻重來(lái)的成本要低得多。

成為一名優(yōu)秀的架構(gòu)師需要具備很多條件：

• 業(yè)務(wù)理解轉(zhuǎn)化能力

• 思維抽象能力

• 軟件建模能力

• 高并發(fā)、高性能、高可用的分布式系統(tǒng)架構(gòu)設(shè)計(jì)能力

• 前沿技術(shù)選型把控能力

• 系統(tǒng)重構(gòu)能力

• 快速學(xué)習(xí)能力

• 此外，還要懂分布式緩存、消息隊(duì)列、負(fù)載均衡、數(shù)據(jù)庫(kù)、NoSQL、搜索、RPC、容器、分庫(kù)分表、注冊(cè)中心、分布式配置、鏈路跟蹤、服務(wù)治理、系統(tǒng)監(jiān)控、微服務(wù)等等。此處省略1萬(wàn)字。。。

兵法有云，“戰(zhàn)略上藐視敵人，戰(zhàn)術(shù)上重視敵人！”

有一個(gè)自信的意識(shí)，意味著你一只腳已經(jīng)邁入成功的大門。

低頭走路，時(shí)不時(shí)也要抬頭看天。要想做好、做精一件事，不能只局限某一個(gè)細(xì)節(jié)點(diǎn)，要做到既有點(diǎn)也有面。放眼全局，才能更好驗(yàn)證細(xì)節(jié)做的好不好，在整體架構(gòu)中是否合理。否則，很容易導(dǎo)致 木桶效應(yīng)

如何做好架構(gòu)設(shè)計(jì)，有哪些經(jīng)驗(yàn)可以遵循，我們簡(jiǎn)單來(lái)學(xué)習(xí)下

 一、“拆分” ，降低架構(gòu)復(fù)雜度

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

人類大腦神經(jīng)信號(hào)傳遞靠的是離子，通過透過鈉與鉀等離子來(lái)傳輸，其速度被限制在化學(xué)擴(kuò)散的速率，所以我們的大腦內(nèi)大部分神經(jīng)信號(hào)是以約 30m/s 的速度傳播。

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

簡(jiǎn)單歸納：應(yīng)用拆分、服務(wù)拆分、數(shù)據(jù)拆分、應(yīng)用解耦。

比如常見的電商領(lǐng)域，當(dāng)用戶發(fā)展到一定規(guī)模后，會(huì)拆分成一系列的業(yè)務(wù)子域：商戶、商品、庫(kù)存、權(quán)限、訂單、支付、履約、結(jié)算、售后、財(cái)務(wù)、會(huì)員、營(yíng)銷、采購(gòu)、倉(cāng)儲(chǔ)等眾多模塊，項(xiàng)目實(shí)戰(zhàn)中可以結(jié)合DDD，來(lái)幫助我們理清、劃分各個(gè)子系統(tǒng)的邊界。

拆分帶來(lái)的好處：

• 需求不斷疊加導(dǎo)致并行開發(fā)和上線時(shí)，通過拆分可以減少相互影響。

• 降低系統(tǒng)的復(fù)雜度，讓研發(fā)人員適當(dāng)聚焦，提升專業(yè)度。

• 弱化各個(gè)模塊間的耦合性，降低整體系統(tǒng)風(fēng)險(xiǎn)

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

• 拆分微服務(wù)后，無(wú)狀態(tài)化部署，更容易橫向擴(kuò)容，方便我們有針對(duì)性補(bǔ)齊某塊性能短板，提升整體系統(tǒng)吞吐量

拆分需注意事項(xiàng)：

• 最好是從 頂層按業(yè)務(wù)及業(yè)務(wù)流程來(lái)垂直拆分 ，而不是純技術(shù)視角維度。畢竟研發(fā)更多是跟著產(chǎn)品節(jié)奏來(lái)走
• 對(duì)于拆分得到的具體模塊，可以按 讀寫分離 、 在線離線分離 、 快慢分離 、 場(chǎng)景分離 等方式做進(jìn)一步的水平拆分。
• 隨著業(yè)務(wù)的升級(jí)演化，不斷調(diào)整策略，將 易變與穩(wěn)定 、 共性與非共性 進(jìn)行水平拆分

拆分是架構(gòu)設(shè)計(jì)大型復(fù)雜系統(tǒng)的第一步，對(duì)降低系統(tǒng)復(fù)雜性有著決定性的意義，它也是架構(gòu)師的必備技能之一。

 二、認(rèn)知抽象，架構(gòu)模式有通用性

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

原文：這猴王也是他一竅通時(shí)百竅通，當(dāng)時(shí)習(xí)了口訣，自習(xí)自練，將七十二般變化，都學(xué)成了。

翻譯過來(lái)：一個(gè)主要的弄通了，其他的自然也都會(huì)弄通。

相信很多人都面試過別人，或者被別人面試過。大家有沒有發(fā)現(xiàn)一個(gè)現(xiàn)象，簡(jiǎn)歷中項(xiàng)目經(jīng)驗(yàn)很重要，但是有時(shí)想招到一個(gè)對(duì)口業(yè)務(wù)的人真的很難，這時(shí)考量標(biāo)準(zhǔn)就會(huì)轉(zhuǎn)變?yōu)閷?duì)求職者的基礎(chǔ)技術(shù)能力（比如算法）、表達(dá)能力、歸納能力、抽象思維能力。正所謂“一通百通”，你在一個(gè)行業(yè)積累了成功的項(xiàng)目經(jīng)驗(yàn)，那么再換一個(gè)賽道也不會(huì)有問題。

現(xiàn)如今，互聯(lián)網(wǎng)行業(yè)快速發(fā)展，各種垂直化業(yè)務(wù)如雨后春筍般涌現(xiàn)出來(lái)，騰訊的IM即時(shí)通訊、阿里巴巴的電商、滴滴的打車、百度的搜索、餓了么的O2O外賣。

看似形態(tài)各異，但細(xì)細(xì)一想，是不是也可以歸納為：讀業(yè)務(wù)、寫業(yè)務(wù)、扣減業(yè)務(wù)。

• 讀業(yè)務(wù)：對(duì)于讀的SLA（服務(wù)等級(jí)協(xié)議）要求非常高。但考慮到數(shù)據(jù)更改的頻率低，通常采用 數(shù)據(jù)盡量前置 應(yīng)對(duì)性能要求。
• 寫業(yè)務(wù)：對(duì)寫的SLA要求高， 寫業(yè)務(wù)的特點(diǎn)是寫入的數(shù)據(jù)是用戶私有的而不是共享的 ，同時(shí)寫入不需要依賴已有的數(shù)據(jù)。對(duì)于 UGC 寫業(yè)務(wù)，只要盡最大可能將數(shù)據(jù)存儲(chǔ)下來(lái)即可。
• 扣減業(yè)務(wù)：與上面寫業(yè)務(wù)類似，但是寫入的內(nèi)容要少很多，但是對(duì)單個(gè)數(shù)值的并發(fā)修改能力要求很高， 可以考慮將大庫(kù)存拆分N份小庫(kù)存，從而降低并發(fā)寫壓力。

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

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

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

《五視圖法》描述架構(gòu)：

• 邏輯視圖：對(duì)應(yīng)邏輯架構(gòu)，主要關(guān)注功能需求，以及系統(tǒng)職責(zé)和行為的劃分。邏輯視圖不僅包括用戶可見的功能，還包括相應(yīng)的輔助功能。比如秒殺系統(tǒng)中的活動(dòng)場(chǎng)次切換、商品列表、用戶登錄、活動(dòng)管理、后臺(tái)權(quán)限等功能

• 開發(fā)視圖：對(duì)應(yīng)開發(fā)架構(gòu)，主要關(guān)注系統(tǒng)開發(fā)過程中的質(zhì)量屬性。它包括軟件源碼的組織方式、引入開源框架、配置方式、編譯打包方式以及與第三方包的依賴關(guān)系等。

• 運(yùn)行視圖：對(duì)應(yīng)運(yùn)行架構(gòu)，主要關(guān)注軟件運(yùn)行過程中的質(zhì)量屬性，它包括進(jìn)程、線程、協(xié)程、對(duì)象之間的并發(fā)、同步、通信的問題等。

• 物理視圖：對(duì)應(yīng)物理架構(gòu)，主要關(guān)注安裝和部署需求。它包括軟件運(yùn)行時(shí)的系統(tǒng)、網(wǎng)絡(luò)、服務(wù)器等基礎(chǔ)設(shè)施和相關(guān)配置，以及如何利用基礎(chǔ)設(shè)施來(lái)實(shí)現(xiàn)應(yīng)用程序的高可用、可伸縮等。

• 數(shù)據(jù)視圖：對(duì)應(yīng)數(shù)據(jù)架構(gòu)，通常用 E-R 圖（Entity Relationship Diagram，實(shí)體-聯(lián)系圖）表示。主要關(guān)注數(shù)據(jù)需求，它包括數(shù)據(jù)的格式、屬性、關(guān)系等。

四、系統(tǒng)是演化來(lái)的，切勿初期就翻天覆地

隨著公司業(yè)務(wù)的擴(kuò)大，系統(tǒng)也會(huì)經(jīng)歷一個(gè)演化過程。大致分為這么幾個(gè)階段：煙囪式架構(gòu) --> 平臺(tái)化 --> 中臺(tái)化

就像人一樣，每個(gè)階段也都有自己的優(yōu)點(diǎn)和不足，業(yè)務(wù)早期追求速度，講究快速落地，搶占市場(chǎng)，時(shí)間就是生命，我們可能采用集中式架構(gòu)，系統(tǒng)快速落地，后期在慢慢優(yōu)化、架構(gòu)升級(jí)。

早期的系統(tǒng)很多都是煙囪式架構(gòu)，自上而下一體化，存在大量的模塊重復(fù)，導(dǎo)致維護(hù)成本很高。另外模塊割裂對(duì)業(yè)務(wù)也有很大影響，比如：會(huì)員模塊，每個(gè)渠道都有自己的獨(dú)立用戶體系，用戶登錄網(wǎng)站系統(tǒng)時(shí)需要記住多套賬號(hào)，體驗(yàn)較差。也不利于數(shù)據(jù)互通、共享，無(wú)法最大化發(fā)揮數(shù)據(jù)的價(jià)值。 此時(shí)，便有了從煙囪式架構(gòu)朝著平臺(tái)化演化。

平臺(tái)化是從降低技術(shù)重復(fù)的角度出發(fā)，將重復(fù)模塊進(jìn)行融合，從而提升效率。

中臺(tái)化，也稱為企業(yè)級(jí)的能力復(fù)用平臺(tái)。從業(yè)務(wù)復(fù)用的角度出發(fā)，進(jìn)一步提升業(yè)務(wù)落地的效率。

中臺(tái)的搭建思路：

• 從平臺(tái)化到中臺(tái)化演化升級(jí)，可以從 業(yè)務(wù)能力可視化 、 業(yè)務(wù)能力在線配置化 的方法進(jìn)行落地改造。
• 開發(fā)建設(shè)一套 業(yè)務(wù)可視化平臺(tái) ，將業(yè)務(wù)平臺(tái)中的代碼流程可視化地 登記 到可視化系統(tǒng)中，按照一定的 連線規(guī)則 或 流程引擎規(guī)則 ，形成 業(yè)務(wù)流 。另外要保證可視化平臺(tái)能夠在業(yè)務(wù)代碼修改后，實(shí)時(shí)感知更新相對(duì)應(yīng)的流程。

可視化之后，業(yè)務(wù)邏輯可以直接在可視化平臺(tái)上展現(xiàn)出來(lái)，業(yè)務(wù)方和產(chǎn)品經(jīng)理不需要頻繁和研發(fā)溝通確認(rèn)需求，可以極大地減少溝通時(shí)間，有助于 業(yè)務(wù)快速落地 。

中臺(tái)價(jià)值：當(dāng)面對(duì)不斷出現(xiàn)的新的業(yè)務(wù)場(chǎng)景和形態(tài)時(shí)（如電商里新出現(xiàn)的社區(qū)團(tuán)購(gòu)等），中臺(tái)需要快速地復(fù)用已有能力，去滿足業(yè)務(wù)新建站點(diǎn)或不斷擴(kuò)寬業(yè)務(wù)邊界的訴求。

最后，聊聊關(guān)于 “道” 認(rèn)知

不管是設(shè)計(jì)什么樣的系統(tǒng)，在做技術(shù)方案前一定要充分了解業(yè)務(wù)背景、客戶需求，否則很容易走偏。最終開發(fā)出來(lái)的系統(tǒng)不是客戶想要的。

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

有針對(duì)性的加固系統(tǒng)，如果是秒殺性質(zhì)，要思考系統(tǒng)如何不被瞬間洪峰流量沖垮。提前準(zhǔn)備降級(jí)方案，舍小保大。在保證系統(tǒng)的高并發(fā)輸出外，也要兼顧系統(tǒng)的穩(wěn)定性。

架構(gòu)和歷史也是一樣， 分久必合合久必分，但在分分合合的過程中一定要結(jié)合業(yè)務(wù)現(xiàn)狀來(lái)設(shè)計(jì)演化。 千萬(wàn)不要脫離業(yè)務(wù)，純技術(shù)或心性自由發(fā)揮，這樣很容易受挫。

最后，這個(gè)世界上沒有什么是完美的，架構(gòu)設(shè)計(jì)也是一樣的， 比如拆分后帶來(lái)的分布式事務(wù)、調(diào)用鏈路變長(zhǎng)、模塊變多，線上服務(wù)器增多，排查問題復(fù)雜，跨團(tuán)隊(duì)溝通成本增加等問題。 不管怎樣，滿足當(dāng)前業(yè)務(wù)發(fā)展，且預(yù)留一定的擴(kuò)展性，滿足未來(lái)短期內(nèi)的發(fā)展需要，這樣的架構(gòu)設(shè)計(jì)就是合格的架構(gòu)設(shè)計(jì)。