- 《架構世界》2020金融刊：DevOps與微服務在金融業的應用
- 普元信息
- 4447字
- 2020-09-03 11:24:21
三、微服務架構關鍵技術
微服務平臺技術圖譜
微服務技術桟：
:
:
基礎框架：
微服務容器：
服務發布：
服務注冊中心： -
服務路由： -
服務調用： -
服務熔斷器： -
安全認證： -
服務配置中心：, -
服務監控：
關鍵技術架構與設計
我們從這個方面來解析微服務關鍵技術架構與設計。
、前端框架
兼容性
是流行的前端框架，其對瀏覽器的兼容性較好，主流的操作系統和瀏覽器都支持。
響應式雙向數據綁定實現自動同步
.采用數據劫持結合發布者-訂閱者的方式，通過.（）來劫持各個屬性的，，在數據變動時，發布消息給訂閱者，觸發相應的監聽回調。
具體的來講，.通過指令去對做封裝，當數據發生變化，會通知指令去修改對應的，數據驅動的變化。.還會對操作做一些監聽（ ），當我們修改視圖的時候，.監聽到這些變化，從而改變數據。這樣就形成了數據的雙向綁定。
、微服務容器
微服務運行的容器環境
我們來看一下微服務運行容器，要做可靠高效的微服務架構應用，實際上我們需要做的事情還是非常多的。如果沒有一個統一的微服務容器，這些能力在每個微服務組件中都需要建設一遍，而且會五花八門，也很難集成到一起。
微服務容器：負載均衡
微服務容器的基礎服務能力之一就是支持負載均衡。
. 通常所說的負載均衡都指的是服務端負載均衡，其中分為硬件負載均衡和軟件負載均衡。硬件負載均衡主要通過在服務器節點之間安裝專門用于負載均衡的設備，比如等；而軟件負載均衡則是通過在服務器上安裝一些具有負載均衡功能或模塊的軟件來完成請求分發工作，比如等。
. 硬件負載均衡的設備或是軟件負載均衡的軟件模塊都會維護一個下掛可用的服務端清單，通過心跳檢測來剔除故障的服務端節點以保證清單中都是可以正常訪問的服務端節點。當客戶端發送請求到負載均衡設備時，該設備按照某種算法（比如線性輪詢、按權重負載、按流量負載等）從維護的可用服務端清單中取出一臺服務端的地址，然后進行轉發。
. 客戶端負載均衡和服務器負載均衡最大的不同點在于上面所提到的服務清單所存儲的位置。在客戶端負載均衡中，所有客戶端節點都維護著自己要訪問的服務端清單，而這些服務端的清單來自于服務注冊中心，建議使用 的組件。
微服務容器：服務熔斷、容錯、升降級、限流
微服務容器的基礎服務能力之二就是服務熔斷、容錯、升降級、限流，在系統出現異常時提供故障恢復能力。
、注冊中心
服務注冊與發現
接下來我們聊一下注冊發現，以前的單塊應用之間互相調用時配置個就行了，但在微服務架構下，服務提供者會有很多，手工配置地址又變成了一個不可行的事情。那么服務自動注冊發現的方案就解決了這個問題。
我們的服務注冊發現能力是依賴 組件實現的。服務在啟動的時候，會將自己要發布的服務注冊到服務注冊中心，運行時，如果需要調用其他微服務的接口，那么就要先到注冊中心獲取服務提供者的地址，拿到地址后，通過微服務容器內部的簡單負載均衡器進行路由。
一般情況，系統內微服務的調用都通過這種客戶端負載均衡的模式進行，否則就需要有很多的負載均衡進程。跨業務系統的服務調用，也可以采用這種去中心化的路由方式。當然采用的模式，由中心化的服務網管來管理系統間的調用也是另一種選擇，要結合企業的現狀和需求來決定。
、配置中心
集中配置管理
微服務分布式環境下，一個系統拆分為很多個微服務，一定要告別投產或運維手工修改配置的方式。需要采用集中配置管理的方式來提升運維的效率。
配置文件主要有運行前的靜態配置和運行期的動態配置兩種。靜態配置通常是在編譯部署包之前設置好。動態配置則是系統運行過程中需要調整的系統變量或者業務參數。
要想做到集中的配置管理，那么需要注意以下幾點：
. 配置與介質分離，這個就需要通過制定規范的方式來控制。千萬別把配置放在包里。
. 配置的方式要統一，格式、讀寫方式、變更熱更新的模式盡量統一，要采用統一的配置框架
. 運行時需要有個配置中心來統一管理業務系統中的配置信息，這個就需要平臺來提供配置中心服務和配置管理門戶。
配置修改同步交互
配置修改后通過推送或者定時拉取的方式更新并緩存到應用程序所在的微服務容器中供應用程序使用。
高可用運行架構設計
配置中心有兩種部署模式
. 高可用模式，見上圖，支撐大規模微服務訪問時根據負載情況可以對“配置查詢同步服務”進行橫向擴展
. --模式，配置變更服務、配置查詢服務合并為一個進程。適合支撐少量系統的場景使用。
配置中心可以支持高可用模式部署，滿足金融行業的要求。
、監控中心
基于定制實現
主要就是通過收集各種格式的數據進行存儲，然后展示。所以我們需要關注的是 、 和存儲設備。
探針
是 .以后引入的，也可以叫做代理。
是運行在方法之前的攔截器，它內定的方法名叫，也就是說先執行方法然后再執行方法。
使用技術構建一個獨立于應用程序的代理程序（即為），用來協助監測、運行甚至替換其他上的程序。使用它可以實現虛擬機級別的功能。
全鏈路運行監控
調用鏈跟蹤分析：把同一的收集起來，按時間排序就是。把串起來就是調用棧。
實時分析：對單條日志直接分析，不做匯總，重組。得到當前，延遲。
離線分析：按匯總，通過的和還原調用關系，分析鏈路形態。
、日志中心
日志中心架構
日志分析是運維工程師解決系統故障，發現問題的主要手段。日志主要包括系統日志、應用程序日志和安全日志。系統運維和開發人員可以通過日志了解服務器軟硬件信息、檢查配置過程中的錯誤及錯誤發生的原因。經常分析日志可以了解服務器的負荷，性能安全性，從而及時采取措施糾正錯誤。
通常，日志被分散的儲存在不同的設備上。如果你管理數十上百臺服務器，你還在使用依次登錄每臺機器的傳統方法查閱日志，即繁瑣又效率低下。為此，我們使用集中化的日志管理，將所有服務器上的日志收集匯總。
集中化管理日志后，日志的統計和檢索又成為一件比較麻煩的事情，這時實時日志分析平臺能夠完美的解決上述的問題，由、和三個開源工具組成。
規范日志與流水，問題追根溯源
作為一個微服務應用平臺除了提供支撐開發和運行的技術組件和框架之外，還應該提供一些運維友好的經驗總結，我們推薦的日志與流水實現如下：
. 先來看日志，平臺應提供的日志主要有三種，系統日志，引擎日志還有跟蹤日志。有了這些日志，在出問題的時候能夠幫助我們獲取一些關鍵信息進行問題定位。
. 要想做到出了問題能夠追根溯源，那么右邊的這些流水號的設計也是非常重要的，日志與各種流水號配合，能夠讓我們快速定位問題發生的具體時間地點以及相關信息，能夠快速還原業務交易全鏈路。對這些日志與流水的細節處理，對于系統運維問題定位有非常大的幫助，沒有這些有用的日志內容，日志收集套件搭建的再漂亮，收一堆垃圾日志也是沒用的。
通常開源框架只是提供個框架由開發人員自由發揮，而設計一個平臺則一定要考慮直接提供統一規范的基礎能力。
、
基于 的組件定制實現
異步非阻塞模式啟動的線程很少，基本上一個 上只需啟一個處理線程，它使用的線程資源就很少，上下文切換（ ）開銷也少。非阻塞模式可以接受的連接數大大增加，可以簡單理解為請求來了只需要進隊列，這個隊列的容量可以設得很大，只要不超時，隊列中的請求都會被依次處理。
邏輯架構
網關就像整個系統的門面一樣，所有的外部訪問都經過它實現調度、過濾、請求路由、負載均衡、校驗等等。
功能
網關上還可以實現更多更復雜的功能。
、（ ）
架構
為企業提供統一的賬號管理視角，對所有基于賬號的管理、認證、授權、審計進行集中的統一管理，提高了賬號管理的安全，幫助系統管理員提高了工作效率，降低了管理負擔，同時改善了普通用戶在不同資源中登錄認證的重復繁瑣過程，為日常工作提供了更高的安全性。
統一用戶中心
可以為企業所有的資源使用人員如普通用戶、系統管理人員、駐場代維人員、合作伙伴、臨時工作人員等定義主賬號，按照公司的組織方式對人員進行管理。通過一對一的主賬號管理模式，可以在該平臺實現對所有資源使用人員進行集中定義、集中維護等生命周期管理。
統一認證與鑒權
安全認證方面，我們基于 結合再加上（ ）做安全令牌，實現統一的安全認證與鑒權，使得微服務之間能夠按需隔離和安全互通。認證鑒權一定是個公共的服務，而不是多個系統各自建設。
、微服務管理
服務管理機制
? 服務提供者：
. 服務注冊
在服務注冊時，需要確認下..--=參數是否正確，默認為，若設置為將不會啟動注冊操作。
. 服務同步
由于服務注冊中心之間因互相注冊為服務，當服務提供者發送注冊請求到一個服務注冊中心，它會將該請求轉發給集群中相連的其他注冊中心，從而實現注冊中心之間的服務同步。
. 服務續約
..----參數用于定義服務續約任務的調用間隔時間默認秒。
..----參數用于定義服務失效時間，默認為秒。
? 服務消費者：
. 獲取服務
當我們啟動服務消費者時候，它會發送一個請求給服務注冊中心，來獲取上面注冊的服務清單。為了性能考慮， 會維護一份只讀的服務清單來返回給客戶端，同時該緩存清單會每隔秒更新一次。
. 服務調用
服務消費者在獲取服務清單后，通過服務名可以獲得具體提供服務的實例名和該實例的元數據。因為有這些服務實例的詳細信息，所以客戶端可以根據自己的需要決定具體調用哪個實例。
單服務異常導致雪崩
采用微服務架構后，服務之間會有錯綜復雜的依賴關系，例如，一個前端請求一般會依賴于多個后端服務。
在微服務架構中，存在著那么多的服務單元，若一個單元出現故障，就很容易因依賴關系而引發故障的蔓延，最終導致整個系統的癱瘓，造成所謂的雪崩效應，這樣的架構較傳統架構更加不穩定。
自我保護
當網絡分區故障發生時，微服務與 之間無法正常通信，而微服務本身是正常運行的，此時不應該移除這個微服務，所以引入了自我保護機制。
服務注冊到 之后，會維護一個心跳連接，告訴 自己還活著。 在運行期間，會統計心跳失敗的比例在分鐘之內是否低于%，如果出現低于的情況， 會將當前的實例注冊信息保護起來，讓這些實例不會過期，盡可能保護這些注冊信息。
服務容錯處理
. 資源隔離：包括線程池隔離和信號量隔離，限制調用分布式服務的資源使用，某一個調用的服務出現問題不會影響其他服務調用
. 降級機制：超時降級、資源不足時（線程或信號量）降級，降級后可以配合降級接口返回托底數據。
. 熔斷：當失敗率達到閥值自動觸發降級（如因網絡故障／超時造成的失敗率高），熔斷器觸發的快速失敗會進行快速恢復。
. 緩存：提供了請求緩存、請求合并實現。
推薦閱讀
關于作者：黃豆，普元信息數字化金融研究院研究員，擅長系統分析和架構設計、金融三級密鑰安全體系及信息安全保障、虛擬化和云計算技術、技術；參與研發的神州商橋電子商務平臺獲得“全國電子商務示范單位”稱號；帶領團隊研發的國電通云終端系統在國網多個省公司推廣應用。