2021-07-28(微服務的概念)

1.1 單體、分布式、集群

我們學習微服務之前,需要先理解單體、集群、分布式這些概念，這樣會幫助我們在學習后面知識會更加容易些.

單體

一個系統業務量很小的時候所有的代碼都放在一個專案中就好了，然后這個專案部署在一臺服務器上就好了，整個專案所有的服務都由這臺服務器提供，這就是單機結構，

單體應用開發簡單,部署測驗簡單.但是存在一些問題,比如:單點問題,單機處理能力有限,當你的業務增長到一定程度的時候，單機的硬體資源將無法滿足你的業務需求，

分布式

由于整個系統運行需要使用到Tomcat和MySQL，單臺服務器處理的能力有限,2G的記憶體需要分配給Tomcat和MySQL使用，，隨著業務越來越復雜，請求越來越多. 記憶體越來越不夠用了，所以這時候我們就需要進行分布式的部署.

我們進行一個評論的請求，這個請求是需要依賴分布在兩臺不同的服務器的組件[Tomat和MySQL],才能完成的. 所以叫做分布式的系統.

集群

在上面的圖解中其實是存在問題的，比如Tomcat存在單點故障問題，一旦Tomcat所在的服務器宕機不可用了，我們就無法提供服務了,所以針對單點故障問題，我們會使用集群來解決.那什么是集群模式呢?

單機處理到達瓶頸的時候，你就把單機復制幾份，這樣就構成了一個“集群”，集群中每臺服務器就叫做這個集群的一個“節點”，所有節點構成了一個集群，每個節點都提供相同的服務，那么這樣系統的處理能力就相當于提升了好幾倍（有幾個節點就相當于提升了這么多倍），

但問題是用戶的請求究竟由哪個節點來處理呢？最好能夠讓此時此刻負載較小的節點來處理，這樣使得每個節點的壓力都比較平均，要實作這個功能，就需要在所有節點之前增加一個“調度者”的角色，用戶的所有請求都先交給它，然后它根據當前所有節點的負載情況，決定將這個請求交給哪個節點處理，這個“調度者”有個牛逼了名字——負載均衡服務器，
我們在上面的圖中僅展示了Tomcat的集群，如果MySQL壓力比較大的情況下，我們也是可以對MySQL進行集群的.

1.2 系統架構演變

隨著互聯網的發展，網站應用的規模也不斷的擴大，進而導致系統架構也在不斷的變化，

從互聯網早起到現在，系統架構大體經歷了下面幾個程序: 單體應用架構—>垂直應用架構—>分布

式架構—>微服務架構，

接下來我們就來了解一下每種系統架構是什么樣子的， 以及各有什么優缺點，

優點：

• 專案架構簡單，小型專案的話， 開發成本低

• 專案部署在一個節點上， 維護方便

缺點：

• 全部功能集成在一個工程中，對于大型專案來講不易開發和維護

• 專案模塊之間緊密耦合，單點容錯率低

• 無法針對不同模塊進行針對性優化和水平擴展

1.2.1 單體應用架構

互聯網早期，一般的網站應用流量較小，只需一個應用，將所有功能代碼都部署在一起就可以，這

樣可以減少開發、部署和維護的成本，

? 比如說一個電商系統，里面會包含很多用戶管理，商品管理，訂單管理，物流管理等等很多模塊，

我們會把它們做成一個web專案，然后部署到一臺tomcat服務器上，

1.2.2 垂直應用架構

隨著訪問量的逐漸增大，單一應用只能依靠增加節點來應對，但是這時候會發現并不是所有的模塊

都會有比較大的訪問量.

? 還是以上面的電商為例子， 用戶訪問量的增加可能影響的只是用戶和訂單模塊， 但是對訊息模塊

的影響就比較小. 那么此時我們希望只多增加幾個訂單模塊， 而不增加訊息模塊. 此時單體應用就做不

到了， 垂直應用就應運而生了.

? 所謂的垂直應用架構，就是將原來的一個應用拆成互不相干的幾個應用，以提升效率，比如我們可

以將上面電商的單體應用拆分成:

