金融行業微服務架構解析

轉載本文需註明出處：微信公衆號EAWorld，違者必究。

引言：

對於微服務，每一個人都有本身的理解，與互聯網企業的大量落地相比，微服務在傳統金融行業尚未普及，這首先是傳統金融行業線上系統需求更新和版本迭代沒有互聯網公司那麼頻繁；其次是技術能力約束了新技術的落地；再者傳統金融行業對系統可用性和穩定性的要求很是高。

如何理解微服務架構？微服務可以給金融行業帶來什麼？金融行業微服務架構如何選型？這些都須要咱們對微服務架構進行深刻的剖析。

目錄：

1、什麼是微服務
2、主流微服務框架
3、微服務架構關鍵技術

1、什麼是微服務？

微服務架構定義



微服務的定義源於 2014 年 3 月 Martin Fowler 所寫的一篇文章「Microservices」，微服務的四個特性定義抽象爲「小、獨、輕、鬆」。

微服務的感性認識



轉型以前：
緊耦合組件
慢的部署週期，等待集成測試

轉型以後：
鬆耦合組件
自動化部署，無需等待獨立組件

微服務優點



可伸縮性：服務的承載能力在設計之初並不能徹底符合後來業務發展的要求，隨着業務量增大，服務要經過服務器集羣方式進行擴展，各個微服務的擴展數量也是按需求擴展，承載量大的微服務擴展節點多，承載量小的微服務擴展節點少，從而實現資源有效配置。

下降風險：準備好部署各個階段的工件，包括：構建工件，測試腳本，配置文件和部署清單文件。

a) 從負載均衡列表中移除掉「金絲雀」服務器。
b) 升級「金絲雀」應用（排掉原有流量並進行部署）。
c) 對應用進行自動化測試。
d) 將「金絲雀」服務器從新添加到負載均衡列表中（連通性和健康檢查）。
e) 若是「金絲雀」在線使用測試成功，升級剩餘的其餘服務器。（不然就回滾）

彈性系統：在理想的設計中，一旦某一非核心微服務啓動失敗，其餘微服務仍然可用，用戶在沒有使用到異常模塊所提供的服務時，對這一異常徹底無感知，大大加強了用戶體驗。

敏捷：開發成本下降，響應速度加快。各個開發團隊的人員沒必要耗費大量時間瞭解整個服務端架構，主要經過了解某個微服務的金融業務需求和技術體系便可參與開發，從而下降了學習成本以及改動代碼帶來的風險，代碼審查流程的簡化也相應地加快了開發響應速度。

靈活：不要求全部的微服務都使用同一種技術和平臺來實現。

微服務架構帶來的問題



依賴服務變動很難跟蹤，其餘團隊的服務接口文檔過時怎麼辦?依賴的服務沒有準備好，如何驗證我開發的功能。
部分模塊重複構建，跨團隊、跨系統、跨語言會有不少的重複建設。
微服務放大了分佈式架構的系列問題，如分佈式事務怎麼處理?依賴服務不穩定怎麼辦?
運維複雜度陡增，如：部署物數量多、監控進程多致使總體運維複雜度提高。

這些解決方案折騰到最後就會明白，原來咱們要有一個微服務應用平臺才能總體性的解決這些問題。

微服務架構適用場景



微服務架構並非萬能的，有它適合採用的系統，這些系統包括：

對於業務流程較爲複雜，且業務會逐漸變得更加複雜的系統，單體應用將十分龐大，後期難以修改和維護，應考慮使用微服務架構。
爲了知足業務需求，項目中引入了衆多的技術棧，中間件，單體應用會給開發者帶來很大的困擾，應考慮將應用拆分紅多個獨立部署的採用最優技術棧實施的微服務。
高併發的，有高可用和彈性伸縮需求的系統，每每是那些面向龐大數量互聯網用戶的平臺類、交易類系統，應考慮利用微服務架構便於橫向擴展和彈性伸縮的特性。
單體應用版本發佈成本高，而單個微服務的變動和發佈都很容易，那些有高頻率版本發佈需求的系統，應使用微服務架構。
沒有數據實時強一致要求，可接受數據最終一致的系統，可以使用微服務架構。

