學習目標

1. 回顧架構的演進。
2. 明確springcloud是什么？
3. 明確spring、springboot和springcloud之間的關系。
4. 了解springcloud的常用組件及其作用。

第1章 架構演進

1、單體架構

我相信，絕大部分同學都用過SSM框架進行過開發，當時你們所在項目組肯定是將所有的功能模塊全部放在了同一個框架里面，只是不同的功能建了一個不同的包，然后所有的功能模塊數據存儲在一個數據庫里面，然后通過一臺Tomcat容器去啟動服務。

這種架構在最開始公司業務量、數據量、并發量小的情況下是沒問題的，甚至對于開發人員更友好。

但是來了，但是隨著你公司的發展，業務量增大，功能需求增多，數據量并發量也增大的時候，單體架構就不行了，為什么呢？

1. 隨著業務量增大，單臺Tomcat很容易達到性能瓶頸，一般的服務器上Tomcat的最大并發量也就在200左右。
2. 因為只有一臺服務器，出現問題就直接掛掉了，此時客戶端都訪問不了服務，這個時候就讓我想起了，讀大學的時候選選修課，每次都要等好幾個小時才能選上，體驗極差。

2、集群架構

為了解決上面的這些問題，必須要從根源上進行優化。此時集群架構出現。

集群架構的邏輯其實很簡單，它就是把整個系統從一臺服務器上部署變成了多臺服務器部署，只是對整個系統的復制拷貝。然后增加Nginx服務器做負載均衡而已。

但是集群架構也存在一些問題：

• 如果系統中的某個很小的功能發生了版本迭代，那這個時候就需要將所有的系統全部停掉，然后進行更新。而且可能整個系統非常龐大了，開發這個大系統的部門人員可能也非常多組織架構也不好管理。
• 雖然你系統做了集群，但是數據庫往往才是制約你系統性能的最大因素，當并發量大了，數據量大了，數據庫是處理不過來的。

3、業務垂直化拆分

針對上面的問題，架構再一次需要改進，整個大系統不適用了，就將不同的功能模塊拆分成小系統。

對業務進行垂直化拆分，簡單來說，就是可以按照系統的業務功能拆分出多個業務模塊子系統。每個子系統由不同的業務團隊負責。

4、服務化改造

隨著對業務系統進行垂直化改造之后，以業務功能緯度拆分出來多個子系統，而在各個子系統中，會存在比較多的共享業務，比如用戶信息查詢，在支付業務中會涉及到、在首頁中也會涉及到。那么勢必會造成重復開發產生非常多的冗余代碼。那么這個時候就引入了服務化改造的思想，也就是 SOA把一些通用的、會被多個上層服務調用的模塊獨立拆分出來，形成一些共享的基礎服務。這些被拆分出來的共享服務相對來說是比較獨立，并且可重用。 比如用戶管理服務，包含用戶注冊、用戶查詢等功能。比如單點登錄服務。

SOA 的核心目標就是通過服務的流程化來實現業務的靈活性，而這個流程化其實就是由一系列相關聯的任務組成，這一系列相關聯的任務可以通過一系列的服務組合來實現具體的業務功能SOA 面向服務架構，從語義上說，它與面向過程、面向對象、面向組件一樣，是一種軟件組建及開發的方式。所以在 SOA 中，服務是最核心的抽象手段，業務被劃分為一些列粗粒度的業務服務和業務流程。

SOA 中更強調 ESB 企業服務總線，企業服務總線可以使得服務之間的交互是動態的，以及服務位置是透明的。這樣的好處是服務的調用者和服務的提供者之間是高度解耦的。從而使得服務有更高的靈活性以及隔離性。

ESB： 是從面相服務架構(SOA)發展過來的，主要是對多個系統中的服務調用者和服務提供者的解耦。ESB 本身提供了服務暴露、接入、協議轉化、數據格式轉化、路由等功能。

SOA 主要解決的問題：