• 電商系統(用戶管理 商品管理 訂單管理)

• 后臺系統(用戶管理 訂單管理 客戶管理)

• CMS系統(廣告管理 營銷管理)

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

和CMS的節點，

優點：

• 系統拆分實作了流量分擔，解決了并發問題，而且可以針對不同模塊進行優化和水平擴展

• 一個系統的問題不會影響到其他系統，提高容錯率

缺點：

• 系統之間相互獨立， 無法進行相互呼叫

• 系統之間相互獨立， 會有重復的開發任務

1.2.3 分布式架構

當垂直應用越來越多，重復的業務代碼就會越來越多，這時候，我們就思考可不可以將重復的代碼

抽取出來，做成統一的業務層作為獨立的服務，然后由前端控制層呼叫不同的業務層服務呢？

? 這就產生了新的分布式系統架構，它將把工程拆分成表現層和服務層兩個部分，服務層中包含業務

邏輯，表現層只需要處理和頁面的互動，業務邏輯都是呼叫服務層的服務來實作，

優點：

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

缺點：

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

1.2.4 微服務架構

微服務架構在某種程度上是面向服務的架構，它更加強調服務的"徹底拆分"，

優點：

• 服務原子化拆分，獨立打包、部署和升級，保證每個微服務清晰的任務劃分，利于擴展

• 微服務之間采用RESTful等輕量級Http協議相互呼叫

缺點：

• 分布式系統開發的技術成本高（容錯、分布式事務等）

1.3 微服務架構介紹

微服務架構， 簡單的說就是將單體應用進一步拆分，拆分成更小的服務，每個服務都是一個可以獨

立運行的專案，

微服務架構的常見問題

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

• 這么多小服務，如何管理他們？

• 這么多小服務，他們之間如何通訊？

• 這么多小服務，客戶端怎么訪問他們？

• 這么多小服務，一旦出現問題了，應該如何自處理？

• 這么多小服務，一旦出現問題了，應該如何排錯?

對于上面的問題，是任何一個微服務設計者都不能繞過去的，因此大部分的微服務產品都針對每一

個問題提供了相應的組件來解決它們，

1.4 SpringCloud介紹

Spring Cloud是一系列框架的集合，它利用Spring Boot的開發便利性巧妙地簡化了分布式系統基礎設施的開發，如服務發現注冊、配置中心、訊息總線、負載均衡、斷路器、資料監控等，都可以用Spring Boot的開發風格做到一鍵啟動和部署，

Spring Cloud并沒有重復制造輪子，它只是將目前各家公司開發的比較成熟、經得起實際考驗的服務框架組合起來，通過Spring Boot風格進行再封裝屏蔽掉了復雜的配置和實作原理，最終給開發者留出了一套簡單易懂、易部署和易維護的分布式系統開發工具包，

1.4.1 SpringBoot和SpringCloud有啥關系?

• SpringBoot專注于快速方便的開發單個個體微服務，

• SpringCloud是關注全域的微服務協調整理治理框架，它將SpringBoot開發的一個個單體微服務整合并管理起來，為各個微服務之間提供，配置管理、服務發現、斷路器、路由、事件總線、分布式事務、等等集成服務，

總結: SpringBoot專注于快速、方便的開發單個微服務個體，SpringCloud關注全域的服務治理組件的集合，

1.4.2 SpringCloud版本名稱?

因為Spring Cloud不同其他獨立專案，它是擁有很多子專案的大專案，所以它是的版本是 版本名+版本號 （如Greenwich.SR6），
版本名：是倫敦的地鐵名
版本號：SR（Service Releases）是固定的 ,大概意思是穩定版本，后面會有一個遞增的數字，
所以 Greenwich.SR6就是Greenwich的第6個Release版本，

1.4.3 為什么選擇SpringCloud Alibaba？

我們這里為什么選擇SpringCloud Alibaba呢，主要因為SpringCloud Netflix的組件：服務注冊與發現的 Eureka、服務限流降級的 Hystrix、網關 Zuul都已經停止更新了，當然繼續使用是沒問題的，只是出現問題，官方不維護，需要自行解決.