常見系統架構的介紹

我們平時都會聽到什么單體架構、微服務、分布式專案，那么這些都是啥意思呢？我們在開發前應該咋么選型（雖說我是個菜菜架構方面不用我考慮，就當是先學習學習），那么我們就得先了解一下有哪些常見的系統架構，有那些優缺點？

1、寫在前面

任何一個架構不會一上來就搭建微服務架構，而是一步一步跟用用戶量、訪問量來演變的，除非能確定我的業務需求非常的復雜，有很多用戶訪問量；因此，我們要明白在什么樣的場景應該使用啥樣的架構；

系統架構大致有以下幾種：

• 單體應用架構
• 垂直架構
• 分布式架構
• SOA架構
• 微服務架構

2、單體架構

單體架構就是將所有的功能代碼部署在一塊，可以減少開發、部署和維護的成本；他包含了應用所有功能的應用程式是一種比較傳統的架構風格，只實作最簡單，最基礎的功能；

換句話就是說將所有的業務場景的前臺表示層、中間業務邏輯層和后臺資料訪問層都放在一個工程中，最終經過編譯、打包，部署在一臺服務器上，如下圖：

在一些小型應用的初期，訪問量小的時候，這種架構的性價比還是比較高的，開發速度快，成本低，但是隨著業務的發展，邏輯越來越復雜，代碼量越來越大，代碼的可讀性和可維護性越來越低，用戶的增加，訪問量越來越多單體架構的應用并發能力十分有限，這種架構雖然有一定的并發能力，及應對一定復雜業務，但是依然沒有改變系統為單體架構的事實，大量的業務必然會有大量的代碼，代碼得可讀性和可維護性依然很差，如果面對海量的用戶，它的并發能力依然不夠，

優點：

• 專案架構簡單，小型專案開發成本低；
• 專案部署在一塊，維護方便；

缺點：

• 全部功能集成在一個工程中，對于大型專案來講不易開發和維護
• 專案模塊之間緊密耦合，單點容錯率低
• 無法針對不同模塊進行針對性優化和水平擴展

3、垂直架構

隨著訪問量的逐漸增大，單一應用只就無法滿足需求了；所謂的垂直應用架構，就是將原來的一個應用拆成互不相干的幾個應用，以提升效率；

比如電商平臺，如果用戶訪問增加但是又并不是對所有的模塊都會有比較大的訪問量，可能對用戶管理和訂單管理的影響比較大對訊息中心的影響就比較小，那么我們就希望只多增加幾個訂單模塊， 而不增加訊息模塊，再比如CMS應用宕機了，其他的應用也不想被受影響；此時單體應用就做不到了， 垂直架構就應運而生了；

我們根據業務功能可以將上面電商的單體應用拆分成以下部分：

• 電商系統(用戶管理 商品管理 訂單管理)
• 后臺系統(用戶管理 訂單管理 客戶管理)
• CMS系統(廣告管理 營銷管理)

這樣拆分完畢之后，一旦用戶訪問量變大，只需要增加電商系統的節點就可以了，而無需增加后臺和CMS的節點，

優點：

• 系統拆分實作了流量分擔，解決了并發問題
• 可以針對不同模塊進行優化和水擴展
• 一個系統的問題不會影響到其他系統，提高容錯率

缺點：

• 系統之間相互獨立， 無法進行相互呼叫
• 系統之間相互獨立， 會有重復的開發任務
• 搭建集群后，實作負載均衡比較復雜

4、分布式架構

當垂直應用越來越多，重復的業務代碼就會越來越多，這時候我們就得考慮將重復的代碼抽取出來，由前端控制層呼叫不同的業務層服務，于是這就產生了新的分布式系統架構，

分布式系統架構把工程拆分成表現層和服務層兩個部分，服務層中包含業務邏輯，表現層只需要處理和頁面的互動，業務邏輯都是呼叫服務層的服務來實作，

如下圖，變現層依然不變該點那里還是哪里，但是有公共的服務層可以相互呼叫；

優點：

• 抽取公共的功能為服務層，提高代碼復用性

缺點：

• 系統間耦合度變高，呼叫關系錯綜復雜，難以維護

5、SOA架構