• 信息孤島
• 互聯互通
• 業務重用

5、微服務架構

業務系統實施服務化改造后，原本共享的業務被拆分，形成可復用的服務，可以在最大程度上避免共享業務的重復建設、資源連接瓶頸等問題出現。那么那些被拆分出來的服務，是否也需要以業務功能為維度來進行拆分，使之能夠獨立進行部署，以降低業務藕合和提升容錯性呢？

微服務并不是一種新思想的方法。它更像是一種思想的精煉，是一種服務化思想的最佳實踐方向而已，所以我認為微服務其實是在 SOA 思路下，隨著各個企業對于服務化治理上不斷地完善，以及對軟件的交付鏈路以及基礎設施逐步成熟之下的一種自然的產物。 微服務也是一種面向服務的架構模型，只是它更強調服務的粒度。也就是服務的職責更加單一更加精煉我們也可以把 SOA 看成是微服務的超集。 也就是多個微服務可以組成一個 soa 服務。

6、微服務和 SOA 架構的區別

經常會有同學問，微服務和 SOA 架構有什么區別。這個區別一定要從架構的發展過程來了解。這兩種架構模式，其實本質上應該是在分布式架構這條時間線上，基于服務化思想的不斷完善，以及基礎設施的逐步成熟之下的一種升級。既然存在于時間線的先后，那也就意味著，這兩種架構模式所關注的點不一樣。

第2章 Spring Cloud

上一章講到了架構的演進過程，事實上不管什么架構，都是需要通過合適的框架技術進行落地，從最開始的spring框架，到后來的springboot，再到現在的springcloud，那為什么需要springcloud呢？spring為什么不行呢？

要想整體弄明白這些問題，那我們接下來先弄清楚幾個概念，自己在腦海里面形成一套體系：

1. spring在開發過程中有什么問題？
2. springboot的出現解決了什么？
3. springboot跟springcloud是什么關系
4. springcloud是什么？它包含了什么？

1、spring的問題

事實上spring的出現就是為了簡化開發的，spring的核心概念絕大部分同學都能說出來，無非就是3個，IoC、DI、AOP，下面稍微解釋一下這仨兄弟是干嘛的。

• IoC實際上就是一個容器，它就是用來裝Bean對象的；回到最最基礎的層面，我們java開發就是在不斷的通過new創建對象，然后拿到對象之后調用對象里面的方法。OK，那在實際開發過程中，如果所有的對象都需要手動去創建將是一個非常繁瑣的過程，也許你有1萬個類，然后這1萬個類在各種地方都要創建對象，這個時候假設用到了A類的對象，然后你在B類中new了對象，如果要在C、D、E等等類中要用到這個對象的話，將會很麻煩，這只是一種情況，在開發中這種類似的現象隨處可見，所以spring為了解決這個過程，設計了一個IoC的功能，你就理解成一個中心容器，用來裝項目中幾乎所有需要用到的Bean對象。
• IoC的概念理解了，那么這個時候你要想，對象創建了，但是對象里面可能會存在別的一些成員屬性，而這些成員屬性又是另外的一些對象，舉個例子就是A對象里面有個成員屬性是B對象，那這個時候你要去進行引用的關聯，這一步也非常麻煩和繁瑣，怎么辦呢？spring的DI幫你完成了，在A對象new的過程中，spring就會去中心容器找有沒有B對象，有的話就把這個B對象賦值給A對象的屬性。
• AOP的概念其實更好理解，它是基于動態代理完成的，你們要清晰的指導，代理就是做增強的，什么意思呢？假設有一個對象的業務功能就是創建訂單，OK，那我不想直接調用這個對象的創建訂單功能，我想在創建訂單之前和之后干點別的事情，比如說打印日志這個事，這個時候就用到了代理。

OK，spring基于這仨兄弟確實簡化了很多開發的流程，但是，在最開始的過程中spring在進行IoC注入對象的過程中，它是基于XML方式的，這個邏輯很容易理解，就是你要把什么對象放到容器中去，只需要在XML文件中配置一下就好了。

