近年來，銀行業因為龐大的業務體量和業務發展需求，紛紛投入微服務架構的建設中。但隨著業務系統向微服務架構的轉型，隨之便產生了諸如微服務統一管控和治理這類令人頭疼的問題。
為了解決這類問題，開源的Spring Boot/Cloud生態提供了大量開源的組件，雖然它們經歷了市場考驗，但存在一些共同的缺點，如各個組件缺乏有機的企業級集成、內置功能不能滿足金融行業應用的特性等等。
對于金融企業來說開源解決方案并不能完全滿足企業自身的現狀和要求，甚至無法滿足技術上的自主可控訴求，這也造成了金融企業在使用開源解決方案的同時，需要投入大量的資源對開源解決方案和開源組件進行二次開發和定制，甚至是修改開源組件源代碼。
那該如何有效解決這類問題呢？
實踐出真知，長亮科技結合多年在銀行核心領域的積累及業內先進技術經驗，總結并實現了面向金融業務系統的微服務治理體系，讓我們一起看看，長亮科技在這方面經驗與見解。
如何構建面向金融業務系統的微服務治理體系?
面向金融業務系統的微服務治理體系主要圍繞服務管理、服務觀測、服務預警、服務控制幾大領域，提供服務全生命周期管理、數字化運維、立體化監控、細粒度服務治理等功能，以解決開發人員、運維人員、SRE、架構師等多方痛點，全方位提升工作效率。
要想實現統一的企業級微服務治理平臺，整個體系需要以層級結構進行建設：
● 管控層：提供平臺用戶統一視角的管理控制臺，通過前后端分離模式將治理控制臺和治理功能服務拆分；
● 集成層：主要針對微服務應用提供治理服務集成能力，主要包括客戶端集成SDK、客戶端性能和鏈路探針、客戶端日志收集代理；
● 服務層：對業務微服務提供治理能力的服務層，包含平臺后端的主要業務邏輯，并對中間件提供的服務進行封裝與定制；
● 中間件層：平臺所依賴的中間件，以開源為主，二次開發和私有實現為輔，包括注冊中心、配置中心、治理中心、網關中心、監控中心、日志中心、告警中心等；
● 數據層：為平臺中的非業務參數提供數據存儲，根據治理數據的特性和使用場景分為結構化數據和非結構化數據，分別采用對應的SQL和NoSQL存儲；
● 基礎設施層：平臺在部署方面支持X86物理機、虛擬機環境部署，支持公有云、私有云和混合云的虛擬機部署，支持基于Docker環境的容器化部署，支持基于Kubernetes的容器云環境部署。
深度剖析企業級微服務治理體系四大核心領域設計
1.微服務統一管理
提供一套圍繞業務應用和基礎組件的管理體系。在業務應用管理方面，提供從域、系統、分區、應用和單元（集群）等多維度管理方案，進而細粒度的控制業務應用接入；在基礎組件管理方面，可以對組件資源進行統一管理，做到應用零配置化即可使用組件。
● 平臺上對基礎組件資源的統一管理，為業務應用提供的SDK可以更簡單的接入到這些基礎組件。
■ 將微服務架構運行期所需要的各種基礎組件，如注冊中心、配置中心、API網關、分布式緩存、分布式消息等，通過平臺區域控制服務統一接管，為企業級架構提供統一視角的基礎組件資源管理。
■ 將業務應用集成這些基礎組件所需要的各種客戶端Starter包裝成一個簡單且統一的客戶端Starter，利用Spring Boot內置的監聽器機制，在業務應用啟動時可以連接到平臺上以此來獲取連接這些組件資源所需要的各種參數，在這個過程中也可以通過Token機制實現對組件資源的訪問權限控制，即降低了業務應用集成這些基礎組件的配置參數管理難度，也提高了對基礎組件使用的安全管控能力。
● 通過在平臺上創建的系統/應用/集群/實例這樣的模型結構，讓接入到微服務治理平臺的業務應用可以按照預期分拆的微服務運行，以此來做到對微服務應用規范強管控。
2. 運行期統一觀測
對運行狀態的微服務應用采用APM模塊實現對健康狀態、性能狀態監控、鏈路追蹤、應用日志分析、API接口管理等多維度實現統一的觀測手段。
● 實例探測：Spring Boot原生提供了Actuator組件來暴露運行期的各種狀態級數據指標，包括實例信息、啟動環境、配置數據、Bean加載信息、端點映射、日志級別等，同時也暴露了一些敏感且不安全的端點，如停止操作、數據庫密碼等。在利用Actuator組件實現實例狀態檢測功能的同時，需要將這些存在不安全的端點進行屏蔽，同時在這類端點上增加訪問安全權限控制，讓該組件可以在安全可控的范圍內為微服務治理觀測提供實例健康狀態探測相關特性能力。
● 性能監控：為了實現對業務應用的零代碼侵入，可采用Java探針技術實現對微服務應用的性能數據采集，如Skywalking APM Agent；從應用、集群、端口等維度收集性能數據，性能數據包括但不局限于：服務可用級別、響應時間、每分鐘調用數、百分位響應耗時、CPU、內存、GC情況等。應用實例通過平臺SDK注冊到平臺獲取到APM組件信息，通過APM組件客戶端對APM組件進行相關初始化操作，之后依托Agent字節碼增強技術在相應位置進行埋點，定時將性能數據推送至APM組件進行分析并持久化；平臺本身通過訪問APM組件暴露的端點獲取相關性能數據。
● 鏈路追蹤：與性能監控探針技術類似，利用Java探針技術，遵循OpenTracing標準，收集全鏈路數據，并分析鏈路數據形成調用拓撲；應用實例通過平臺SDK注冊到平臺獲取到APM組件信息，通過APM組件客戶端對APM組件進行相關初始化操作，之后依托Agent字節碼增強技術在相應位置進行埋點，定時將鏈路數據推送至APM組件進行分析并持久化，同時將MDC信息填充到日志，從而實現鏈路與日志的聯動；平臺本身通過訪問APM組件暴露的端點獲取相關鏈路數據。
● 應用日志分析：在日志收集和分析領域EFK是普遍采用的技術方案，但在應用日志分析的落地使用上，應用日志規范才是其核心的價值體系，對于企業級微服務日志觀測方面，日志規范體系需要在日志組件上落地以此作強規范約束；將規范中的某些關鍵數據以MDC方式注入，并按標準輸出到日志文件，日志收集組件到指定路徑收集日志數據推送至日志分析組件，日志分析組件按規范解析日志數據并進行持久化；平臺通過日志分析服務獲取日志數據。
● API：通過Swagger組件獲取應用實例運行時暴露的端點信息，從而進行在線接口調試；應用實例通過平臺SDK注冊到平臺獲取相關服務資源，之后正常啟動實例，實例啟動完成回調平臺接口通知平臺來拉取API數據，平臺接收到API數據拉取通知之后調用應用實例特定端點獲取API數據并持久化；平臺通過對API數據進行分析，從而實現對應用實例API接口進行在線調試功能。
3. 健康狀態統一預警
從性能數據和日志數據出發，提供性能告警和日志告警功能，結合靈活的告警規則可以針對不同業務場景產生與之相對應的告警，并在觸發告警之后提供一套完善的告警事件處理體系，包括告警事件標記、告警事件推送等。
● 性能告警：通過管控端配置告警規則提交到告警管理模塊落庫持久化，同時將告警規則推送至配置中心，性能告警組件依賴配置中心可以動態感知告警規則的變化并實時生效，然后在APM預處理接收的性能指標數據時立刻計算告警規則，對于滿足告警規則的指標數據立刻生成相應的告警事件，并持久化，隨后產生相關告警數據，并將告警數據持久化，同時推送至告警推送系統進行下一步推送操作。
● 日志告警：通過管控端配置告警規則提交到告警管理模塊落庫持久化，同時將告警規則推送至日志告警組件，然后刷新本地告警規則配置并定時輪詢檢測日志數據是否觸發告警規則，隨后產生相關告警事件，并將告警事件持久化，同時推送至告警推送系統進行下一步推送操作。
4. 服務保護統一控制
平臺服務網關提供一套以API為中心的完善的安全控制體系和治理體系。服務網關作為系統的統一入口，自身提供豐富的API治理和安全控制功能，這些功能可以按需開啟。外圍系統通過各種協議接入服務網關，服務網關經過一系列的安全校驗治理，最終通過指定協議調用目標應用。對業務應用做到統一管控和統一治理。
平臺服務網關接收到客戶端接入請求，首先會對報文進行解包成網關內部請求對象，之后走核心過濾器鏈：
● 所有過濾器都正常執行則走到路由過濾器根據接出協議將網關內部請求對象轉換成接出請求對象進行外部調用，調用成功拿到接出響應對象再轉換為網關內部響應對象；
● 執行過程有校驗不通過的直接拋出異常，異常處理過濾器對異常信息進行封裝網關內部響應對象。
在網關上提供的核心治理體系主要分為安全控制和API治理兩大部分：
● 安全控制體系：提供黑白名單、訪問控制、密鑰、租戶認證等多種安全體系，其中密鑰又從加密解密、加簽驗簽和認證授權等多種方式來保證API訪問的安全性。
● 治理體系：從限流控制、參數過濾、熔斷降級、灰度路由、超時控制、并發控制、訪問時段控制等維度對API訪問進行全方位治理。
在金融數字化浪潮中，企業級分布式服務平臺也在隨之改善升級、與時俱進，我們可以預見，未來的企業級分布式服務平臺將會進一步強化與企業金融應用開發平臺的整合力度，加強從設計到運維一站式可視化操作能力，提供架構級、單元化級別的可視化生命周期管理，并結合深度學習等技術實現智能化、自動化的微服務、單元化治理能力。