在銀行系統中：

OA、HR、績效等管理類系統並不須要微服務架構；
信貸、CRM等管理類應用若是體積龐大（幾十萬行代碼以上），要使用微服務改造；
中間業務、核心帳務、網銀因爲系統壓力大，能夠採用微服務架構。

微服務架構在互聯網金融方面的應用



第三方支付包括以支付寶、財付通、盛付通爲表明的互聯網支付企業，也包括快錢、匯付天下爲表明的金融型支付企業。
P2P小額信貸是一種我的對我的的直接信貸模式。
大數據金融是指集合海量非結構化數據，經過對其進行實時分析，能夠爲互聯網金融機構提供客戶全方位信息。
衆籌融資指用團購+預購的形式，向網友募集項目資金的模式。衆籌利用互聯網傳播的特性，讓小企業、藝術家或我的對公衆展現他們的創意，爭取你們的關注和支持，進而得到所須要的資金援助。
所謂信息化金融機構，是指經過採用信息技術，對傳統運營流程進行改造活重構，實現經營、管理全面電子化的銀行、證券和保險等金融機構。
互聯網金融門戶是指利用互聯網進行金融產品的銷售以及爲金融產品銷售提供第三方服務的平臺。它的核心就是「搜索+比價」的模式。

2、主流微服務框架

業界開源微服務框架方案比較



綜合來看，SpringCloud是首選。爲何選擇SpringCloud？

不僅是解決微服務的某一個問題，而是一個解決微服務架構實施的綜合性解決框架；
整合了諸多被普遍實踐和證實過的框架做爲實施的基礎部件，又在該體系基礎上建立了一些很是優秀的邊緣組件 ；
大量的兼容性測試，保證了更好的穩定性；
極高的社區活躍度；

SpringCloud之於其餘微服務框架就比如是：品牌機 VS  DIY電腦

3、微服務架構關鍵技術

微服務平臺技術圖譜



微服務技術桟：
API Doc: Swagger UI
API Mock: Swagger Mock API
AOP基礎框架：Spring framework
微服務容器：Spring Boot
服務發佈：Spring Web MVC
服務註冊中心：Spring Cloud - Eureka
服務路由：Spring Cloud – Ribbon
服務調用：Spring Cloud – Feign
服務熔斷器：Spring Cloud – Hystrix
安全認證：Spring Cloud - Security
服務配置中心：Apollo , Spring Cloud – Config
服務監控：Spring Boot Admin

關鍵技術架構與設計



咱們從這9個方面來解析微服務關鍵技術架構與設計。

一、前端UI框架

兼容性



Vue是流行的前端框架，其對瀏覽器的兼容性較好，主流的操做系統和瀏覽器都支持。

vue響應式雙向數據綁定實現自動同步



vue.js採用數據劫持結合發佈者-訂閱者的方式，經過Object.defineProperty()來劫持各個屬性的setter，getter，在數據變更時，發佈消息給訂閱者，觸發相應的監聽回調。

具體的來說，Vue.js經過Directives指令去對DOM作封裝，當數據發生變化，會通知指令去修改對應的DOM，數據驅動DOM的變化。vue.js還會對操做作一些監聽（DOM Listener），當咱們修改視圖的時候，vue.js監聽到這些變化，從而改變數據。這樣就造成了數據的雙向綁定。

二、微服務容器

微服務運行的容器環境



咱們來看一下微服務運行容器，要作可靠高效的微服務架構應用，實際上咱們須要作的事情仍是很是多的。若是沒有一個統一的微服務容器，這些能力在每一個微服務組件中都須要建設一遍，並且會五花八門，也很難集成到一塊兒。

微服務容器：負載均衡



微服務容器的基礎服務能力之一就是支持負載均衡。