但是，正因為這個，使得spring變的無比的繁瑣，你想想，一個項目中得用到多少個對象，每個對象都去配置一下，完犢子了。要寫無數個XML文件了。

spring開始發力，要優化了，引入注解，但是沒用啊，如果你項目要集成別的組件呢？比如redis，比如mybatis。甚至在微服務項目中要引入集成各種組件的話，那更加崩潰。

其實歸根結底，spring還是沒有解決IoC注入的復雜流程，以及外部化配置的統一管理。

2、springboot

看過springboot源碼的同學都知道，springboot底層其實會走一遍spring的流程。也就是springboot依賴于spring，同時它也在spring的基礎之上作了一些工作。

具體作了啥，實際上就是解決IoC自動注入和配置統一管理，使得這個工作不再需要程序員去做了，框架自己干了。具體怎么解決的參照之前的內容。

3、springcloud生態

先明確springcloud是什么？網上都說，啊呀springcloud就是做微服務的，它是一個生態啊等等。進說一些我們聽不懂的。

那我這里用最簡單的語言去解釋一下：

springcloud就是springboot集成各種各樣starter組件的一個集體，springcloud底層核心框架就是springboot，然后springboot集成不同組件的時候不需要程序員去寫XML文件以及配置文件了，而是一些好事之徒，他們基于springboot自動裝配原理寫了starter組件，然后將這些starter組件和springboot的整體我們給了一個名字叫做springcloud。

明白了吧，那知道springcloud是什么之后，在來看這個生態里面包含了啥，springboot我知道了，starter組件有哪些呢？

這個不用去背，我們自己根據數據流向從整體上去串一串就好了，當你串明白了，那你離架構師就不是太遠了。

（1）網關

Gateway組件

我們知道 spring cloud 可以用來開發微服務，但是應該很少有同學真正知道 spring cloud 是什么。

官方的解釋是：spring cloud 提供了一些可以讓開發者快速構建分布式應用的工具，這些服務可以很好的工作在任何分布式環境下。

既然提供的是一些快速構建微服務應用的工具，那么我們需要了解微服務開發過程中需要解決哪些問題？

在微服務實施之后，各個服務的拆分粒度很小，對于客戶端來說，做一個操作可能會涉及到后端的多個服務組件的調用，那意味著它需要頻繁的發起多次訪問才能進行數據聚合實現用戶的功能。

如果我們在所有的微服務之前增加一個網關，對于客戶端來說它需要做什么功能操作直接調用網關并且告訴網關所要做的事情即可，網關根據請求的功能對后端的多個服務的數據進行聚合聚合哦從而減少客戶端的調用頻次。

并且，由于有了網關的聚合，我們還可以在網關層對請求進行統一鑒權和認證； 包括還可以實現限流、請求日志統一記錄、 灰度發布等等。

（2）遠程通信

Openfeign、Dubbo

服務拆分以后就會涉及到服務的遠程通信，比如 http 協議或者 rpc 協議。

（3）服務發現

Eureka、Nacos

在滿足基礎通信的基礎上，如何做到服務的統一管理以及服務的動態感知，就需要涉及到服務的注冊中心來實現服務注冊和發現的功能。

（4）負載均衡

Ribbon、Dubbo

假設服務提供者為了擴大吞吐量，采用 10 臺機器的集群部署，這個時候客戶端從注冊中心獲得服務以后，應該調用哪臺機器呢？

所以必然有一種負載均衡的機制，來實現客戶端請求的分發。

（5）熔斷、限流、降級

Hystrix、Sentinel

在分布式架構中，各個服務節點一定需要滿足高可用，所以對于服務本身來說，一方面是在有準備的前提下做好充足的擴容。另一方面，服務需要有熔斷、限流、降級的能力。

