微服務框架實踐——學習筆記

阿新 • • 發佈：2018-12-12

微服務實戰（一）：微服務架構的優勢與不足

每個服務單獨使用一個database,這為資料庫CAP帶來挑戰. 例如,一個使用者完成一筆消費,同時影響購物車/推薦系統/評論系統等的資料.在單體式應用容易實現一致性,分散式微服務必須使用RPC或訊息佇列等通訊機制,開銷增大.

微服務實戰（二）：使用API Gateway

客戶端到微服務直接通訊

問題1: 客戶端的需求量與每個微服務暴露的細粒度API數量的不匹配. 每個服務使用一個URL,一個client的WEB UI或者APP需要發起數十個HTTP請求,網路開銷大.

問題2: 後端微服務的重構都需要客戶端進行改動,特別是將一個微服務拆分成多個時,前端改動大.

採用一個API Gateway

使用一個GATEWAY為客戶端統一服務.

GATEWAY還可能有其他功能，如授權、監控、負載均衡、快取、請求分片和管理、靜態響應處理等.

實現: GATEWAY以單個頁面的需求進行定製化,選擇性地挑選頁面需要的服務,對客戶端封裝呼叫服務的過程,API GATEWAY是一個粗粒度的REST API.

API Gateway的優點和缺點

難點: 保證API GATEWAY的高可用.API GATEWAY作為統一入口,需要負擔高效能和可拓展的責任.

採用反應性程式設計模型
服務呼叫: 執行緒間通訊-同步與非同步結合
服務發現
處理部分失敗

微服務實戰（三）：深入微服務架構的程序間通訊

對客戶端隱藏微服務耦合結構,各服務間需要通訊.

互動模式:

解決兩個問題:

一對一還是一對多
同步還是非同步

呼叫端是否關心實時響應:

是: 同步,例如,購物車獲取商品資訊.

否: 非同步,例如,商品加入購物車,推薦系統獲得商品資訊,給出推薦結果.例如,釋出打車請求後回到地圖頁面,服務端非同步地把打車請求分發給附近的司機.

一對多的互動模式有以下幾種方式：

• 釋出/ 訂閱模式：客戶端釋出通知訊息，被零個或者多個感興趣的服務消費。

• 釋出/非同步響應模式：客戶端釋出請求訊息，然後等待從感興趣服務發回的響應。

例項:打車系統的IPC

上圖中的服務通訊使用了通知、請求/響應、釋出/訂閱等方式。例如，乘客通過移動端給『行程管理服務』傳送通知，希望申請一次出租服務。『行程管理服務』傳送請求/響應訊息給『乘客服務』以確認乘客賬號是有效的。緊接著建立此次行程，並用釋出/訂閱互動模式通知其他服務，包括定位可用司機的排程服務。

API的演化

定義API需要考慮新舊版本同時執行.

實現1: 規定預設響應值,客戶端對於響應預設不處理.

實現2: URL加入版本號使不同版本API共存.

處理部分失敗

API GATEWAY的失敗為執行緒失敗: 會影響整體程序.

解決方案:

網路超時
限制請求次數
斷路器模式:記錄成功和失敗請求的數量。如果失效率超過一個閾值，觸發斷路器使得後續的請求立刻失敗。如果大量的請求失敗，就可能是這個服務不可用，再發請求也無意義。在一個失效期後，客戶端可以再試，如果成功，關閉此斷路器。
提供回滾：當一個請求失敗後可以進行回滾邏輯。例如，返回快取資料或者一個系統預設值。

IPC技術

非同步: 訊息佇列

同步: RPC/REST/Thrift

微服務實戰（四）：服務發現的可行方案以及實踐案例

問題描述:

傳統應用: 服務部署在固定的機器上.在配置當中寫好IP地址即可.
微服務: 動態部署, 服務地址不固定.需要更復雜的服務髮型機制,動態定位.

客戶端發現模式:

在客戶端與服務之間加上一層服務註冊層管理服務. 在客戶端實現負載均衡,檢視可用服務,決定請求地址. 服務例項的網路位置是在啟動時註冊到服務登錄檔中，並且在服務終止時從登錄檔中刪除。服務例項註冊資訊一般是使用心跳機制來定期重新整理的。

最大的缺點是需要針對不同的程式語言註冊不同的服務，在客戶端需要為每種語言開發不同的服務發現邏輯。(?未理解)

服務端發現模式:

客戶端通過負載均衡器向某個服務提出請求，負載均衡器向服務登錄檔發出請求，將每個請求轉發往可用的服務例項。跟客戶端發現一樣，服務例項在服務登錄檔中註冊或者登出。

簡而言之,將客戶端實現的功能搬到負載均衡器實現.

優點: 客戶端解耦.
缺點: 負載均衡器需保證高可用.

服務註冊

服務例項註冊和登出主要有兩類方式。

服務例項自動註冊到服務登錄檔中，也就是自注冊模式；
某個系統模組負責處理註冊和登出，也就是第三方註冊模式。

DNS註冊

使用DNS繫結<域名,IP地址>實現動態發現服務地址. NGINX Plus支援.

微服務實踐（五）：微服務的事件驅動資料管理

單體式應用使用RDBMS的優勢:

ACID transactions
SQL的方便查詢與引擎的自帶優化

要點:

微服務框架中各服務維護各自database,事務操作的ACID如今沒法保障.

整體思路:

在多個服務之間找到通訊方式,把事務操作抽象為具體的事件,如建立訂單,發起付款和點贊等. 由事件發起,觸發相關的服務釋出另一個事件,並更新自身資料庫.

詳細解決方案:

訊息佇列:釋出/訂閱
交易日誌挖掘:感知資料庫的變化
事件源:進一步解耦,建立一個基本服務進行事件管理與釋出.

微服務實戰（六）：選擇微服務部署策略

總結:

和虛擬機器相比,如Docker這類容器技術擁有很多優勢. 容器技術離宿主作業系統更近,各個不同容器之間共享核心態作業系統,只在使用者態作業系統有各自的沙盒,安全性會收到一定程度上的考驗,但是一般使用都不會有這類問題.

微服務實踐（七）：從單體式架構遷移到微服務架構

整體策略:

不做大規模遷移,逐步分離直到單體式架構被完全替代或自身成為微服務一部分.

策略1——停止挖掘

新功能以微服務實現

開發內容:

路由分發模組,區分新功能與原有功能.
膠水語言,新功能微服務往往與舊的單體式構架存在嚴重耦合,資料互相依賴.

微服務有三種方式訪問單體應用資料：

使用單體應用提供的遠端API
直接訪問單體應用資料庫
自己維護一份從單體應用中同步的資料

策略2——業務分層

表現層——處理HTTP請求，要麼響應一個RESTAPI請求，要麼是提供一個基於HTML的圖形介面。對於一個複雜使用者介面應用，表現層經常是程式碼重要的部分。
業務邏輯層——完成業務邏輯的應用核心
資料訪問層——訪問基礎元素，例如資料庫和訊息代理.

策略3——抽出服務

如何選擇被抽出模組進行服務化:

變化頻率最高的;
資源消耗高,時間與空間資源.
根據模組的同步/非同步,抽出非同步模組對完成同步功能的邏輯影響小.

總結:

使原有單體式框架逐步架空, 隨著抽離程度越高,服務化會越來越容易.