一般所說的負載均衡都指的是服務端負載均衡，其中分爲硬件負載均衡和軟件負載均衡。硬件負載均衡主要經過在服務器節點之間安裝專門用於負載均衡的設備，好比F5等；而軟件負載均衡則是經過在服務器上安裝一些具備負載均衡功能或模塊的軟件來完成請求分發工做，好比Nigix等。

硬件負載均衡的設備或是軟件負載均衡的軟件模塊都會維護一個下掛可用的服務端清單，經過心跳檢測來剔除故障的服務端節點以保證清單中都是能夠正常訪問的服務端節點。當客戶端發送請求到負載均衡設備時，該設備按照某種算法（好比線性輪詢、按權重負載、按流量負載等）從維護的可用服務端清單中取出一臺服務端的地址，而後進行轉發。

客戶端負載均衡和服務器負載均衡最大的不一樣點在於上面所提到的服務清單所存儲的位置。在客戶端負載均衡中，全部客戶端節點都維護着本身要訪問的服務端清單，而這些服務端的清單來自於服務註冊中心，建議使用Spring Cloud Netflix 的Ribbon組件。

微服務容器：服務熔斷、容錯、升降級、限流


微服務容器的基礎服務能力之二就是服務熔斷、容錯、升降級、限流，在系統出現異常時提供故障恢復能力。

三、註冊中心

服務註冊與發現



接下來咱們聊一下注冊發現，之前的單塊應用之間互相調用時配置個IP就好了，但在微服務架構下，服務提供者會有不少，手工配置IP地址又變成了一個不可行的事情。那麼服務自動註冊發現的方案就解決了這個問題。

咱們的服務註冊發現能力是依賴SpringCloud Eureka組件實現的。服務在啓動的時候，會將本身要發佈的服務註冊到服務註冊中心，運行時，若是須要調用其餘微服務的接口，那麼就要先到註冊中心獲取服務提供者的地址，拿到地址後，經過微服務容器內部的簡單負載均衡器進行路由。

通常狀況，系統內微服務的調用都經過這種客戶端負載均衡的模式進行，不然就須要有不少的負載均衡進程。跨業務系統的服務調用，也能夠採用這種去中心化的路由方式。固然採用SOA的模式，由中心化的服務網管來管理系統間的調用也是另外一種選擇，要結合企業的IT現狀和需求來決定。

四、配置中心

集中配置管理



微服務分佈式環境下，一個系統拆分爲不少個微服務，必定要告別投產或運維手工修改配置的方式。須要採用集中配置管理的方式來提高運維的效率。

配置文件主要有運行前的靜態配置和運行期的動態配置兩種。靜態配置一般是在編譯部署包以前設置好。動態配置則是系統運行過程當中須要調整的系統變量或者業務參數。

要想作到集中的配置管理，那麼須要注意如下幾點：

配置與介質分離，這個就須要經過制定規範的方式來控制。千萬別把配置放在Jar包裏。
配置的方式要統一，格式、讀寫方式、變動熱更新的模式儘可能統一，要採用統一的配置框架
運行時須要有個配置中心來統一管理業務系統中的配置信息，這個就須要平臺來提供配置中心服務和配置管理門戶。

配置修改同步交互



配置修改後經過推送或者定時拉取的方式更新並緩存到應用程序所在的微服務容器中供應用程序使用。

高可用運行架構設計



配置中心有兩種部署模式

高可用模式，見上圖，支撐大規模微服務訪問時根據負載狀況能夠對「配置查詢同步服務」進行橫向擴展
ALL-IN-ONE模式，配置變動服務、配置查詢服務合併爲一個進程。適合支撐少許系統的場景使用。

配置中心能夠支持高可用模式部署，知足金融行業的要求。

五、監控中心

基於Skywalking定製實現



SkyWalking主要就是經過收集各類格式的數據進行存儲，而後展現。因此咱們須要關注的是 SkyWalking Collecter、SkyWalking UI 和 存儲設備。

