4.2  架構準備階段

        在架構準備階段，主要是分析使用者的需求，推薦採用“ADMEMS矩陣”矩陣方法進行需求結構化，即“需求層次-需求方面矩陣”。

        通過業務級需求、使用者級需求、開發級需求三個層次，功能、質量、約束三個方面對使用者需求進行二維需求觀分析，抽取出決定架構的關鍵需求。

        ADMEMS矩陣如下圖所示：

        以下是分行特色業務雲平臺的關鍵需求，主要包括關鍵約束、關鍵質量和關鍵功能。

        另外，根據這些關鍵需求，抽象出業務架構檢視，從業務概念的角度，描述了整個系統要實現的功能。作為一種架構檢視，本人把這部分內容放到《細化架構階段-業務架構》部分，以便提供一個完整的架構檢視。

4.2.1  關鍵約束

        1.採用Java語言；

        2.採用行方自主研發的Tesla平臺作為基礎開發平臺；

        3.採用分散式服務設計風格；

        4.前期（一期、二期）應用執行在叢集環境，後期遷移到基於Docker的雲服務平臺；

        5.前期（一期、二期）資料執行在關係資料庫環境，暫時不用考慮分庫分表，後期隨著業務量的增加，必須考慮分庫分表；

        6.專案週期：

        一期：2017年3月1日至2017年7月31日，主要完成基於Tesla平臺的分行特色業務雲平臺的搭建工作，含部分通用公共元件；

        二期：2017年8月1日至2017年12月31日，主要完成分行特色業務雲平臺通用技術元件、業務元件、業務服務的開發、與不少於6個分行進行業務對接等；

        三期：2018年1月1日至2018年5月31日，分行特色業務雲平臺分庫分表、雲服務平臺遷移、業務對接等；

4.2.2  關鍵質量

4.2.2.1  效能

        系統必須滿足預期的效能目標，在併發使用者數（Concurrent Users）、併發事務數（Transactions per Second，TPS）、響應時間、吞吐量（Throughout）等指標方面達到預估值，支撐使用人群的正常使用操作。

        分行特色業務雲平臺預期的效能指標如下：（非叢集環境）

        1.併發使用者數：200。

        2.併發事務數：300。

        3.平均響應時間：100ms。

4.2.2.2  可用性

        可用性是指系統在指定時間內提供服務有效訪問的特性。

        分行特色業務雲平臺至少保證可用性是3個9，即軟體具有較高可用性，也就是說軟體年度不可用時間小於9小時。

        分行特色業務雲平臺要在以下幾個方面支援系統的高可用性： 

        1.高可用的應用 

       支援叢集化部署：使用F5進行負載均衡，使用基於suce linux的X86虛擬機器進行叢集部署；

        支援雲化部署：允許分行特色業務雲平臺遷移到行方的私有云，該私有云基於Docker實現。

        2.高可用的服務

        服務降級熔斷：當外部系統不可用或連續出現結果異常時，應可達到服務降級的效果，全熔斷或部分熔斷異常服務容量，保證正常服務的可用性，防止出現雪崩效應。

        服務流量控制：對某一特定服務提供併發量控制，通過修改引數配置可調整服務併發數量。

        服務物件權重控制：提供對不同服務物件（模組）的流量權重控制，通過修改引數配置可調整對不同服務物件提供服務的權重比例。

        服務開關：單個服務動態開關，系統整體狀態動態開關。

        叢集服務流量控制：針對於一個特定服務提供叢集併發量控制，通過修改引數配置可調整服務併發數量。該功能推出後，可替換單例項流控的方式。

        客戶化併發控制：針對某一特定服務，解析接入報文資料後，對指定資料項匹配後做併發控制，如：針對某一商戶進行單獨併發控制。

        3.高可用的資料

        支援總行資料庫DB2的高可用。

        對於分行資料庫的高可用性，由分行自己實現。

        4.高可用的軟體質量保證

        程式碼：對程式碼版本進行控制。

        測試：支援自動化測試。

        服務灰度釋出：對外服務變更時，做到對分行特色應用的透明，在驗證週期內，保證對非驗證分行應用不受影響，使得服務變更對分行特色應用造成的影響最低。

        5.執行監控

        程序/服務監控：對本地服務、程序繁忙情況提供監控介面，供系統負責人進行監控。

        實時交易：對實時交易基本要素進行監控：交易金額、成功情況、耗時、渠道、客戶資訊等提供實時監控。

        對流程編排過程的監控。

        監控預警：設定告警級別，告警方式，告警規則，告警活動。

            告警級別：自定義，頁面顯示，預設告警方式不同；

            告警方式：郵件，簡訊，頁面展示；

            告警規則：該條告警執行的操作（如取連續3筆後臺響應超時的交易），針對一個告警規則，指定告警級別及告警方式；

4.2.2.3  伸縮性

        伸縮性指不需要改變軟硬體設計，僅僅通過改變部署的伺服器數量就可以擴大或縮小軟體的服務處理能力。

        分行特色業務雲平臺需要支援多臺伺服器構成叢集，並且加入新的伺服器後可以提供和原來的伺服器無差別的服務。

