微服務架構和安全體系設計方案

文/韓道岐

1 行業現狀和問題

銀行現有的IT架構已經不能滿足互聯網秒殺、低成本高用戶群覆蓋、技術自主可控等要求。銀行的傳統IT架構面臨下列問題（圖1）：

應用系統投產后的運營過程中，業務并發和數據量迅速成倍增長，數據庫運維壓力越來越大。業務監管、業務創新等需求，導致系統變更頻繁，需要進一步縮短新業務上線和系統變更維護的計劃停機時間。新老系統切換需要更穩健的升級方案。

反觀大型互聯網企業的系統，高峰并發能達到百萬級別，大量使用廉價X86平臺構建分布式云計算處理系統，自主研究和引入成熟開源技術，構建自主可控的各層平臺軟件，面向服務方式構建可擴展多層次架構。通過分而治之的策略，化解了大用戶量、大業務量的問題。

而很多銀行的新一代核心系統規劃，進行讀寫分離、業務分庫表的優化，賬戶和產品分離、支付和產品分離、核算和產品分離，使用不同技術構建混合平臺模式的私有云，也提高了整個系統的并發能力。一些關鍵業務不再依托特定的軟硬件平臺，使用開放技術構建。

在某大行實施了更自主可控、低成本的軟件定義的服務目錄技術，在單數據中心內部服務調度能力也可達到20萬/秒，并可很好的支持多數據中心并行服務、兩地三中心災備的大規模分布式部署要求，尋址和故障切換對應用透明。

表1：兩種云化技術的功能對比

圖1：傳統IT架構面臨的問題

2013年，容器技術被Docker的橫空出世再一次引爆，其核心價值在于隔離性、封裝性與跨平臺部署。這就使得在微服務架構下的企業IT，可在開發、測試、運維過程中更加快速敏捷。企業在面臨應用的快速迭代壓力下，開始思考基于docker容器技術的下一代云變革，基于docker完善的工具鏈，逐層堆積組件集，按需構建應用，迭代各類精益調整的參數、配置文件、腳本，如圖2所示。

2 主要技術方案

使用虛擬化技術實現IAAS層的自動化、大規模部署。使用openstack等開源技術，實現網絡、存儲、計算節點的虛擬化創建，提供云的資源管理、應用自動調度、監控、日常運維工具，使用docker技術固化系統和應用的安裝鏡像，如表1所示。

使用分布式隊列、異步可靠消息、面向服務的封裝技術，實施PAAS層功能的服務化。提供一個更好的支撐分布式應用開發、運行、測試的框架平臺。

針對金融應用，提供固化的模型應用框架，快速開發調整。多租戶的SAAS服務模式，可互聯網方式運營應用服務，集中建設服務長尾。

根據上述需求，設計系統的整體軟件邏輯架構如下四層：

（1）容器平臺服務：輕量級容器技術，更高的性能、更快的部署速度應用+運行環境整體打包，一次構建，重復部署。

（2）平臺軟件服務：開源和廠商的各類中間件的集成，如：Tomcat、WAS、RDS（Oracle、mysql）、MQ（ActiveMQ、Kafka）、SLB(nginx、HA-proxy)，構建云化基線版本。

（3）支撐開發測試流水線DevOps，云上開發環境，云上測試環境服務化及部署。構建編譯、打包、鏡像制作、部署的全流程自動化。

（4）分布式微服務框架，海量服務自動注冊、發現、路由、調用鏈跟蹤與日志實時處理分析。高性能與擴展性，提供服務開發框架和微服務管理體系。使用統一的IDE工具集成開發、測試、服務框架、微服務管理功能，具有一體化、提高復用性、大規模團隊分工協作等優點。

研究的創新點在于：提供高效尋址緩存和分布式服務注冊中心機制，把上述三層的云服務統一管理、發布，通過管理臺，隨時隨地可以獲得各類資源狀態、容錯調用。重點解決分布式的準實時一致性、上億用戶并發的響應性能問題、實時容錯能力三方面難題。

3 新一代架構設計

新一代最主要的特點為分布式、使用廉價的X86集群、虛擬化管理和擴展。

新架構可以橫向擴展，容量和并發不再受限，系統容錯和可維護性強。

需要平臺化一些設計特征，提供安全可靠的服務容器，避免復雜的應用處理邏輯；針對公共需求固化公共組件，服務方式訪問組件，避免組件耦合，最終減少每個應用系統的開發工作。