APM探針



JavaAgent 是JDK 1.5 之後引入的，也能夠叫作Java代理。

JavaAgent 是運行在 main方法以前的攔截器，它內定的方法名叫 premain ，也就是說先執行 premain 方法而後再執行 main 方法。

使用agent技術構建一個獨立於應用程序的代理程序（即爲Agent），用來協助監測、運行甚至替換其餘JVM上的程序。使用它能夠實現虛擬機級別的AOP功能。

APM全鏈路運行監控



調用鏈跟蹤分析：把同一TraceID的Span收集起來，按時間排序就是timeline。把ParentID串起來就是調用棧。

實時分析：對單條日誌直接分析，不作彙總，重組。獲得當前QPS，延遲。

離線分析：按TraceID彙總，經過Span的ID和ParentID還原調用關係，分析鏈路形態。

六、日誌中心

 

日誌中心架構

 

日誌分析是運維工程師解決系統故障，發現問題的主要手段。日誌主要包括系統日誌、應用程序日誌和安全日誌。系統運維和開發人員能夠經過日誌瞭解服務器軟硬件信息、檢查配置過程當中的錯誤及錯誤發生的緣由。常常分析日誌能夠了解服務器的負荷，性能安全性，從而及時採起措施糾正錯誤。

一般，日誌被分散的儲存在不一樣的設備上。若是你管理數十上百臺服務器，你還在使用依次登陸每臺機器的傳統方法查閱日誌，即繁瑣又效率低下。爲此，咱們使用集中化的日誌管理，將全部服務器上的日誌收集彙總。

集中化管理日誌後，日誌的統計和檢索又成爲一件比較麻煩的事情，這時實時日誌分析ELK平臺可以完美的解決上述的問題，ELK由ElasticSearch、Logstash和Kiabana三個開源工具組成。

 

規範日誌與流水，問題追根溯源



做爲一個微服務應用平臺除了提供支撐開發和運行的技術組件和框架以外，還應該提供一些運維友好的經驗總結，咱們推薦的日誌與流水實現以下：

先來看日誌，平臺應提供的日誌主要有三種，系統日誌，引擎日誌還有跟蹤日誌。有了這些日誌，在出問題的時候可以幫助咱們獲取一些關鍵信息進行問題定位。

要想作到出了問題可以追根溯源，那麼右邊的這些流水號的設計也是很是重要的，日誌與各類流水號配合，可以讓咱們快速定位問題發生的具體時間地點以及相關信息，可以快速還原業務交易全鏈路。對這些日誌與流水的細節處理，對於系統運維問題定位有很是大的幫助，沒有這些有用的日誌內容，ELK日誌收集套件搭建的再漂亮，收一堆垃圾日誌也是沒用的。

一般開源框架只是提供個框架有開發人員自由發揮，而設計一個平臺則必定要考慮直接提供統一規範的基礎能力。

七、API Gateway

基於Spring Cloud Netflix的Zuul組件定製實現


異步非阻塞模式啓動的線程不多，基本上一個CPU core上只需啓一個處理線程，它使用的線程資源就不多，上下文切換(Context Switch)開銷也少。非阻塞模式能夠接受的鏈接數大大增長，能夠簡單理解爲請求來了只須要進隊列，這個隊列的容量能夠設得很大，只要不超時，隊列中的請求都會被依次處理。

API Gateway邏輯架構



API網關就像整個系統的門面同樣，全部的外部訪問都通過它實現調度、過濾、請求路由、負載均衡、校驗等等。

API Gateway 功能



API網關上還能夠實現更多更復雜的功能。

八、IAM（Identity and Access Management）

IAM架構



IAM爲企業提供統一的帳號管理視角，對全部基於帳號的管理、認證、受權、審計進行集中的統一管理，提升了帳號管理的安全，幫助系統管理員提升了工做效率，下降了管理負擔，同時改善了普通用戶在不一樣資源中登陸認證的重複繁瑣過程，爲平常工做提供了更高的安全性。


