金融行業微服務架構解析

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

引言：

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

如何理解微服務架構？微服務能夠給金融行業帶來什麼？金融行業微服務架構如何選型？這些都需要我們對微服務架構進行深入的剖析。

目錄：

一、什麼是微服務

二、主流微服務框架

三、微服務架構關鍵技術

一、什麼是微服務？

微服務架構定義

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

微服務的感性認識

轉型之前：

緊耦合元件

慢的部署週期，等待整合測試

轉型之後：

松耦合元件

自動化部署，無需等待獨立元件

微服務優勢

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

2. 降低風險：準備好部署各個階段的工件，包括：構建工件，測試指令碼，配置檔案和部署清單檔案。

   a) 從負載均衡列表中移除掉“金絲雀”伺服器。

   b) 升級“金絲雀”應用（排掉原有流量並進行部署）。

   c) 對應用進行自動化測試。

   d) 將“金絲雀”伺服器重新新增到負載均衡列表中（連通性和健康檢查）。

   e) 如果“金絲雀”線上使用測試成功，升級剩餘的其他伺服器。（否則就回滾）

3. 彈性系統：在理想的設計中，一旦某一非核心微服務啟動失敗，其他微服務仍然可用，使用者在沒有使用到異常模組所提供的服務時，對這一異常完全無感知，大大增強了使用者體驗。

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

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

微服務架構帶來的問題

1. 依賴服務變更很難跟蹤，其他團隊的服務介面文件過期怎麼辦?依賴的服務沒有準備好，如何驗證我開發的功能。

2. 部分模組重複構建，跨團隊、跨系統、跨語言會有很多的重複建設。

3. 微服務放大了分散式架構的系列問題，如分散式事務怎麼處理?依賴服務不穩定怎麼辦?

4. 運維複雜度陡增，如：部署物數量多、監控程式多導致整體運維複雜度提升。

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

微服務架構適用場景

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

1. 對於業務流程較為複雜，且業務會逐漸變得更加複雜的系統，單體應用將十分龐大，後期難以修改和維護，應考慮使用微服務架構。

2. 為了滿足業務需求，專案中引入了眾多的技術棧，中介軟體，單體應用會給開發者帶來很大的困擾，應考慮將應用拆分成多個獨立部署的採用最優技術棧實施的微服務。

3. 高併發的，有高可用和彈性伸縮需求的系統，往往是那些面向龐大數量網際網路使用者的平臺類、交易類系統，應考慮利用微服務架構便於橫向擴充套件和彈性伸縮的特性。

4. 單體應用版本釋出成本高，而單個微服務的變更和釋出都很容易，那些有高頻率版本釋出需求的系統，應使用微服務架構。

5. 沒有資料實時強一致要求，可接受資料最終一致的系統，可使用微服務架構。

在銀行系統中：

1. OA、HR、績效等管理類系統並不需要微服務架構；

2. 信貸、CRM等管理類應用如果體積龐大（幾十萬行程式碼以上），要使用微服務改造；

3. 中間業務、核心賬務、網銀由於系統壓力大，可以採用微服務架構。

微服務架構在網際網路金融方面的應用

1. 第三方支付包括以支付寶、財付通、盛付通為代表的網際網路支付企業，也包括快錢、匯付天下為代表的金融型支付企業。

2. P2P小額信貸是一種個人對個人的直接信貸模式。

3. 大資料金融是指集合海量非結構化資料，透過對其進行實時分析，可以為網際網路金融機構提供客戶全方位資訊。

4. 眾籌融資指用團購+預購的形式，向網友募集專案資金的模式。眾籌利用網際網路傳播的特性，讓小企業、藝術家或個人對公眾展示他們的創意，爭取大家的關注和支援，進而獲得所需要的資金援助。

5. 所謂資訊化金融機構，是指透過採用資訊科技，對傳統運營流程進行改造活重構，實現經營、管理全面電子化的銀行、證券和保險等金融機構。
   

6. 網際網路金融門戶是指利用網際網路進行金融產品的銷售以及為金融產品銷售提供第三方服務的平臺。它的核心就是“搜尋+比價”的模式。

二、主流微服務框架

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

綜合來看，SpringCloud是首選。為什麼選擇SpringCloud？

1. 不只是解決微服務的某一個問題，而是一個解決微服務架構實施的綜合性解決框架；

2. 整合了諸多被廣泛實踐和證明過的框架作為實施的基礎部件，又在該體系基礎上建立了一些非常優秀的邊緣元件 ；

3. 大量的相容性測試，保證了更好的穩定性；

4. 極高的社群活躍度；

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

三、微服務架構關鍵技術

微服務平臺技術圖譜

微服務技術桟：

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個方面來解析微服務關鍵技術架構與設計。

1、前端UI框架

相容性

Vue是流行的前端框架，其對瀏覽器的相容性較好，主流的作業系統和瀏覽器都支援。