3.1 分布式

新的分布式架構，需要實現數據庫、應用、存儲、網絡、計算節點的多節點并行計算，水平可在線動態擴展，垂直可分層分類隔離。通過全局的服務總線，松散耦合服務提供者和服務消費者；通過數據復制防丟失，數據多副本后，可提供不同服務，可水平擴展服務訪問能力。

提供統一的分布式服務容器平臺，支持各類技術組件、業務組件的部署和運行。相關服務規范，由平臺統一實現，組件建設項目組只需關注組件功能目標。

分布式部署后，各系統間須使用標準化的服務方式訪問，接口清晰易用、易調試，服務發布和服務訪問由服務容器平臺配置化實現，提供流程和各步驟訪問關系視圖、一致的調試日志視圖，方便理解和維護。

平臺使用插件機制，固化服務代理、服務組裝、服務發布三類插件，都可以配置化部署在不同的計算節點上。通過DRQ分布式實時處理隊列進行消息可靠傳輸處理，提供消息排隊和優先級調度機制，根據服務接口字段配置化路由，分發給內部不同插件服務、分發給外部不同服務節點。DRQ提供數據緩存池機制，使用HASH內存池的方式高效率處理，KEY/VALUE方式簡潔訪問，自動的編解碼數據，通過網絡方式、本地DRQ隊列方法高效傳輸數據。DRQ提供了同步消息傳輸、異步消息傳輸、響應消息的自動匹配、消息唯一性、生命周期登記和清理等機制，基于DRQ的這些機制，實現上層的各種服務模型會簡化、可靠。

平臺提供集群部署和管理服務，避免單點故障；無需一次性投入，可以根據業務的發展，增加機器；可以將不同類型機器組成集群部署(比如AIX、HP-UX、Linux等)

針對運行節點、插件、服務、應用模塊、配置項資源，提供了動態安裝、啟動、停止、更新和刪除機制。多版本并存，更新時，不影響當前版本，可預約新版本生效時間點，集群內部的同時更新生效。

圖2：Docker的C/S服務架構

提供故障身份ID的識別和自動隔離機制，周邊服務系統的故障會被服務容器快速識別和隔離，不影響其他服務的正常處理。

提供服務降級機制，控制服務并發量。可對服務、目的方、客戶化應用條目，設置流量控制策略，并可以根據歷史的成功率情況動態調整目的方并發數閾值。

3.2 尋址

服務的訪問通過標準化和服務容器平臺固化后，應用調用服務處理變得簡單、高效。

應用可以透明、動態、高效的找到目的服務方，服務方可以靈活的水平拆分、不影響消費者的調用，是新架構第二個要解決的問題。

大量的服務地址，可以通過總線平臺的服務代理插件配置，固化在總線平臺中。缺點是當服務提供者發生擴容、服務地址切換、新服務投產等事件時，總線平臺必須進行手工調整。總線平臺的擴展和容錯，還要依托負載均衡設備。

新架構設計了尋址組件和服務目錄組件，實現軟件方式的本地動態尋址，這樣大量的內部尋址需求，可以避免依賴負載均衡設備和手工管理切換。通過AGENT隔離和授權、訪問ACL、黑白名單、流量控制等機制，保障服務體系的安全可控。架構建議應用調用服務時，至少兩次尋址容錯、并保證使用唯一的全局流水號，提高成功率、避免服務重復處理，發生不一致時，可以根據全局流水號跟蹤異常。

優勢在于：服務的狀態是動態注冊進入服務目錄的，實時在整個數據中心內部同步，服務消費者在本地發現服務，直接訪問服務，取消了對負載均衡設備、總線平臺的依賴。服務控制、負載均衡、資源節能調度或擴容、故障隔離、災備切換、靈活路由等功能，都統一封裝在尋址組件中，更一體化、自動化。

難點在于：服務訪問需要標準化，消費者不再關心提供者的服務協議。需要規范各系統的服務訪問實現，尋址、服務控制、監控登記，需要改造調用尋址組件的API。服務容量大幅提高后，給日志備份和分析、實時監控、指標統計、高效故障切換等實現帶來數據量的壓力，相關系統也必須使用分布式技術改造。

服務總線可以先完成尋址改造，一些服務組合和條件路由還是依托總線平臺實現，不能下沉給服務消費者。

