作者：小傅哥
博客：https://

沉淀、分享、成長，讓自己和他人都能有所收獲！😄

一、前言

架構(gòu)，說的是開發(fā)用的框架嗎？

對于剛接觸編程的新人來說，可能并不能很清楚的知道架構(gòu)是怎么來的，都包括什么內(nèi)容。如果非得說什么架構(gòu)，那么可能就是目前在 IDEA 中打開的工程就是架構(gòu)。

拋開技術圈內(nèi)的架構(gòu)而已，蓋房子的圖紙算不算架構(gòu)、做豆腐的步驟算不算架構(gòu)、結(jié)婚的流程算不算架構(gòu)？歸納得出，所有的這些步驟都在計算成本、耗材、執(zhí)行和產(chǎn)出，那么架構(gòu)就可以看做是一個用于完成目標結(jié)果的指導藍圖，現(xiàn)在在放到技術架構(gòu)的層面來看，架構(gòu)就不只是我們研發(fā)人員用到的技術框架，還需要根據(jù)場景、規(guī)模，設定技術選型、實施標準、部署結(jié)構(gòu)，綜合來完成一個項目的交付。

• 應用場景：你的應用場景是最先決定你采用哪種架構(gòu)的，這可能會包括：電商、交易、社交、視頻、音樂、出行、外賣等等，當然除了互聯(lián)網(wǎng)中的應用場景，還會有一些基于物聯(lián)網(wǎng)的應用，例如：PLC 應用、IO 板卡、中繼器打碼以及你熟悉的小區(qū)自提柜。
• 業(yè)務規(guī)模：這決定了你的用戶范圍和體量，如果你是在當下正火的抖音里開發(fā)商城，那你的用戶體量基數(shù)從上線之初就會特別大，但如果你還是一個初創(chuàng)團隊小電商，那么每天的QPS維持在 5~10，可能這個階段你就不需要有能承載多大體量的系統(tǒng)架構(gòu)。這也類似網(wǎng)絡上的笑話，團隊初期招聘某大廠大佬，上來就是超級架構(gòu)的建設，沒等系統(tǒng)開發(fā)完呢，公司沒了！
• 服務類型：有了場景和規(guī)模的設定，接下來要考慮的內(nèi)容就是整個技術實現(xiàn)層面的內(nèi)容，服務類型可能是整個團隊最初對系統(tǒng)拆分模塊和如何支持的考量，有了業(yè)務的分層就可以劃分出由各個團隊來協(xié)同支持開發(fā)。當然如果是小團隊那么這一環(huán)節(jié)最好縮小，哪怕把所有的功能都開發(fā)到一個系統(tǒng)里去，先快速驗證市場是主要的。
• 部署結(jié)構(gòu)：是部署結(jié)構(gòu)決定了開發(fā)模式，單體部署、集群部署、分布式部署、云環(huán)境等，這些都會決定技術的選型和框架的結(jié)構(gòu)。例如不引用RPC，那么就很難實現(xiàn)分布式部署，如果不使用分庫分表和大數(shù)據(jù)環(huán)境，也很難支撐起分布式部署下的數(shù)據(jù)應用。
• 開發(fā)框架：MVC、DDD，這應該是研發(fā)人員最先接觸到整個系統(tǒng)架構(gòu)中的代碼開發(fā)部分，也就是具體功能的具體實現(xiàn)層，如果是單體應用那么基本一個 MVC 結(jié)構(gòu)就夠了，但如果是大體量的分布式部署，那么你的系統(tǒng)開發(fā)里可能有的是操作數(shù)據(jù)庫的，有的是專門做業(yè)務的，有的是用于支持分布式任務和消費MQ消息的。
• 技術選型：其實開發(fā)框架，無論是 MVC 還是 DDD，都是不影響技術選型的，任何一種語言都可以放在同樣的架構(gòu)框架中進行開發(fā)，比如你說 Java、PHP、GO，只不過它們都是在自己語言下有自己的解決方案。

綜上，就是我們研發(fā)人員在做架構(gòu)設計時要考慮的核心內(nèi)容，隨著我們技術的不斷迭代也會有更多更新的思想，就像20年熱起來中臺、21年熱起來的低代碼，都是為了更好的讓架構(gòu)降本增效的實施方案。