在分布式架構下，當服務越來越多，容量的評估，小服務資源的浪費等問題逐漸顯現，此時需增加一個治理中心對集群進行實時管理，此時，便引入了SOA（Service Oriented Architecture）架構；

在SOA系統中會有一個服務注冊中心，我們將服務注冊到服務注冊中心中（必須要放在服務注冊中心，中心化的強耦合），他就會一直監控著每一個服務，當某一個服務宕機時服務注冊中心就會將其排除在外不會呼叫，直到該服務正常，這就解決了服務呼叫例外的問題；同時也會根據某個協議進行調整，將一個協議轉為另一個協議，這就解決了各個應用間協議不同的情況；

優點：

• 使用治理中心（ESB\dubbo）解決了服務間呼叫關系的自動調節

缺點：

• 服務間會有依賴關系，一旦某個環節出錯會影響較大( 服務雪崩 )
• 服務關系復雜，運維、測驗部署困難

6、微服務架構

微服務架構就是對之前的架構進行更徹底的細粒度拆分，在某種程度上是面向服務的架構SOA繼續發展的下一步，它更加強調服務的”徹底拆分”，比如之前的一個商品模塊可以拆分為普通商品模塊、特價商品模塊、秒搶商品模塊等等，但是拆分的力度還是要根據業務的復雜度來進行拆分的；同時還引入了治理和協調的微服務組件以及各種組件去解決其它問題，比如服務器雪崩，去中心化啥的；

將每一個模塊都拆分成一個個的服務；

優點：

• 服務原子化拆分，獨立打包、部署和升級，保證每個微服務清晰的任務劃分，利于擴展
• 微服務之間采用Restful等輕量級http協議相互呼叫

缺點：

• 分布式系統開發的技術成本高（容錯、分布式事務等）
• 復雜性更高，各個微服務進行分布式獨立部署，當進行模塊呼叫的時候，將會變得更加麻煩，

7、微服務架構補充

7.1、微服務架構的常見問題

一旦采用微服務系統架構，就勢必會遇到這樣幾個問題：

1. 這么多小服務，如何管理他們？(注冊中心 nacos)
2. 這么多小服務，他們之間如何通訊？(restful rpc dubbo feign)
3. 這么多小服務，客戶端怎么訪問他們？(網關 gateway)
4. 這么多小服務，出現問題，應該如何自處理？(容錯 sentinel)
5. 這么多小服務，出現問題，應該如何排錯? (鏈路追蹤 skywalking)

7.2、微服務架構框架圖

首先從客戶端發送請求，通過負載均衡分發到達對應的網關，實作負載均衡主要是為了減輕網關的壓力；然后網關通過nscos注冊中心獲取服務串列也就是拿到名稱；之后通過熔斷降級（防止發生雪崩之類的問題）找到對應的微服務，然后會采用Feign來進行服務間的呼叫；最后會使用一些OSS、MQ、Redis等等；

7.3、常見的微服務架構

微服務架構只是一種風格，那么我們可以有多種實作方式；

7.3.1、dubbo: zookeeper +dubbo + SpringMVC/SpringBoot

• 配套 通信方式：rpc
• 注冊中心：zookeeper / redis
• 配置中心：diamond

只能實作治理中心，熔斷等并不能實作

7.3.2、SpringCloud：全家桶+輕松嵌入第三方組件(Netflix)

• 配套 通信方式：http restful
• 注冊中心：eruka
• 配置中心：config
• 服務的隔離及斷路器：hystrix
• 網關：zuul
• 分布式追蹤系統：sleuth + zipkin

關于SpringCloud全家桶可以參考我之前發布的文章SpringCloud超詳細筆記（附原始碼）一文；

7.3.3、SpringCloud Alibaba

Spring Cloud Alibaba是對Spring Cloud的標椎實作；他致力于提供微服務開發的一站式解決方案，此專案包含開發微服務架構的必需組件，方便開發者通過 Spring Cloud 編程模型輕松使用這些組件來開發微服務架構，只需要添加一些注解和少量配置，就可以將 Spring Cloud 應用接入阿里分布式應用解決方案，通過阿里中間件來迅速搭建分布式應用系統，

將在下篇中詳細分享SpringCloud Alibaba以及他的環境的搭建；

自此常見系統架構的介紹、演變以及優缺點就分享到這里了，如有欠缺歡迎個位大佬在評論區批評指正！