微服務架構下的服務呼叫與鑑權——某保險公司微服務平臺實施案例分享

基於微服務架構的企業分散式應用平臺，從整合開發工具、服務執行環境、應用管理監控、外部渠道接入等維度來劃分，其功能架構如圖所示，包括SDK&規範、註冊中心、配置中心、監控中心、認證中心、API閘道器、服務執行環境、管理平臺、登記平臺等部分。

微服務平臺邏輯架構

微服務平臺概念模型

結合客戶的實際情況，微服務平臺的概念模型定義如下：

• 註冊中心：支援一個環境內所有域下所有微服務的註冊

• 配置中心：支援支援一個環境內所有域下所有微服務的配置

• APM：支援一個環境內所有域下所有微服務的APM監控

• 斷路器監控中心：支援一個環境內所有域下所有微服務的斷路器監控，支援按每個版本檢視

• 日誌中心：支援一個環境內所有域下所有微服務的日誌收集、檢視

• 域：對應完整的業務域，比如車險域

• 閘道器：閘道器分為外部閘道器和內部閘道器。外部閘道器部署在DMZ區，用於把API對外網暴露；內部閘道器用於跨系統間的API呼叫

• 系統：對應實際的業務系統，每個域有多個業務系統

• 應用：對應業務系統中的業務模組，每個業務系統有多個應用

• 微服務：每個應用有多個微服務

• 微服務版本：每個微服務可以有多個版本，其中可以有多個上線執行版本

• API：每個微服務版本提供的API

• 例項：每個微服務版本的執行程式

微服務之間的呼叫關係分為系統內部和跨系統兩種場景：

1、系統內部的微服務之間呼叫

採用直連方式，微服務多例項部署時，呼叫者採用客戶端負載均衡器（如Netflix Ribbion）。

2、跨系統的微服務之間呼叫

跨系統的微服務呼叫透過API閘道器進行中轉，服務提供者需要在API閘道器上配置路由，然後在API Store中釋出API；

服務消費者透過API Store訂閱需要的API並獲得訂閱碼，然後攜帶訂閱碼呼叫所訂閱的API；

API Store支援訂閱稽核流程，服務提供者可以對消費者的訂閱請求進行稽核。

注：API Store是為客戶定製的管理服務釋出與訂閱的模組，這裡不做展開描述。

在實際業務場景中，微服務提供者執行期存在多版本共存的情況，所以API閘道器和微服務SDK支援微服務多版本路由策略：

1. 客戶端請求頭指定呼叫目標服務版本

2. 支援灰度版本策略：可以設定針對特定的一組呼叫者允許或不允許訪問灰度版本（即黑白名單），即灰度版本匯入部分客戶端流量

3. 支援灰度版本線上熱切換成正式版本

服務的呼叫過程包括服務釋出與服務消費的過程。

在不同的服務呼叫場景中，API閘道器和服務提供者需要對消費者的身份進行認證、對服務呼叫進行鑑權。

API閘道器負責校驗客戶端訂閱碼的合法性（呼叫API鑑權服務進行鑑權），支援黑白名單配置；微服務提供者（SDK）負責校驗客戶端（系統內部服務或者API閘道器）身份的合法性。

微服務訪問鑑權設計

1）服務消費者透過API閘道器呼叫服務提供者的API時，需要在請求頭中攜帶訂閱碼

2）API閘道器根據請求頭中的訂閱碼，呼叫鑑權服務校驗請求的合法性，鑑權失敗則拒絕非法請求

3）API閘道器鑑權成功後，刪除請求頭中的訂閱碼，避免洩露服務消費者的安全資訊給服務提供者，並在請求頭中新增API閘道器標識，然後根據當前路由規則轉發到後端某個API服務提供者例項上

4）服務提供者接收到來自API閘道器或者系統內部其他微服務的呼叫請求，獲取請求頭中的客戶端標識，根據這個標識從服務註冊中心獲取客戶端例項列表，比較此次請求的來源是否在例項列表中，驗證此次請求是否來自合法的消費者。

下面是Java客戶端呼叫示例，訂閱碼等呼叫所需的引數可以在application.yml (application.properties)或配置中心上配置，微服務SDK開發工具包中已經封裝了請求頭關於鑑權的處理。

Java客戶端呼叫示例

以上便是透過某保險公司微服務平臺實施案例，分享了微服務架構下的服務呼叫與鑑權的全部內容。