作者：小傅哥
部落格：https://bugstack.cn
沉澱、分享、成長，讓自己和他人都能有所收穫！?
一、前言
架構，說的是開發用的框架嗎？
對於剛接觸程式設計的新人來說，可能並不能很清楚的知道架構是怎麼來的，都包括什麼內容。如果非得說什麼架構，那麼可能就是目前在 IDEA 中開啟的工程就是架構。
拋開技術圈內的架構而已，蓋房子的圖紙算不算架構、做豆腐的步驟算不算架構、結婚的流程算不算架構？歸納得出，所有的這些步驟都在計算成本、耗材、執行和產出，那麼架構就可以看做是一個用於完成目標結果的指導藍圖，現在在放到技術架構的層面來看，架構就不只是我們研發人員用到的技術框架，還需要根據場景、規模，設定技術選型、實施標準、部署結構，綜合來完成一個專案的交付。
- 應用場景：你的應用場景是最先決定你採用哪種架構的，這可能會包括：電商、交易、社交、視訊、音樂、出行、外賣等等，當然除了網際網路中的應用場景，還會有一些基於物聯網的應用，例如：PLC 應用、IO 板卡、中繼器打碼以及你熟悉的小區自提櫃。
- 業務規模：這決定了你的使用者範圍和體量，如果你是在當下正火的抖音裡開發商城，那你的使用者體量基數從上線之初就會特別大，但如果你還是一個初創團隊小電商，那麼每天的QPS維持在 5~10，可能這個階段你就不需要有能承載多大體量的系統架構。這也類似網路上的笑話，團隊初期招聘某大廠大佬，上來就是超級架構的建設，沒等系統開發完呢，公司沒了！
- 服務型別：有了場景和規模的設定，接下來要考慮的內容就是整個技術實現層面的內容，服務型別可能是整個團隊最初對系統拆分模組和如何支援的考量，有了業務的分層就可以劃分出由各個團隊來協同支援開發。當然如果是小團隊那麼這一環節最好縮小，哪怕把所有的功能都開發到一個系統裡去，先快速驗證市場是主要的。
- 部署結構：是部署結構決定了開發模式，單體部署、叢集部署、分散式部署、雲環境等，這些都會決定技術的選型和框架的結構。例如不引用RPC，那麼就很難實現分散式部署，如果不使用分庫分表和大資料環境，也很難支撐起分散式部署下的資料應用。
- 開發框架：MVC、DDD，這應該是研發人員最先接觸到整個系統架構中的程式碼開發部分，也就是具體功能的具體實現層，如果是單體應用那麼基本一個 MVC 結構就夠了，但如果是大體量的分散式部署，那麼你的系統開發裡可能有的是運算元據庫的，有的是專門做業務的，有的是用於支援分散式任務和消費MQ訊息的。
- 技術選型：其實開發框架，無論是 MVC 還是 DDD，都是不影響技術選型的，任何一種語言都可以放在同樣的架構框架中進行開發，比如你說 Java、PHP、GO，只不過它們都是在自己語言下有自己的解決方案。
綜上，就是我們研發人員在做架構設計時要考慮的核心內容，隨著我們技術的不斷迭代也會有更多更新的思想，就像20年熱起來中臺、21年熱起來的低程式碼，都是為了更好的讓架構降本增效的實施方案。
但如果想了解和學習架構，最好還是要從它是一顆小樹苗時候看起，看看它是如何一點點長大的。在頭腦中有了一個這樣的架構體系，也能讓大家更好的理解和設計你需要的架構。
二、架構演變
1. 單體架構
- 體量：⭐
- 技術：tomcat、weblogic、Java、Mysql、MVC
- 描述：我的部落格 bugstack.cn 基本就是這種架構，只不過開發語言不是Java的。這種結構適合體量較小的業務場景，通常都是大佬在網際網路初期自研的網站，不過現在這種模型並沒有過期，依舊有它的應用場景。
2. 應用與資料庫分離
- 體量：⭐
- 技術：tomcat、weblogic、Java、DB2、MVC
- 描述：這一階段的拆分其實沒有太多變體，主要是由於原有的單體架構應用和資料庫部署在一臺伺服器上，導致效能不足。那麼最簡單高效的拆分就是把應用和資料庫分離開了，讓它們在各自的伺服器上發揮最大效能。
3. 使用快取抗量
- 體量：⭐⭐
- 技術：tomcat、weblogic、Java、Oracle、MVC、Redis
- 描述：在這個階段大家發現，我們需要頻繁的從資料庫中拉取資料，非常耗費效能。也嘗試把一部分資料存放在本地記憶體，但在服務重啟後這部分資料就沒有了。因此引入了Redis這樣的快取服務，在這個階段還是非常大的提升了整體服務的效能。
4. 多應用部署和Nginx反向代理
- 體量：⭐⭐⭐
- 技術：tomcat、weblogic、Java、Oracle、MVC、Redis、Nginx
- 描述：當單個服務的承載體量已經到極限了以後，就能想到的就是把服務部署多套，因為這些服務都是做著同樣的事，資料庫又都是統一一套的，那麼通過Nginx的反向代理，就可以把使用者的請求分散到不同的服務上去，大大的減輕了服務壓力。
5. 資料庫讀寫分離
- 體量：⭐⭐⭐
- 技術：tomcat、weblogic、Java、Oracle、MVC、Redis、Nginx
- 描述：資料庫的讀寫分離設計，更多的是因為某些業務場景需要大量的事務性寫入，影響到需要讀操作的業務。但讀寫分離的設計並沒有太大程度上提升系統效能，因為很大程度的讀操作已經使用 Redis 抗住。不過這樣的設計思路卻為後續的架構模型提供了新的思路。
6. 應用分組部署
- 體量：⭐⭐⭐⭐
- 技術：tomcat、weblogic、Java、Oracle、MVC、Redis、Nginx
- 描述：所有業務都開發在一個應用上所能承載的使用者體量已經到極限了，那麼接下來最好架構方式就把不同的業務拆分為不同的應用，這些應用都配有自己的資料庫，也分別部署在自己的伺服器內。這樣一來就大大提升了整體的負載能力。
7. 應用分庫設計
- 體量：⭐⭐⭐⭐
- 技術：tomcat、weblogic、Java、Oracle、MVC、Redis、Nginx、MyCat
- 描述：當應用按照不同的業務各自系統拆分以後，接下來的瓶頸就在於已經獨立的應用使用者體量依舊很大，對應的資料庫熱連線數持續增高。所以在當前條件下，開始設計應用分庫操作，同時後可能也會在這個階段引入分表操作。這樣一來單個應用的負載能力又得到了一大截的提升，但是拆庫以後也需要引入分散式事務、資料彙總等其他技術的使用，來解決拆庫新增的問題。
8. RPC 分散式部署
- 體量：⭐⭐⭐⭐⭐
- 技術：tomcat、weblogic、Java、Oracle、MVC、Redis、Nginx、MyCat、RPC、LVS/F5
- 描述：在系統不斷的再精細化設計以後，其實某些服務並不需要持續的連庫操作，它們可能更多的是業務邏輯的包裝，同時這些資料庫層的操作應用屬於底層系統，那麼就可以把這樣系統用於連庫操作，而上層服務通過RPC框架來連線這樣的服務。那麼，現在就可以通過分散式部署的方式，提升整體的服務效能。
9. 應用細分和閘道器引入
- 體量：⭐⭐⭐⭐⭐
- 技術：tomcat、weblogic、Java、Oracle、MVC、Redis、Nginx、MyCat、RPC、LVS/F5、閘道器、MQ、分散式任務、Elasticsearch
- 描述：從上到下的整個架構演變過程，我們不斷的拆分應用、單獨部署一直到應用細分，都是在不斷的提升應用服務的能力，讓各自應用體負責獨立的事情。這個階段已經開始體現出微服務的能力了，同時這個階段也引入了上層的閘道器統一接入和下層的資料使用能力。
10. 低程式碼程式設計和可複用
- 體量：⭐⭐⭐⭐⭐
- 技術：tomcat、weblogic、Java、Oracle、MVC、Redis、Nginx、MyCat、RPC、LVS/F5、閘道器、MQ、分散式任務、Elasticsearch、SDK、低程式碼、支撐服務
- 描述：在目前這個階段服務框架基本已經可以很好的支撐使用者體量，所以也開始考慮如何更高效的開發和交付問題。那麼也就引入了服務編排、服務治理以及通用的模組、元件和中介軟體。而這些設計其實壓縮來看基本就是以前你開發的一個應用而已，不過把所有非業務邏輯的通用性功能不斷的拆分出來了，再通過這些細分的元件和服務能力的編排，提供所需介面，這樣一來也就大大的提升了可持續交付整合的效率。
三、架構圖?下載
有小夥伴反饋看了架構圖，也有了點自己的想法，但是動手畫的時候就很懵，不知道從哪開始。那麼小傅哥把畫的架構圖原稿分享給大家，可以讓感興趣的小夥伴下載使用。
下載：https://download.csdn.net/download/Yao__Shun__Yu/15567125
四、總結
- 本章也是小傅哥在整理系列架構內容資料的一個總結，讓
新人碼農對架構有一個從小到大的認識。在總結整理時也結合現在的架構簡化了一部分內容，因為只有剝絲抽繭的看懂最主幹的內容，大家才好不斷的擴充套件枝葉。 - 從演變的過程我們可以看到，業務體量會影響部署，部署形態會改變架構，架構會呼應開發方式，最終語言只是當前最合適某種架構的工具，各項技術棧的運用也是為了技術需求而存在。
- 最後，就是如果你也想讓圖表達出你的意思，那麼可以嘗試畫一畫、總結總結，找到一種能適合你表達出結果的畫圖結構。