4.2.2.4  擴充套件性

        擴充套件性指在對現有系統影響最小的情況下，系統功能可持續擴充套件或提升的能力。

        分行特色業務雲平臺需要具備良好的擴充套件性，能在系統基礎設施穩定不需要經常改變的情況下，對需求變更可以敏捷響應。

4.2.2.5  安全性

        安全性指保護系統不受惡意訪問和攻擊，保護重要資料不被竊取。

        分行特色業務雲平臺需要保證總分之間、第三方與總行、分行之間通訊安全，保證敏感的資料不外洩。

        1.通訊安全

            標準加解密功能：使用總行標準安全加解密方法提供給分行使用。

            標準加驗籤功能：使用總行標準安全加驗籤方法提供給分行使用。

        2.資料安全

            日誌脫敏功能：實現關鍵敏感字的日誌脫敏功能。

            加密儲存功能：FTP密碼明文儲存、資料庫密碼明文儲存修改為加密儲存。

4.2.3.1  公共技術功能

        1.服務編排

        使用Tesla的服務編排元件，進行復雜流程服務（涉及兩個及其以上服務呼叫、以及需異常處理的服務）的封裝。

        2.基於Dubbo的服務呼叫

        基於Tesla3.0的服務呼叫方式，實現服務位置的透明發現，軟負載呼叫，服務超時設定，併發控制等功能。

        服務許可權管控等功能目前重點通過平臺數據庫控制機制實現，註冊中心上的管控方式依賴於註冊中心的可用性，僅作為輔助控制方法。

        3.公共聯機處理框架

        實現公共的聯機處理框架，提供通用的服務接入處理，包括入參預處理、初始化交易流水、更新交易流水、出參預處理等功能，對服務呼叫透明化，簡化業務開發。

        4.統一渠道接入能力

        通過API閘道器，接入總行公共渠道，在閘道器上實現通訊協議解析，安全認證，流量控制，資料轉換，協議轉換等功能。

        5.統一訊息通知

        服務通過配置化實現交易前、交易成功、交易失敗、交易異常的訊息通知機制，呼叫訊息通知元件，與聯機服務框架解耦。通知的方式可擴充套件，通知失敗後的處理規則可選擇。優先實現簡訊方式。

        6.統一異常處理

        服務通過配置化實現異常處理的自動處理，當異常處理到達最大重試上限後，將異常處理資訊推送異常處理平臺。同時，支援異常處理平臺回撥平臺服務的實現。

        7.非同步任務排程

        支援非持久化非同步任務排程和持久化非同步任務排程。

        8.本地快取

        實現基於本地記憶體的快取元件，快取執行過程中極少變更的配置資料和業務資料。除此之外，本地快取元件需要實現如下功能：

            實現快取查詢服務、快取更新服務（遠端服務、本地服務）等快取管理功能；

           基於Zookeeper的Watch機制，實現了叢集環境中，快取更新事件的釋出與訂閱，以支援該元件在叢集環境中的使用；

            為了保證叢集各節點快取都進行了更新，在控制檯增加了相應快取檢視，快取更新功能，便於應用例項與ZK之間出現通訊異常時，快取仍然能正常更新；

            同時支援基於ZK的自動更新和基於控制檯的手動更新，各應用根據實際情況配置；

            同時支援應用級本地資料快取和模組級本地資料快取，各自管理，互不衝突；

        9.自動任務排程

        實現自動任務排程元件，以支援平臺任務的定時排程，具體功能如下：

            支援Tesla平臺Function功能的跨模組呼叫；

            支援任務持久化；

            支援叢集和分散式任務；

            分執行緒池管理；

            任務排程定義可配置化管理；

        10.總分報文通訊元件

        實現公共的報文通訊元件，供分行呼叫總行的服務，對分行遮蔽報文協議解析封裝、壓縮解壓、簽名驗籤功能。另外，提供靈活的擴充套件機制，供後續功能的擴充套件。

        11.公共檔案處理元件

        實現檔案配置化的組裝、解析功能。

        12.總分檔案互動元件

        分平臺與總平臺或後臺公共模組檔案互動的方案實現，使用公共元件，使分行對總分檔案互動方式做到透明化。

        13.全域性序列號發生器

        實現資料庫儲存全域性序列號，應用啟動時載入流水號段。

        14.分散式叢集檔案配置

        使用Tesla現有的配置管理中心能力實現，用於分散式應用的叢集技術引數的配置。同時，配置的修改有歷史記錄可追蹤，提供審計資訊檢視功能；

        15.公共返回碼管理

        實現基於資料庫的公共返回碼管理，便於全平臺的返回碼資源共享，便於檢視，維護。支援啟動時載入資料庫內容至本地快取，支援動態重新整理。

        16.分庫分表

        應對大交易量交易對資料庫單表造成的操作壓力，支援進行分庫分表操作，對錶進行水平拆分和縱向拆分。

        17.資料歸檔元件

        應用系統對於長時間執行後，某些記錄數過大（存量/增量指標）的表，且不需要提供實時查詢的資料，應提供歸檔機制，直至滿足監管和行內要求的最低保留時限，以避免資料無限增長對系統容量和執行效率造成負面影響。歸檔資料可考慮備份至本系統歷史庫，也可考慮歸檔至歷史歸檔平臺。

        18.檔案歸檔元件：

        對於不需要長期保留的檔案，如對賬檔案，產品資訊檔案等，需要提供定時清理機制，系統應可配置保留天數，超過天數（建議7天）的檔案自動清理。

        對交易日誌檔案，實現自動定期備份、歸檔和清理，避免因檔案數量過多導致應用處理效率低下。對接ELK或日誌歸檔平臺進行備份後，自動清理。

        19.標準通訊SDK

        供接入商戶使用，整合加解密、數字簽名等安全功能，通訊協議拆解包等通訊功能，統一接入標準，簡化商戶接入難度。

        20.公共批處理框架

        實現批處理框架，以支援大量作業的併發處理、併發控制、異常處理等，具體要求如下：

            互斥控制：

                1)互斥作業應有防止併發控制機制；

                2)單個批處理應控制併發重複執行；

                3)前後依賴關係的批處理應保證順序執行；

            併發控制：對大資料量（量化）批處理應可實現併發處理，通過多執行緒/程序或資料庫層實現併發，併發數可動態調整；

            斷點執行：單個批處理處理過程中失敗，修復問題後應支援斷點處繼續執行；

            緊急跳過：對於無法短時間修復的批處理，能提供緊急跳過該步驟，繼續後續批處理功能；

            通知機制：批處理開始、結束、異常等情況，可通過郵件和簡訊通知相關人員；

            CPS排程：批作業應支援CPS系統排程發起交易和本地管理端發起交易。對處理失敗的批處理，可通過本地管理端再次發起該作業；

            異常業務資料通知：對批處理過程中遇到不影響繼續處理，但存在異常或可疑的資料，產生工作流任務或實時通知業務人員進行非同步處理；

            定時任務自定義：系統提供自定義的定時自動任務，完成經常調整的定時任務，不建議通過系統的crontab定義自動任務。與其他系統有關聯的作業，不建議使用此方式；

            與聯機交易衝突：

                1)批處理過程應儘量減少聯機（計劃內）的可用性；

                2)考慮資源（資料庫資源/網路資源/程序資源等）不影響聯機交易的可用性；

            作業監控：對批作業狀態及進度提供展示介面；