但如果想了解和學習架構(gòu)，最好還是要從它是一顆小樹苗時候看起，看看它是如何一點點長大的。在頭腦中有了一個這樣的架構(gòu)體系，也能讓大家更好的理解和設計你需要的架構(gòu)。

二、架構(gòu)演變

1. 單體架構(gòu)

• 體量：?
• 技術：tomcat、weblogic、Java、Mysql、MVC
• 描述：我的博客 基本就是這種架構(gòu)，只不過開發(fā)語言不是Java的。這種結(jié)構(gòu)適合體量較小的業(yè)務場景，通常都是大佬在互聯(lián)網(wǎng)初期自研的網(wǎng)站，不過現(xiàn)在這種模型并沒有過期，依舊有它的應用場景。

2. 應用與數(shù)據(jù)庫分離

• 體量：?
• 技術：tomcat、weblogic、Java、DB2、MVC
• 描述：這一階段的拆分其實沒有太多變體，主要是由于原有的單體架構(gòu)應用和數(shù)據(jù)庫部署在一臺服務器上，導致性能不足。那么最簡單高效的拆分就是把應用和數(shù)據(jù)庫分離開了，讓它們在各自的服務器上發(fā)揮最大性能。

3. 使用緩存抗量

• 體量：??
• 技術：tomcat、weblogic、Java、Oracle、MVC、Redis
• 描述：在這個階段大家發(fā)現(xiàn)，我們需要頻繁的從數(shù)據(jù)庫中拉取數(shù)據(jù)，非常耗費性能。也嘗試把一部分數(shù)據(jù)存放在本地內(nèi)存，但在服務重啟后這部分數(shù)據(jù)就沒有了。因此引入了Redis這樣的緩存服務，在這個階段還是非常大的提升了整體服務的性能。

4. 多應用部署和Nginx反向代理

• 體量：???
• 技術：tomcat、weblogic、Java、Oracle、MVC、Redis、Nginx
• 描述：當單個服務的承載體量已經(jīng)到極限了以后，就能想到的就是把服務部署多套，因為這些服務都是做著同樣的事，數(shù)據(jù)庫又都是統(tǒng)一一套的，那么通過Nginx的反向代理，就可以把用戶的請求分散到不同的服務上去，大大的減輕了服務壓力。

5. 數(shù)據(jù)庫讀寫分離

• 體量：???
• 技術：tomcat、weblogic、Java、Oracle、MVC、Redis、Nginx
• 描述：數(shù)據(jù)庫的讀寫分離設計，更多的是因為某些業(yè)務場景需要大量的事務性寫入，影響到需要讀操作的業(yè)務。但讀寫分離的設計并沒有太大程度上提升系統(tǒng)性能，因為很大程度的讀操作已經(jīng)使用 Redis 抗住。不過這樣的設計思路卻為后續(xù)的架構(gòu)模型提供了新的思路。

6. 應用分組部署

• 體量：????
• 技術：tomcat、weblogic、Java、Oracle、MVC、Redis、Nginx
• 描述：所有業(yè)務都開發(fā)在一個應用上所能承載的用戶體量已經(jīng)到極限了，那么接下來最好架構(gòu)方式就把不同的業(yè)務拆分為不同的應用，這些應用都配有自己的數(shù)據(jù)庫，也分別部署在自己的服務器內(nèi)。這樣一來就大大提升了整體的負載能力。

7. 應用分庫設計

• 體量：????
• 技術：tomcat、weblogic、Java、Oracle、MVC、Redis、Nginx、MyCat
• 描述：當應用按照不同的業(yè)務各自系統(tǒng)拆分以后，接下來的瓶頸就在于已經(jīng)獨立的應用用戶體量依舊很大，對應的數(shù)據(jù)庫熱連接數(shù)持續(xù)增高。所以在當前條件下，開始設計應用分庫操作，同時后可能也會在這個階段引入分表操作。這樣一來單個應用的負載能力又得到了一大截的提升，但是拆庫以后也需要引入分布式事務、數(shù)據(jù)匯總等其他技術的使用，來解決拆庫新增的問題。

