溫馨提示×
您好，登錄后才能下訂單哦！
點擊 登錄注冊 即表示同意《億速云用戶服務條款》
您好，登錄后才能下訂單哦！
轉載本文需注明出處：微信公眾號EAWorld，違者必究。
引言：
根據保險行業發展趨勢，目前保險交易已經呈現高頻化、碎片化、場景化等特點，對系統的處理能力、容量、業務連續性、需求相應速度、運維響應速度提出了更高的要求。業務模式創新重塑導致系統更新頻繁、應用復雜度急劇升高，傳統架構不堪重負，敏捷開發和快速交付無從談起。
本次實施目標為建設滿足XXX保險公司業務需求的微服務管理平臺和配套工具規范，包括：微服務開發框架，微服務登記平臺，微服務管理平臺等，能夠支撐微服務的開發、運行生命周期管理，進而更好的支持業務與技術的發展與創新。
目錄：
一、項目背景與目標
二、微服務平臺架構設計
三、微服務調用關系
四、微服務訪問鑒權設計
根據保險行業發展趨勢，目前保險交易已經呈現高頻化、碎片化、場景化等特點，對系統的處理能力、容量、業務連續性、需求相應速度、運維響應速度提出了更高的要求。業務模式創新重塑導致系統更新頻繁、應用復雜度急劇升高，傳統架構不堪重負，敏捷開發和快速交付無從談起。
客戶面臨的問題主要是：
基于單體架構或SOA架構的應用無法適應業務模式創新的需要
缺乏微服務應用的統一技術標準與體系架構
微服務架構試點項目反應出對于服務的管控、治理亟待提升
客戶微服務平臺定制的目標，是建設滿足新形勢下保險業務需求的微服務管理平臺和配套工具規范，能夠支撐微服務的開發、運行生命周期管理，這主要包括：
微服務開發框架：一個供開發微服務的服務框架基座；
微服務登記平臺：進行微服務設計、開發、變更、版本、訂閱、下架等全生命周期管理；
微服務管理平臺：進行微服務運行時管理，包括服務注冊、服務發現、配置中心、網關、負載均衡、認證鑒權、熔斷降級、監控等功能。
基于微服務架構的企業分布式應用平臺，從集成開發工具、服務運行環境、應用管理監控、外部渠道接入等維度來劃分，其功能架構如圖所示，包括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支持微服務多版本路由策略：
客戶端請求頭指定調用目標服務版本
支持灰度版本策略：可以設置針對特定的一組調用者允許或不允許訪問灰度版本（即黑白名單），即灰度版本導入部分客戶端流量
支持灰度版本在線熱切換成正式版本
服務的調用過程包括服務發布與服務消費的過程。
在不同的服務調用場景中，API網關和服務提供者需要對消費者的身份進行認證、對服務調用進行鑒權。
API網關負責校驗客戶端訂閱碼的合法性（調用API鑒權服務進行鑒權），支持黑白名單配置；微服務提供者（SDK）負責校驗客戶端（系統內部服務或者API網關）身份的合法性。
微服務訪問鑒權設計
1）服務消費者通過API網關調用服務提供者的API時，需要在請求頭中攜帶訂閱碼
2）API網關根據請求頭中的訂閱碼，調用鑒權服務校驗請求的合法性，鑒權失敗則拒絕非法請求
3）API網關鑒權成功后，刪除請求頭中的訂閱碼，避免泄露服務消費者的安全信息給服務提供者，并在請求頭中添加API網關標識，然后根據當前路由規則轉發到后端某個API服務提供者實例上
4）服務提供者接收到來自API網關或者系統內部其他微服務的調用請求，獲取請求頭中的客戶端標識，根據這個標識從服務注冊中心獲取客戶端實例列表，比較此次請求的來源是否在實例列表中，驗證此次請求是否來自合法的消費者。
下面是Java客戶端調用示例，訂閱碼等調用所需的參數可以在application.yml (application.properties)或配置中心上配置，微服務SDK開發工具包中已經封裝了請求頭關于鑒權的處理。
Java客戶端調用示例
以上便是通過某保險公司微服務平臺實施案例，分享了微服務架構下的服務調用與鑒權的全部內容。
精選提問：
問1：“服務的調用過程包括服務發布與服務消費的過程”，這里講了“服務消費的鑒權”，那“服務發布”有需要鑒權的么？
答：API發布的時候可以設置是否需要審批，服務消費者訂閱API的時候，API Store會根據是否需要審批的設置，判斷是否交由服務提供者進行訂閱審批，審批通過后才算是訂閱成功，才能進行調用。服務發布本身現在是通過API Store的用戶權限控制，由提供者的管理員進行發布。
問2：系統A不允許訪問系統B的服務1，但可以訪問系統B的服務2，而服務2走系統內部直接訪問服務1，那么：在系統A被授權或訪問服務2的時候，API Store或者API網關會提示風險么？
答：不會提示，系統B的服務2調用自己系統內部的服務1是不會被限制的，網關鑒權只關注系統A調用系統B的服務是否合法。
關于作者：李忠文，普元開發工程師，普元DevOps核心成員之一。曾參與興業銀行、上海大眾、北京海關、交行卡中心、中國銀聯等項目
關于EAWorld：微服務，DevOps，數據治理，移動架構原創技術分享。
免責聲明：本站發布的內容（圖片、視頻和文字）以原創、轉載和分享為主，文章觀點不代表本網站立場，如果涉及侵權請聯系站長郵箱：is@yisu.com進行舉報，并提供相關證據，一經查實，將立刻刪除涉嫌侵權內容。