4.2.3.2  公共業務功能

        1.應用日終元件

        完成平臺通用的修改平臺狀態、切日前任務處理，切日任務，切日後任務處理功能。同時，支援多個切日前任務的依賴關係、多個切日後任務的依賴關係分別可配置，根據依賴關係順序執行。

        2.日終對賬元件

        對分平臺提供公共的日終對賬能力，從支付平臺按商戶獲取商戶對賬單檔案，商戶手續費檔案。

        3.額度控制組件

        實現額度控制組件，支援通過配置化的資料項，控制指定交易的額度佔用及釋放。可按照資料級的顆粒度進行配置，如控制某個商戶發起的指定交易額度控制規則。

        在後端有額度控制功能前提下，可不進行配置，避免效能損耗。

        4.頻度控制組件

        實現頻度控制組件，支援通過配置化的資料項，控制指定交易的頻度佔用及釋放。可按照資料級的顆粒度進行配置。如控制某個商戶發起的指定交易頻度控制規則。

        在後端有頻度控制功能前提下，可不進行配置，避免效能損耗。

        5.通用黑白名單控制組件

        通過配置的資料項，從指定的上下文中根據key=value的組合找出控制主鍵，並且對該主鍵進行黑名單准入或白名單准入功能。

4.2.3.3  基本服務封裝

        1.PE-支付引擎

        封裝總行支付引擎提供的通用支付相關的服務，預計17個，根據後期具體業務需求而定。

        2.UNPS-統一網路支付系統

        封裝統一網路支付系統提供的線上支付相關的服務，預計27個，根據後期具體業務需求而定。

        3.NPS-網路支付系統

        封裝網路支付系統提供的線上支付相關的服務，預計2個，根據後期具體業務需求而定。

        4.RLS-零售貸款系統

        封裝零售貸款系統提供的貸款相關的服務，預計5個，根據後期具體業務需求而定。

        5.移動支付收單系統

        封裝移動支付收單系統提供的移動支付相關的服務，預計5個，根據後期具體業務需求而定。

4.2.3.4  流程服務封裝

        1.支付結算服務封裝

        2.資訊查詢服務

        封裝支付/退款結果查詢、交易結果查詢、商戶提現/餘額查詢等服務。

        3.輔助服務

        封裝一些通用功能服務，如總分檔案傳輸服務等。

  微信掃一掃，關注該公眾號

  該系列文章已經在微信公眾號釋出，如果感興趣，請關注。

   以後更多知識通過該微信公眾號分享。