vue響應式雙向資料繫結實現自動同步

vue.js採用資料劫持結合釋出者-訂閱者的方式，透過Object.defineProperty()來劫持各個屬性的setter，getter，在資料變動時，釋出訊息給訂閱者，觸發相應的監聽回撥。

具體的來講，Vue.js透過Directives指令去對DOM做封裝，當資料發生變化，會通知指令去修改對應的DOM，資料驅動DOM的變化。vue.js還會對操作做一些監聽（DOM Listener），當我們修改檢視的時候，vue.js監聽到這些變化，從而改變資料。這樣就形成了資料的雙向繫結。

2、微服務容器

微服務執行的容器環境

我們來看一下微服務執行容器，要做可靠高效的微服務架構應用，實際上我們需要做的事情還是非常多的。如果沒有一個統一的微服務容器，這些能力在每個微服務元件中都需要建設一遍，而且會五花八門，也很難整合到一起。

微服務容器：負載均衡

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

1. 通常所說的負載均衡都指的是服務端負載均衡，其中分為硬體負載均衡和軟體負載均衡。硬體負載均衡主要透過在伺服器節點之間安裝專門用於負載均衡的裝置，比如F5等；而軟體負載均衡則是透過在伺服器上安裝一些具有負載均衡功能或模組的軟體來完成請求分發工作，比如Nigix等。

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

3. 客戶端負載均衡和伺服器負載均衡最大的不同點在於上面所提到的服務清單所儲存的位置。在客戶端負載均衡中，所有客戶端節點都維護著自己要訪問的服務端清單，而這些服務端的清單來自於服務註冊中心，建議使用Spring Cloud Netflix 的Ribbon元件。

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

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

3、註冊中心

服務註冊與發現

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

我們的服務註冊發現能力是依賴SpringCloud Eureka元件實現的。服務在啟動的時候，會將自己要釋出的服務註冊到服務註冊中心，執行時，如果需要呼叫其他微服務的介面，那麼就要先到註冊中心獲取服務提供者的地址，拿到地址後，透過微服務容器內部的簡單負載均衡器進行路由。

一般情況，系統內微服務的呼叫都透過這種客戶端負載均衡的模式進行，否則就需要有很多的負載均衡程式。跨業務系統的服務呼叫，也可以採用這種去中心化的路由方式。當然採用SOA的模式，由中心化的服務網管來管理系統間的呼叫也是另一種選擇，要結合企業的IT現狀和需求來決定。

4、配置中心

集中配置管理

微服務分散式環境下，一個系統拆分為很多個微服務，一定要告別投產或運維手工修改配置的方式。需要採用集中配置管理的方式來提升運維的效率。

配置檔案主要有執行前的靜態配置和執行期的動態配置兩種。靜態配置通常是在編譯部署包之前設定好。動態配置則是系統執行過程中需要調整的系統變數或者業務引數。

要想做到集中的配置管理，那麼需要注意以下幾點：

1. 配置與介質分離，這個就需要透過制定規範的方式來控制。千萬別把配置放在Jar包裡。

2. 配置的方式要統一，格式、讀寫方式、變更熱更新的模式儘量統一，要採用統一的配置框架

3. 執行時需要有個配置中心來統一管理業務系統中的配置資訊，這個就需要平臺來提供配置中心服務和配置管理門戶。

配置修改同步互動

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

高可用執行架構設計

配置中心有兩種部署模式

1. 高可用模式，見上圖，支撐大規模微服務訪問時根據負載情況可以對“配置查詢同步服務”進行橫向擴充套件

2. ALL-IN-ONE模式，配置變更服務、配置查詢服務合併為一個程式。適合支撐少量系統的場景使用。

配置中心可以支援高可用模式部署，滿足金融行業的要求。

5、監控中心

基於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還原呼叫關係，分析鏈路形態。

6、日誌中心

日誌中心架構

日誌分析是運維工程師解決系統故障，發現問題的主要手段。日誌主要包括系統日誌、應用程式日誌和安全日誌。系統運維和開發人員可以透過日誌瞭解伺服器軟硬體資訊、檢查配置過程中的錯誤及錯誤發生的原因。經常分析日誌可以瞭解伺服器的負荷，效能安全性，從而及時採取措施糾正錯誤。

通常，日誌被分散的儲存在不同的裝置上。如果你管理數十上百臺伺服器，你還在使用依次登入每臺機器的傳統方法查閱日誌，即繁瑣又效率低下。為此，我們使用集中化的日誌管理，將所有伺服器上的日誌收集彙總。

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

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

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

1. 先來看日誌，平臺應提供的日誌主要有三種，系統日誌，引擎日誌還有跟蹤日誌。有了這些日誌，在出問題的時候能夠幫助我們獲取一些關鍵資訊進行問題定位。

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

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

7、API Gateway

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

