第一章 微服務介紹
1.1 系統架構演變
随着網際網路的發展，網站應用的規模也在不斷的擴大，進而導緻系統架構也在不斷的進行變化。從互聯 網早起到現在，系統架構大體經曆了下面幾個過程:
單體應用架構—>垂直應用架構—>分布式架構—>SOA架構—>微服務架構
當然還有悄然興起的Service Mesh(服務網格化)。接下來我們就來了解一下每種系統架構是什麼樣子的， 以及各有什麼優缺點。
1.1.1 單體應用架構
網際網路早期，一般的網站應用流量較小，隻需一個應用，将所有功能代碼都部署在一起就可以，這樣可 以減少開發、部署和維護的成本。
[外鍊圖檔轉存失敗,源站可能有防盜鍊機制,建議将圖檔儲存下來直接上傳(img-vUNzD2y2-1624961554394)(file:///C:\Users\ADMINI~1\AppData\Local\Temp\ksohtml13028\wps3.jpg)]
比如說一個電商系統，裡面會包含很多使用者管理，商品管理，訂單管理，物流管理等等很多子產品，我們 會把它們做成一個web項目，然後部署到一台tomcat伺服器上。
優點
項目架構簡單，小型項目的話， 開發成本低
項目部署在一個節點上， 維護友善
缺點：
全部功能內建在一個工程中，對于大型項目來講不易開發和維護項目子產品之間緊密耦合，單點容錯率低
無法針對不同子產品進行針對性優化和水準擴充
1.1.2 垂直應用架構
随着通路量的逐漸增大，單一應用隻能依靠增加節點來應對，但是這時候會發現并不是所有的子產品都會 有比較大的通路量。
還是以上面的電商為例子， 使用者通路量的增加可能影響的隻是使用者和訂單子產品， 但是對消息子產品
的影響就比較小. 那麼此時我們希望隻多增加幾個訂單子產品， 而不增加消息子產品. 此時單體應用就做不到了， 垂直應用就應運而生了。
所謂的垂直應用架構，就是将原來的一個應用拆成互不相幹的幾個應用，以提升效率。比如我們可 以将上面電商的單體應用拆分成:
電商系統(使用者管理 商品管理 訂單管理) 背景系統(使用者管理 訂單管理 客戶管理) CMS系統(廣告管理 營銷管理)
這樣拆分完畢之後，一旦使用者通路量變大，隻需要增加電商系統的節點就可以了，而無需增加背景 和CMS的節點。
1.1.3 分布式架構
當垂直應用越來越多，重複的業務代碼就會越來越多。這時候，我們就思考可不可以将重複的代碼抽取 出來，做成統一的業務層作為獨立的服務，然後由前端控制層調用不同的業務層服務呢？這就産生了新 的分布式系統架構。它将把工程拆分成表現層和服務層兩個部分，服務層中包含業務邏輯。表現層隻需 要處理和頁面的互動，業務邏輯都是調用服務層的服務來實作。
優點：
- 抽取公共的功能為服務層，提高代碼複用性
缺點：
- 系統間耦合度變高，調用關系錯綜複雜，難以維護
1.1.4 SOA架構
在分布式架構下，當服務越來越多，容量的評估，小服務資源的浪費等問題逐漸顯現，此時需增加一個 排程中心對叢集進行實時管理。此時，用于資源排程和治理中心(SOA Service OrientedArchitecture， 面向服務的架構)是關鍵。
優點
- 使用注冊中心解決了服務間調用關系的自動調節
缺點
- 服務間會有依賴關系，一旦某個環節出錯會影響較大( 服務雪崩 )
- 服務關心複雜，運維、測試部署困難
1.1.5 微服務架構
微服務架構在某種程度上是面向服務的架構SOA繼續發展的下一步，它更加強調服務的"徹底拆分"。
優點：
- 服務原子化拆分，獨立打包、部署和更新，保證每個微服務清晰的任務劃分，利于擴充 微服務之間采用Restful等輕量級http協定互相調用
缺點：
- 分布式系統開發的技術成本高（容錯、分布式事務等）
1.2 微服務架構介紹
微服務架構， 簡單的說就是将單體應用進一步拆分，拆分成更小的服務，每個服務都是一個可以獨立運作的項目。
1.2.1 微服務架構的常見問題
一旦采用微服務系統架構，就勢必會遇到這樣幾個問題：
- 這麼多小服務，如何管理他們？(服務治理 注冊中心[服務注冊 發現 剔除])
- 這麼多小服務，他們之間如何通訊？(restful rpc)
- 這麼多小服務，用戶端怎麼通路他們？(網關)
- 這麼多小服務，一旦出現問題了，應該如何自處理？(容錯)
- 這麼多小服務，一旦出現問題了，應該如何排錯? (鍊路追蹤)
對于上面的問題，是任何一個微服務設計者都不能繞過去的，是以大部分的微服務産品都針對每一個問 題提供了相應的元件來解決它們。
1.2.2 微服務架構的常見概念
1.2.2.1 服務治理
服務治理就是進行服務的自動化管理，其核心是服務的自動注冊與發現。
服務注冊：服務執行個體将自身服務資訊注冊到注冊中心。
服務發現：服務執行個體通過注冊中心，擷取到注冊到其中的服務執行個體的資訊，通過這些資訊去請求它們提 供的服務。
服務剔除：服務注冊中心将出問題的服務自動剔除到可用清單之外，使其不會被調用到。
1.2.2.2 服務調用
在微服務架構中，通常存在多個服務之間的遠端調用的需求。目前主流的遠端調用技術有基于HTTP的
RESTful接口以及基于TCP的RPC協定。
REST(Representational State Transfer)：這是一種HTTP調用的格式，更标準，更通用，無論哪種語言都支援http協定
RPC（Remote Promote Call）：一種程序間通信方式。允許像調用本地服務一樣調用遠端服務。RPC架構的主要目标就是讓遠端服務調用更簡單、透明。RPC架構負責屏蔽底層的傳輸方式、序列 化方式和通信細節。開發人員在使用的時候隻需要了解誰在什麼位置提供了什麼樣的遠端服務接口 即可，并不需要關心底層通信細節和調用過程。
差別與聯系
| 比較項 | RESTful | RPC |
|---|---|---|
| 通訊協定 | HTTP | 一般使用TCP |
| 性能 | 略低 | 較高 |
| 靈活度 | 高 | 較高 |
| 應用 | 微服務架構 | SOA架構 |
1.2.2.3 服務網關
随着微服務的不斷增多，不同的微服務一般會有不同的網絡位址，而外部用戶端可能需要調用多個服務 的接口才能完成一個業務需求，如果讓用戶端直接與各個微服務通信可能出現：
- 用戶端需要調用不同的url位址，增加難度在一定的場景下，存在跨域請求的問題
- 每個微服務都需要進行單獨的身份認證
針對這些問題，API網關順勢而生。
API網關直面意思是将所有API調用統一接入到API網關層，由網關層統一接入和輸出。
一個網關的基本功能有：統一接入、安全防護、協定适配、流量管控、長短連結支援、容錯能力。
有了網關之後，各個API服務提供團隊可以專注于自己的的業務邏輯處理，而API網關更專注于安全、流量、路由等問題。
1.2.2.4 服務容錯
在微服務當中，一個請求經常會涉及到調用幾個服務，如果其中某個服務不可用，沒有做服務容錯的 話，極有可能會造成一連串的服務不可用，這就是雪崩效應。我們沒法預防雪崩效應的發生，隻能盡可 能去做好容錯。服務容錯的三個核心思想是：
- 不被外界環境影響
- 不被上遊請求壓垮
- 不被下遊響應拖垮
1.2.2.5 鍊路追蹤
随着微服務架構的的流行，微服務按照不同的次元進行拆分，一次請求往往需要涉及到多個服務。網際網路應 用建構在不同的軟體子產品集上，這些軟體子產品，有可能是由不同的團隊開發、可能使用不同的程式設計語言 來實作、有可能布在了幾千台伺服器，橫跨多個不同的資料中心。是以，就需要對一次請求涉及的多個 服務鍊路進行日志記錄，性能監控即鍊路追蹤
1.2.3 微服務架構的常見解決方案
1.2.3.1 ServiceComb
ApacheServiceComb，前身是華為雲的微服務引擎CSE(CloudService Engine) 雲服務，是全球首個 Apache微服務頂級項目。它提供了一站式的微服務開源解決方案，緻力于幫助企業、使用者和開發者将 企業應用輕松微服務化上雲，并實作對微服務應用的高效運維管理。
1.2.3.2 SpringCloud
Spring Cloud是一系列架構的集合。它利用Spring Boot的開發便利性巧妙地簡化了分布式系統基礎設施的開發，如服務發現注冊、配置中心、消息總線、負載均衡、斷路器、資料監控等，都可以用Spring Boot的開發風格做到一鍵啟動和部署。
Spring Cloud并沒有重複制造輪子，它隻是将目前各家公司開發的比較成熟、經得起實際考驗的服務架構組合起來，通過Spring Boot風格進行再封裝屏蔽掉了複雜的配置和實作原理，最終給開發者留出了一套簡單易懂、易部署和易維護的分布式系統開發工具包。
1.2.3.3 SpringCloud Alibaba
Spring Cloud Alibaba 緻力于提供微服務開發的一站式解決方案。此項目包含開發分布式應用微服務的必需元件，友善開發者通過 Spring Cloud 程式設計模型輕松使用這些元件來開發分布式應用服務。