假設使用用戶ID作為分段，水平切分服務時，消費者需使用該ID做應用尋址條件字段，訪問服務方。跨多個用戶的整合事務服務，需要獨立建設系統，記錄和保障分段的多個事務的一致性。

3.3 緩存和文件

為消除應用服務對數據集中訪問的依賴，需要根據其變化頻率和生效要求，定性出固定參數、非實時變更、動態數據、強一致性要求的賬務數據。對不需要實時串行保持一致性的數據，采用復制和緩存技術，提高訪問效率。通過緩存機制訂閱關注的數據變更，減少網絡的廣播數據量。

平臺級所有的資源配置都通過XML文件，部署到運行環境中，提供多版本的緩存裝載、生效機制，運行引擎通過緩存訪問最新版本配置項。

為應用級的靜態參數，如：技術參數、業務參數、客戶化表達式處理，提供KEY/VALUE形式配置和緩存裝載，可以按需動態加載新版本后，應用使用統一API訪問最新版本的配置。

針對動態數據，提供可讀寫的緩存機制，在服務處理過程中，根據需要動態登記緩存，按記錄多版本管理數據。固化實現動態裝載數據庫表、動態裝載數據文件的處理程序，在相關資源發生變化時，根據配置文件定義，自動完成裝載緩存處理。作為備份服務器的緩存，需要能實時備份數據到文件系統中，保證消息類緩存的可靠性和可恢復。建議一次寫提交、少量或無數據變更、大量讀查詢、能夠忍受1秒變更信息延誤的業務場景下，使用緩存機制。而頻繁更新、需要高可靠一致性的數據修改處理，不能使用緩存。

分布部署時，文件服務也可以使用動態緩存機制，把文件直接放入緩存并從緩存中讀取文件，對應用透明化文件的存放位置。保存文件時，需要先注冊文件目錄所在的動態緩存服務器，然后寫入動態緩存服務器。讀取文件時，需要先尋址文件目錄存放地址后，再從對應的緩存服務器讀出文件。支持分塊傳輸和異步斷點續傳客戶端。

文件服務也需要通過注冊方式登記到服務目錄中，應用可使用尋址方式獲得文件服務器地址，使用標準發送、接收文件API完成可靠的文件傳輸，也可以交給客戶端異步任務方式完成可靠的文件傳輸。傳輸API根據配置選擇使用異步還是同步的方式寫入備份服務器，通過配置兩次寫文件，讀失敗再通過備份服務器嘗試讀一次，提高文件的讀寫可靠性。

分布式哈希表DHT，是目前主要的大規模分布式存儲方式，可不需要服務器方式，組織松散的P2P網絡結構，利用各類資源組成大規模的數據共享服務。對于動態數據緩存和文件數據緩存，使用其中比較成熟的一致性HASH算法和KAD算法。

一致性哈希算法（Consistent Hashing）最早在論文《Consistent Hashing and Random Trees: Distributed Caching Protocols for Relieving Hot Spots on the World Wide Web》中被提出，可以很好實現資源的均勻分布和快速按線索搜索。簡單來說，一致性哈希將整個哈希值空間組織成一個虛擬的圓環，如假設某哈希函數H的值空間為0-2^32-1（即哈希值是一個32位無符號整形），整個哈希空間環按順時針方向組織。0和232-1在零點中方向重合。各個服務器使用Hash進行一個哈希，具體可以選擇服務器的ip或主機名作為關鍵字進行哈希，這樣每臺機器就能確定其在哈希環上的位置。數據key使用相同的函數Hash計算出哈希值，并確定此數據在環上的位置，從此位置沿環順時針“行走”，第一臺遇到的服務器就是其應該定位到的服務器。

KAD（Kademlia）算法，由于其簡單性、靈活性、安全性成為主流的實現方式。KAD無需服務器，通過ID異或機制劃分距離空間，幾次近鄰詢問跳轉，就可查詢網絡中的鄰居節點、關鍵字字典、文件種子、文件索引字典等信息。每個路由節點中使用隊列保存多個節點，使得節點查詢更迅速、命中概率更高，隊列中根據活躍時間進行換入換出，更有利于在p2p這種節點變更頻繁的網絡中快速找到有效的節點。

3.4 自動化和手工相結合實現的最終一致性

