一文章帶你瞭解微服務

 

1、由來：

單體應用-->SOA-->微服務

1.1、單體應用

概念：所有功能全部打包在一起。應用大部分是一個war包或jar包。例如：一個乘客專案中有 使用者、訂單、訊息、地圖等功能。隨著業務發展，功能增多，這個專案會越來越臃腫。

好處：容易開發、測試、部署，適合專案初期試錯。

壞處：
- 複雜性高：程式碼多，十萬行，百萬行級別。加一個小功能，會帶來其他功能的隱患，因為它們在一起。
- 技術債務：人員流動，不壞不修，因為不敢修。
- 持續部署困難：由於是全量應用，改一個小功能，全部部署，會導致無關的功能暫停使用。編譯部署上線耗時長，不敢隨便部署，導致部署頻率低，進而又導致兩次部署之間 功能修改多，越不敢部署，惡性迴圈。
- 可靠性差：某個小問題，比如小功能出現OOM，會導致整個應用崩潰。
- 擴充套件受限：只能整體擴充套件，無法按照需要進行擴充套件，不能根據計算密集型（派單系統）和IO密集型（檔案服務） 進行合適的區分。
- 阻礙創新：單體應用是以一種技術解決所有問題，不容易引入新技術。但在高速的網際網路發展過程中，適應的潮流是：用合適的語言做合適的事情。比如在單體應用中，一個專案用spring MVC，想換成spring boot，切換成本很高，因為有可能10萬，百萬行程式碼都要改，而微服務可以輕鬆切換，因為每個服務，功能簡單，程式碼少。

1.2、SOA

對單體應用的改進：引入SOA（Service-Oriented Architecture）面向服務架構，拆分系統，用服務的流程化來實現業務的靈活性。服務間需要某些方法進行連線，面向介面等，它是一種設計方法，其中包含多個服務， 服務之間通過相互依賴最終提供一系列的功能。一個服務 通常以獨立的形式存在於作業系統程式中。各個服務之間 通過網路呼叫。但是還是需要用些方法來進行服務組合，有可能還是個單體應用。

1.3、微服務

- 無嚴格定義。
- 微服務是一種架構風格，將單體應用劃分為小型的服務單元。
- 微服務架構是一種使用一系列粒度較小的服務來開發單個應用的方式；每個服務執行在自己的程式中；服務間採用輕量級的方式進行通訊(通常是HTTP API)；這些服務是基於業務邏輯和範圍，通過自動化部署的機制來獨立部署的，並且服務的集中管理應該是最低限度的，即每個服務可以採用不同的程式語言編寫，使用不同的資料儲存技術。

2、微服務特性

- 獨立執行在自己程式中。
- 一系列獨立服務共同構建起整個系統。
- 一個服務只關注自己的獨立業務。
- 輕量的通訊機制RESTful API
- 使用不同語言開發
- 全自動部署機制

3、微服務元件

- 服務註冊與發現：服務提供方將己方呼叫地址註冊到服務註冊中心，讓服務呼叫方能夠方便地找到自己；服務呼叫方從服務註冊中心找到自己需要呼叫的服務的地址。

- 負載均衡：服務提供方一般以多例項的形式提供服務，負載均衡功能能夠讓服務呼叫方連線到合適的服務節點。並且，服務節點選擇的過程對服務呼叫方來說是透明的。

- 服務閘道器：服務閘道器是服務呼叫的唯一入口，可以在這個元件中實現使用者鑑權、動態路由、灰度釋出、A/B測試、負載限流等功能。

  灰度釋出（又名金絲雀釋出）是指在黑與白之間，能夠平滑過渡的一種釋出方式。在其上可以進行A/B testing，即讓一部分使用者繼續用產品特性A，一部分使用者開始用產品特性B，如果使用者對B沒有什麼反對意見，那麼逐步擴大範圍，把所有使用者都遷移到B上面來。灰度釋出可以保證整體系統的穩定，在初始灰度的時候就可以發現、調整問題，以保證其影響度。  

- 配置中心：將本地化的配置資訊(Properties、XML、YAML等形式)註冊到配置中心，實現程式包在開發、測試、生產環境中的無差別性，方便程式包的遷移，也是無狀態特性。

- 整合框架：微服務元件都以職責單一的程式包對外提供服務，整合框架以配置的形式將所有微服務元件(特別是管理端元件)整合到統一的介面框架下，讓使用者能夠在統一的介面中使用系統。Spring Cloud就是一個整合框架。

- 呼叫鏈監控：記錄完成一次請求的先後銜接和呼叫關係，並將這種序列或並行的呼叫關係展示出來。在系統出錯時，可以方便地找到出錯點。

- 支撐平臺：系統微服務化後，各個業務模組經過拆分變得更加細化，系統的部署、運維、監控等都比單體應用架構更加複雜，這就需要將大部分的工作自動化。現在，Docker等工具可以給微服務架構的部署帶來較多的便利，例如持續整合、藍綠髮布、健康檢查、效能監控等等。如果沒有合適的支撐平臺或工具，微服務架構就無法發揮它最大的功效。

  1. 藍綠部署是不停老版本，部署新版本然後進行測試，確認OK，將流量切到新版本，然後老版本同時也升級到新版本。
  2. 灰度是選擇部分部署新版本，將部分流量引入到新版本，新老版本同時提供服務。等待灰度的版本OK，可全量覆蓋老版本。
  灰度是不同版本共存，藍綠是新舊版本切換，2種模式的出發點不一樣。