8. RPC 分布式部署

• 體量：?????
• 技術：tomcat、weblogic、Java、Oracle、MVC、Redis、Nginx、MyCat、RPC、LVS/F5
• 描述：在系統(tǒng)不斷的再精細化設計以后，其實某些服務并不需要持續(xù)的連庫操作，它們可能更多的是業(yè)務邏輯的包裝，同時這些數(shù)據(jù)庫層的操作應用屬于底層系統(tǒng)，那么就可以把這樣系統(tǒng)用于連庫操作，而上層服務通過RPC框架來連接這樣的服務。那么，現(xiàn)在就可以通過分布式部署的方式，提升整體的服務性能。

9. 應用細分和網(wǎng)關引入

• 體量：?????
• 技術：tomcat、weblogic、Java、Oracle、MVC、Redis、Nginx、MyCat、RPC、LVS/F5、網(wǎng)關、MQ、分布式任務、Elasticsearch
• 描述：從上到下的整個架構(gòu)演變過程，我們不斷的拆分應用、單獨部署一直到應用細分，都是在不斷的提升應用服務的能力，讓各自應用體負責獨立的事情。這個階段已經(jīng)開始體現(xiàn)出微服務的能力了，同時這個階段也引入了上層的網(wǎng)關統(tǒng)一接入和下層的數(shù)據(jù)使用能力。

10. 低代碼編程和可復用

• 體量：?????
• 技術：tomcat、weblogic、Java、Oracle、MVC、Redis、Nginx、MyCat、RPC、LVS/F5、網(wǎng)關、MQ、分布式任務、Elasticsearch、SDK、低代碼、支撐服務
• 描述：在目前這個階段服務框架基本已經(jīng)可以很好的支撐用戶體量，所以也開始考慮如何更高效的開發(fā)和交付問題。那么也就引入了服務編排、服務治理以及通用的模塊、組件和中間件。而這些設計其實壓縮來看基本就是以前你開發(fā)的一個應用而已，不過把所有非業(yè)務邏輯的通用性功能不斷的拆分出來了，再通過這些細分的組件和服務能力的編排，提供所需接口，這樣一來也就大大的提升了可持續(xù)交付集成的效率。

三、架構(gòu)圖📚下載

有小伙伴反饋看了架構(gòu)圖，也有了點自己的想法，但是動手畫的時候就很懵，不知道從哪開始。那么小傅哥把畫的架構(gòu)圖原稿分享給大家，可以讓感興趣的小伙伴下載使用。

• 公眾號：bugstack蟲洞棧，回復：架構(gòu)圖，即可獲得最新的下載鏈接。后續(xù)更新和補充會更換鏈接

四、總結(jié)

• 本章也是小傅哥在整理系列架構(gòu)內(nèi)容資料的一個總結(jié)，讓新人碼農(nóng)對架構(gòu)有一個從小到大的認識。在總結(jié)整理時也結(jié)合現(xiàn)在的架構(gòu)簡化了一部分內(nèi)容，因為只有剝絲抽繭的看懂最主干的內(nèi)容，大家才好不斷的擴展枝葉。
• 從演變的過程我們可以看到，業(yè)務體量會影響部署，部署形態(tài)會改變架構(gòu)，架構(gòu)會呼應開發(fā)方式，最終語言只是當前最合適某種架構(gòu)的工具，各項技術棧的運用也是為了技術需求而存在。
• 最后，就是如果你也想讓圖表達出你的意思，那么可以嘗試畫一畫、總結(jié)總結(jié)，找到一種能適合你表達出結(jié)果的畫圖結(jié)構(gòu)。

五、系列推薦

• 工作兩三年了，整不明白架構(gòu)圖都畫啥？
• 技術掃盲：關于低代碼編程的可持續(xù)性交付設計和分析
• 方案設計：基于IDEA插件開發(fā)和字節(jié)碼插樁技術，實現(xiàn)研發(fā)交付質(zhì)量自動分析
• 半年招聘篩選了400+份簡歷，告訴你怎么寫容易被撩！
• 《Java 面經(jīng)手冊》PDF，全書 417 頁 11.5 萬字，完稿&發(fā)版！