非同步非阻塞模式啟動的執行緒很少，基本上一個CPU core上只需啟一個處理執行緒，它使用的執行緒資源就很少，上下文切換(Context Switch)開銷也少。非阻塞模式可以接受的連線數大大增加，可以簡單理解為請求來了只需要進佇列，這個佇列的容量可以設得很大，只要不超時，佇列中的請求都會被依次處理。

API Gateway邏輯架構

API閘道器就像整個系統的門面一樣，所有的外部訪問都經過它實現排程、過濾、請求路由、負載均衡、校驗等等。

API Gateway 功能

API閘道器上還可以實現更多更復雜的功能。

8、IAM（Identity and Access Management）

IAM架構

IAM為企業提供統一的賬號管理視角，對所有基於賬號的管理、認證、授權、審計進行集中的統一管理，提高了賬號管理的安全，幫助系統管理員提高了工作效率，降低了管理負擔，同時改善了普通使用者在不同資源中登入認證的重複繁瑣過程，為日常工作提供了更高的安全性。

統一使用者中心

IAM可以為企業所有的資源使用人員如普通使用者、系統管理人員、駐場代維人員、合作伙伴、臨時工作人員等定義主賬號，按照公司的組織方式對人員進行管理。透過一對一的主賬號管理模式，可以在該平臺實現對所有資源使用人員進行集中定義、集中維護等生命週期管理。

統一認證與鑑權

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

9、微服務管理

服務管理機制

• 服務提供者：

1. 服務註冊

   在服務註冊時，需要確認下eureka.client.register-with-eureka=true引數是否正確，預設為true，若設定為false將不會啟動註冊操作。

2. 服務同步

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

3. 服務續約

   eureka.instance.lease-renewal-interval-in-seconds引數用於定義服務續約任務的呼叫間隔時間預設30秒。

   eureka.instance.lease-exptration-duration-in-seconds引數用於定義服務失效時間，預設為90秒。

• 服務消費者：

1. 獲取服務

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

2. 服務呼叫

   服務消費者在獲取服務清單後，透過服務名可以獲得具體提供服務的例項名和該例項的後設資料。因為有這些服務例項的詳細資訊，所以客戶端可以根據自己的需要決定具體呼叫哪個例項。

單服務異常導致雪崩

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

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

自我保護

當網路分割槽故障發生時，微服務與Eureka Server之間無法正常通訊，而微服務本身是正常執行的，此時不應該移除這個微服務，所以引入了自我保護機制。

服務註冊到Eureka Server之後，會維護一個心跳連線，告訴Eureka Server自己還活著。Eureka Server在執行期間，會統計心跳失敗的比例在15分鐘之內是否低於85%，如果出現低於的情況，Eureka Server會將當前的例項註冊資訊保護起來，讓這些例項不會過期，儘可能保護這些註冊資訊。

服務容錯處理

1. 資源隔離：包括執行緒池隔離和訊號量隔離，限制呼叫分散式服務的資源使用，某一個呼叫的服務出現問題不會影響其他服務呼叫

2. 降級機制：超時降級、資源不足時(執行緒或訊號量)降級，降級後可以配合降級介面返回託底資料。

3. 熔斷：當失敗率達到閥值自動觸發降級(如因網路故障/超時造成的失敗率高)，熔斷器觸發的快速失敗會進行快速恢復。

4. 快取：提供了請求快取、請求合併實現。

精選提問：

問1：服務下線之後，eureka預設有30秒的心跳，怎麼做到優雅下線呢？

答：spring-boot-starter-actuator中提供了/shutdown的方式優雅下線。

問2：微服務中事物的一致性怎麼保證？

答：事務一致性保證：可靠事件模式、補償模式、TCC。

問3：hystrix不更新了，有別的替換元件嗎？

答：hystrix不更新，可以選擇Resilience4j和Sentinel。

問4：服務提供者a 往eureka註冊了服務，不希望 B 能看到這個服務。能做到嗎？

答：應用註冊到Eureka可以進行分組，服務消費端可以指定訪問目標應用的其中一個組內的例項。

問5：IAM的授權是全域性的還是隻是賬戶管理系統的，全域性的怎麼實現資源和資源組的統一管理？

答：IAM提供統一賬戶管理，授權對企業來說是全域性的。資源指的是應用功能許可權的話，可以集中管理或者應用自治，按需選擇。

問6：微服務是否適合高併發實時資料的處理？

答：微服務是一種架構風格，具體裡面的應用可以是實時交易類、資料分析類，並沒有限制。

問7：微服務與大資料、分散式的關係，微服務對環境的要求是什麼，單機是否可以部署微服務？

答：微服務是一種架構風格，通常採用分散式部署。如果是做demo部署到單機沒問題。

問8：hystrix或sentinel能否做到對應用叢集整體的流控/熔斷控制啊？

答：整體的熔斷一般手工做。比如透過負載均衡下線。流控hystrix貌似不管。建議流控在閘道器上做。