統一用戶中心



IAM能夠爲企業全部的資源使用人員如普通用戶、系統管理人員、駐場代維人員、合做夥伴、臨時工做人員等定義主帳號，按照公司的組織方式對人員進行管理。經過一對一的主帳號管理模式，能夠在該平臺實現對全部資源使用人員進行集中定義、集中維護等生命週期管理。

統一認證與鑑權



安全認證方面，咱們基於Spring Security結合Auth2再加上JWT(Json web token)作安全令牌，實現統一的安全認證與鑑權，使得微服務之間可以按需隔離和安全互通。認證鑑權必定是個公共的服務，而不是多個系統各自建設。

九、微服務管理

服務管理機制



服務提供者：

服務註冊
在服務註冊時，須要確認下eureka.client.register-with-eureka=true參數是否正確，默認爲true，若設置爲false將不會啓動註冊操做。

服務同步
因爲服務註冊中心之間因互相註冊爲服務，當服務提供者發送註冊請求到一個服務註冊中心，它會將該請求轉發給集羣中相連的其餘註冊中心，從而實現註冊中心之間的服務同步。

服務續約
eureka.instance.lease-renewal-interval-in-seconds參數用於定義服務續約任務的調用間隔時間默認30秒。
eureka.instance.lease-exptration-duration-in-seconds參數用於定義服務失效時間，默認爲90秒。

服務消費者：

獲取服務
當咱們啓動服務消費者時候，它會發送一個REST請求給服務註冊中心，來獲取上面註冊的服務清單。爲了性能考慮，Eureka Server會維護一份只讀的服務清單來返回給客戶端，同時該緩存清單會每隔30秒更新一次。

服務調用
服務消費者在獲取服務清單後，經過服務名能夠得到具體提供服務的實例名和該實例的元數據。由於有這些服務實例的詳細信息，因此客戶端能夠根據本身的須要決定具體調用哪一個實例。

單服務異常致使雪崩



採用微服務架構後，服務之間會有錯綜複雜的依賴關係，例如，一個前端請求通常會依賴於多個後端服務。

在微服務架構中，存在着那麼多的服務單元，若一個單元出現故障，就很容易因依賴關係而引起故障的蔓延，最終致使整個系統的癱瘓，形成所謂的雪崩效應，這樣的架構較傳統架構更加不穩定。

自我保護



當網絡分區故障發生時，微服務與Eureka Server之間沒法正常通訊，而微服務自己是正常運行的，此時不該該移除這個微服務，因此引入了自我保護機制。

服務註冊到Eureka Server以後，會維護一個心跳鏈接，告訴Eureka Server本身還活着。Eureka Server在運行期間，會統計心跳失敗的比例在15分鐘以內是否低於85%，若是出現低於的狀況，Eureka Server會將當前的實例註冊信息保護起來，讓這些實例不會過時，儘量保護這些註冊信息。

服務容錯處理



資源隔離：包括線程池隔離和信號量隔離，限制調用分佈式服務的資源使用，某一個調用的服務出現問題不會影響其餘服務調用
降級機制：超時降級、資源不足時(線程或信號量)降級，降級後能夠配合降級接口返回託底數據。
熔斷：當失敗率達到閥值自動觸發降級(如因網絡故障/超時形成的失敗率高)，熔斷器觸發的快速失敗會進行快速恢復。
緩存：提供了請求緩存、請求合併實現。


關於做者：黃豆，數字化金融研究院研究員，擅長系統分析和架構設計、金融三級密鑰安全體系及信息安全保障、虛擬化和雲計算技術、JavaEE技術；參與研發的神州商橋電子商務平臺得到「全國電子商務示範單位」稱號；帶領團隊研發的國電通雲終端系統在國網多個省公司推廣應用。


關於EAWorld：微服務，DevOps，數據治理，移動架構原創技術分享。長按二維碼關注！