4、微服務優點

1. 獨立部署。不依賴其他服務，耦合性低，不用管其他服務的部署對自己的影響。
2. 易於開發和維護：關注特定業務，所以業務清晰，程式碼量少，模組變的易開發、易理解、易維護。
3. 啟動塊：功能少，程式碼少，所以啟動快，有需要停機維護的服務，不會長時間暫停服務。
4. 區域性修改容易：只需要部署 相應的服務即可，適合敏捷開發。
5. 技術棧不受限：java，node.js等
6. 按需伸縮：某個服務受限，可以按需增加記憶體，cpu等。
7. 職責專一。專門團隊負責專門業務，有利於團隊分工。
8. 程式碼複用。不需要重複寫。底層實現通過介面方式提供。
9. 便於團隊協作：每個團隊只需要提供API就行，定義好API後，可以並行開發。

5、 微服務缺點

1. 分散式固有的複雜性：容錯（某個服務當機），網路延時，呼叫關係、分散式事務等，都會帶來複雜。
2. 分散式事務的挑戰：每個服務有自己的資料庫，優點在於不同服務可以選擇適合自身業務的資料庫。訂單用MySQL，評論用Mongodb等。目前最理想解決方案是：柔性事務的最終一致性。
   ```sh
   剛性事務：遵循ACID原則，強一致性。
   柔性事務：遵循BASE理論，最終一致性；與剛性事務不同，柔性事務允許一定時間內，不同節點的資料不一致，但要求最終一致。
   BASE 是 Basically Available(基本可用)、Soft state(軟狀態)和 Eventually consistent (最終一致性)三個短語的縮寫。BASE理論是對CAP中AP的一個擴充套件，通過犧牲強一致性來獲得可用性，當出現故障允許部分不可用但要保證核心功能可用，允許資料在一段時間內是不一致的，但最終達到一致狀態。滿足BASE理論的事務，我們稱之為“柔性事務”。
   ```
3. 介面調整成本高：改一個介面，呼叫方都要改。
4. 測試難度提升：一個介面改變，所有呼叫方都得測。自動化測試就變的重要了。API文件的管理也尤為重要。推薦：yapi。
5. 運維要求高：需要維護 幾十 上百個服務。監控變的複雜。並且還要關注多個叢集，不像原來單體，一個應用正常執行即可。
6. 重複工作：比如java的工具類可以在共享common.jar中，但在多語言下行不通，C++無法直接用java的jar包。

6、設計原則

單一職責原則：關注整個系統功能中單獨，有界限的一部分。

服務自治原則：可以獨立開發，測試，構建，部署，執行，與其他服務解耦。

輕量級通訊原則：輕，跨平臺，跨語言。REST,AMQP 等。

粒度把控：與自己實際相結合。 不要追求完美，隨業務進化而調整。

7、Spring Cloud

概念：

Spring Cloud是實現微服務架構的一系列框架的有機集合。

是在Spring Boot基礎上構建的，用於簡化分散式系統構建的工具集。是擁有眾多子專案的專案集合。利用Spring Boot的開發便利性，巧妙地簡化了分散式系統基礎設施（服務註冊與發現、熔斷機制、閘道器路由、配置中心、訊息匯流排、負載均衡、鏈路追蹤等）的開發。

整體架構：

1. 服務註冊與發現元件：Eureka，Zookeeper，Consul,Nacos等。Eureka基於REST風格的。
2. 服務呼叫元件：Hystrix(熔斷降級，在出現依賴服務失效的情況下，通過隔離 系統依賴服務  的方式，防止服務級聯失敗，同時提供失敗回滾機制，使系統能夠更快地從異常中恢復)，Ribbon（客戶端負載均衡，用於提供客戶端的軟體負載均衡演算法，提供了一系列完善的配置項：連線超時、重試等），OpenFeign（優雅的封裝Ribbon，是一個宣告式RESTful網路請求客戶端，它使編寫Web服務客戶端變得更加方便和快捷）。
3. 閘道器：路由和過濾。Zuul，Gateway。
4. 配置中心：提供了配置集中管理，動態重新整理配置的功能；配置通過Git或Mysql等其他方式來儲存。
5. 訊息元件：Spring Cloud Stream（對分散式訊息進行抽象，包括髮布訂閱、分組消費等功能，實現了微服務之間的非同步通訊）和Spring Cloud Bus（主要提供服務間的事件通訊，如重新整理配置）
6. 安全控制元件：Spring Cloud Security 基於OAuth2.0開放網路的安全標準，提供了單點登入、資源授權和令牌管理等功能。
7. 鏈路追蹤元件：Spring Cloud Sleuth（收集呼叫鏈路上的資料），Zipkin（對Sleuth收集的資訊，進行儲存，統計，展示）。

Spring Cloud目前只是Java世界中微服務實踐的最佳落地方案，是一個基於Spring Boot的服務治理工具包。並不能代表微服務或者微服務架構。

微服務是一種架構理念：重點是微服務設計原則，不用Spring cloud也能實現微服務，重在架構理念。