在軟硬件故障率大幅下降的情況下，交易出現最終不一致的概率會大大降低。通過各環節的設備冗余，服務調用的2次容錯嘗試，也可以降低故障影響。

通過監控系統的吞吐情況，在超過警戒線時，及時增加相關資源，保證各環節沒有堵塞消息、可橫向擴展、在最小的時間范圍內完成處理，也會增加最終一致性的比率。

當多個分布處理步驟場景下，某個步驟出現業務錯誤時，通過自動沖正機制，實現異步的多次回滾各個成功步驟，解決不一致性的問題。有一致性問題后，應及時提示客服人員，對當前超過一定時間沒有完成回滾的交易，進行人工核對和手工回滾。日終進行多系統流水數據的自動化核對，發現不一致情況，批量調整。

針對賬務類和關鍵類服務，還可以提供統一的差錯接收服務，各系統在發送異常時推送差錯消息。通過全局業務流水號，可展示各服務的完整性處理過程，方便集中處理中心的人員及時發現問題、分析問題，手工處理。

分布式架構下，過程的不一致會在短暫時間內產生的，因此業務流程設計時，必須保證每個步驟執行后，產生的信息或資金不一致狀態情況，不會出現業務風險。如先扣款保證資金安全、不會重復入賬處理，然后可以通過客服和事后調整解決問題。

3.5 云部署管理

在廉價的X86上，可以提供大量的虛擬化計算節點，分布式部署后，系統的安裝、啟停、更新、監控、調度、日志和異常分析，不再是簡單登錄到一個節點控制臺即可完成的任務。需要一個完善的分布式部署、采集和管理框架，批量化完成大量節點的管理，自動化完成采集、分析、展現、調度資源、屏蔽故障的處理。

首先是服務容器和應用系統，提供穩定的版本包，制作到docker或kvm的虛擬化安裝鏡像中，IAAS平臺創建完相關虛擬化設備資源后，就可以直接安裝鏡像。然后是提供一鍵化安裝腳本，根據虛擬化結果的物理環境，自動調整操作系統、平臺、應用的設置，裝載一些標準化的參數數據。

對經常需要更新的應用、代理、第三方軟件包等擴展程序，能夠使用鏡像倉庫樹型結構集中管理，登記相關版本包和依賴包、更新信息、差異比對情況、交付時間、驗證測試時間、上線時間、各階段責任人。在集群中，并行的命令方式執行下面的任務：出庫版本并上傳，部署新版本（解包、復制到部署目錄）、啟動、停止、重啟、平滑刷新新版本、回退指定版本。

提供agent完成受控端的命令式處理（啟停、實時查詢等），預警、日志、狀態定時采集處理。異常及相關錯誤信息的實時推送到展現端。

4 安全性

注冊中心支持多租戶的定義，集中控制所有服務的注冊和尋址，可以方便的擴展各類安全控制策略。需要管理相關用戶口令，訪問的令牌，各類密鑰。

服務消費者和提供者，都必須先自助在線上管理系統完成參與者定義，申請需要訪問的服務、由提供方系統管理員授權，在線上管理系統獲得用戶、口令、APP KEY、證書、AGENT包，才能在生產環境中訪問注冊中心、注冊服務、尋址服務。AGENT定時與注冊中心認證、動態請求維護accessKey。消費者尋址成功后，AGENT提供一次性訪問安全上下文（由服務、地址、用戶名、accessKey、時間戳組成串，簽名獲得），在訪問服務時必須提供安全上下文；服務方需驗證簽名，確認消費者身份后，完成授權檢查。對服務方返回的結果數據，同樣需要服務方簽名，消費者驗證簽名，確認服務方身份后，進行后續處理。

在參與者調用API時，登記服務審計記錄，保存現場信息、耗時信息。通過AGENT定時收集審計記錄，匯總到注冊中心，在注冊中心統計、查詢。

5 結論

通過分析行業現狀，提出了服務總線平臺建設要求和關鍵技術方案。結合多個銀行總線項目的落地實踐過程，建議切實可行的目標平臺應用架構。

服務平臺還需要加強網絡安全的4個領域功能：保密、認證、不可否認和完整性。由下列內容組成：各類加解密算法，保密的密鑰，安全認證和認證保持，信任憑證的保持和遷移。

在平臺上應用相關安全技術，可響應目前國家倡導的安全、自主可控方針，將關鍵的銀行業務系統，安全、平穩的過渡到分布式的SOA架構中。