當一個服務調用另外一個服務，可能因為網絡原因、或者連接池滿等問題導致頻繁出現錯誤，需要有一種熔斷機制，來防止因為請求堆積導致整個應用雪崩。

當發現整個系統的確負載過高的時候，可以選擇降級某些功能或某些調用，保證最重要的交易流程的通過，以及最重要的資源全部用于保證最核心的流程。

在設置了熔斷以及降級策略后，還有一種手段來保護系統，就是限流算法。

我們能夠通過全鏈路壓測了解到整個系統的吞吐量，但實際上的流量可能會超過我們預期的值，比如存在惡意攻擊、或者突然的高峰流量。在這種情況下可以通過限流來保護系統不崩潰，但是對于部分用戶來說，會出現被限流導致體驗不好的情況。

（6）配置中心

Config、Nacos

服務拆分以后，服務的數量非常多，如果所有的配置都以配置文件的方式放在應用本地的話，非常難以管理，可以想象當有幾百上千個進程中有一個配置出現了問題，是很難將它找出來的，因而需要有統一的配置中心，來管理所有的配置，進行統一的配置下發。

在微服務中，配置往往分為幾類，一類是幾乎不變的配置，這種配置可以直接打在容器鏡像里面，第二類是啟動時就會確定的配置，這種配置往往通過環境變量，在容器啟動的時候傳進去，第三類就是統一的配置，需要通過配置中心進行下發，例如在大促的情況下，有些功能需要降級，哪些功能可以降級，哪些功能不能降級，都可以在配置文件中統一配置。

（7）分布式事務

Seata

對于數據庫的垂直拆分，已經服務的拆分，單體的數據庫事務完全不能滿足需求了，這個時候就需要一個第三方的協調工具來做到統一管理事務提交回滾等操作，這個時候Seata出現了。

4、服務帶來的問題

（1）業務團隊的痛點

1. 對于業務開發團隊而言，最強的是技術嗎？一定不是，業務團隊最強的一定是對于業務的理解和熟悉程度。
2. 而業務應用的核心價值，就是為了實現業務場景，而不是寫微服務，微服務只是一種實現業務的手段。
3. 業務團隊除了關心業務之外，他們所面臨的最大的挑戰在于，如何保證系統的穩定性何可擴展性、如何設計一個安全的 open api。如果對服務進行拆分、如何保證跨庫的數據一致性。以及對于舊系統的改造。
4. 于公司層面而言，業務團隊的壓力還來自于時間人力的投入，我們用于被各種 deadline 趕著走。所以作為一個業務程序員，如果在這個 deadline 之前還需要花更多的時間投入在spring cloud 這些工具的學習上，那無疑是雪上加霜。公司對于業務團隊的考核，永遠只看結果！

（2）跨語言帶來的問題

微服務有一個很重要的特性，就是不同的微服務可以采用自己最擅長的語言來編寫程序。這種特性在企業中落地的時候又會帶來一些問題。

比如公司內部會開發一些公共的類庫或者框架，也或者會使用第三方的類庫或者框架來實現某些功能。

但是由于公司的微服務用了各種各樣的語言，那意味著這些類庫需要針對不同的語言開發兼容版本。如果是主流語言還好，如果是一些小眾語言，那對于這些基礎組件的開發者而言無疑是晴天霹靂.

（3）總結

從這些痛點中可以發現，我們所做的所有非業務類的事情，都是為了保證把請求發送到正確的地方，并且能夠及時或得正確的結果。那對于對于業務開發人員而言，是否有必要去關心這些呢？

回到最開始我們說的一個例子，在進行計算機網絡通信的時候，開發人員有必要去關心網絡通信的細節嗎？ 我們在使用 http 協議進行數據傳輸時，關心過底層是使用 TCP 還是 udp？數據是怎么傳輸的？

既然我們不需要關心這些，那對于微服務架構中的這些問題，業務開發人員為什么一定要關心服務的通訊呢？