大型金融生產系統設計原則

摘要：隨著金融創新和金融改革的不斷推進和深化，大型金融企業正面臨前所未有挑戰和變革，生產系統穩定運行成為衡量企業服務質量的重要標準。為確保系統的建設成功與可持續發展，在系統的建設與技術方案設計時應遵循正確的設計原則。針對大型金融企業科技管理需求出發，結合大量生產運維經驗，提出了架構設計七項原則，并進行逐項剖析，提出相應實施建議。

關鍵詞：業務連續性;應用系統;設計;原則;架構

中圖分類號：TP311

文獻標識碼：A

文章編號：1009-3044（2020）04-0218-03

收稿日期：2019-12-05

作者簡介：劉鑫璐（1985—），男，上海人，工程師，主要研究方向為大型金融生產系統管理。

The Design Principles of Large Financial Production System

LIU Xin-lu

（China Securities Investor Services Center，Shanghai 200135，China）

Abstract：With the promotion of financial innovation and reform，large financial enterprises are facing unprecedented challenges and changes.The stable production systems have become an important standard to measure the service quality.In order to ensure the success and sustainable development of the system construction，the correct design principles should be followed in the system construction and technical scheme design.According to requirement of IT management of large-scale financial enterprises，combined with a lot of production and operation experience，the paper puts forward seven principles of architecture design，does corresponding analysis，and provides implementation suggestions.

Key words：business continuity;application system;design;principle;architecture

1 背景

系統架構設計是根據新系統的邏輯模型建立物理模型，在用戶提供的環境條件下，設計出一個能在計算機網絡環境上實施的方案。如果說需求分析解決了系統“是什么”和“干什么的問題，那么系統設計則解決“怎么干”。系統設計的好壞在根本上決定了軟件系統的優劣?？梢哉f“差的系統設計必定產生差的軟件系統”，但是不能保證“好的系統設計必定產生好的軟件系統”。

什么是優秀的系統設計？這個問題頗有爭議，但幾乎每個軟件工程師和架構師都追求優秀的系統設計。當然，系統設計并不代表結果，系統設計只是架構師或者帶頭程序員的工作，優秀的系統設計必須經由良好的項目管理和團隊努力，經過分析需求、設計、開發、測試、分發、維護，以及迭代或重構的過程。中間哪個環節出了問題，再好的設計都將功虧一簣。

可能每個人都對自己設計的系統很自信很滿意，但“實踐是檢驗真理的唯一標準”。如果一個系統設計經過實踐證明，大家（指客戶或用戶）公認為優秀的系統，那就是一個優秀的系統設計，在大型金融企業中更是如此，優秀的系統設計可以經得起大業務交易量和大業務并發量的考驗，可以完美支撐生產系統穩定運行，為科技部門贏得高效工作效率和業務部門的充分認可。下文介紹大型金融企業生產系統的應用設計原則。

2 設計原則

大型金融生產系統為滿足業務連續性要求，應著重考慮應用設計。應用設計除注重功能性需求外，應需遵循以下七大原則，包括：高可用、可擴展、高安全、高性能、易維護、可理解、經濟性[1]。

下面將對各設計原則進行詳細描述。

2.1 高可用

系統可用性是應用研發人員在整個系統設計研發、測試、投產過程中都必須重點考慮的問題，可用性程度的高低直接影響到業務系統持續對外提供服務的能力?？梢哉f，高可用是大型金融企業系統需要具備的最基本的要求之一。

實現系統的高可用需要對應用設計和基礎架構兩個層面進行統一考慮。針對基礎架構層面的高可用性進行長期、深入、與時俱進的研究，并借助基礎架構高可用的設計思路和過往的運維經驗，提出以下三點建議：

第一，冗余設計[2]。盡可能避免單點風險，即系統中任何一個模塊出現異常停止服務時，不會影響整個系統持續對外服務。根據以往經驗，總控程序、公共服務數據庫等模塊容易成為單點。

第二，檢錯設計。當系統中某些模塊出現故障未能按預期執行時，系統應能夠自動恢復或提示運維人員手工處理，以此提高系統的可靠性。例如，日終批量執行、定時調度執行和核心數據庫備份等重要操作就有必要進行檢錯設計。

第三，降低系統復雜度。系統復雜度越高，可能出現故障的環節也就越多，潛在的風險點就越多，因此在設計過程中，應本著以簡為美的原則，通過降低系統復雜度來提升系統的可用性。

另外需要加以說明的是，應用系統的高可用性并非依賴于某個硬件設備或者軟件產品的可靠性來保證的，高可用是一個全局性問題，需要綜合考慮軟件設計、基礎架構設計、軟硬件產品特點等多個方面。

2.2 可擴展

大型金融企業的應用系統面臨著較大的并發訪問壓力，并且當前正處于并發訪問數量快速增長的階段。一方面大型金融企業客戶數量巨大，另一方面隨著服務種類的增多以及服務渠道的便利，實際業務量正在不斷增長。因此，在應用設計之初就要將可擴展性作為最重要的設計原則之一。關于可擴展性，需要從程序和數據兩個層面來考慮，有如下兩點建議：

第一，程序上實現集群架構[3]。利用負載均衡技術，將應用系統設計成多應用節點并行的集群架構。集群中各個應用節點不依賴于某個應用節點的內部資源，如內存數據、IP地址端口、文件等，即各個節點完全獨立且對等，不存在相互依賴或者調用關系，使得集群規?？砂葱鑼崿F動態、彈性擴展。

第二，數據上按照業務邏輯進行拆分。進行數據拆分的目的是為了提升系統的并發訪問能力，更好地滿足并發訪問需求，拆分粒度需視具體情而定。例如，應用系統支持將數據庫拆分成聯機庫與歷史庫，或者按照地區、客戶號、業務類型等進行拆分;在單個數據庫內部，可以使用分區技術對若干大表或熱表進行邏輯或物理上的拆分。

2.3 高安全

隨著大型金融企業信息化進程的不斷推進，業務運營及日常辦公都依托于信息化平臺，各類重要文件及敏感數據需要通過計算機和網絡進行存儲和傳輸，信息安全問題受到內部管理層及外部監管部門的高度重視。從系統運維及管理的角度出發，有以下安全性建議：

第一，敏感數據加密。對于業務系統中的敏感數據，如用戶名稱、密碼、賬戶信息、身份證、交易金額等數據在傳輸、存儲過程中必須進行加密。對于配置文件中的敏感字段，如IP地址、各類用戶及口令等也應該進行加密保存，參數化管理。密鑰應滿足一定復雜度，且定期（三個月或更短）進行更改。

第二，采用加密方式進行文件傳輸和訪問。對于信息傳輸和訪問，建議使用SSL等安全性較高的協議替代Http、FTP等高風險協議，保證數據在傳輸及系統訪問過程中的安全和可靠。

另外，大型金融企業信息系統的分級分類管理規范及開源軟件使用的指導意見都與系統安全性相關，下文分兩個小節給出主要內容。

2.3.1 系統分級分類

按照系統的服務對象、服務時間、監管要求及安全等保要求，來考慮應用系統的可用性及安全性設計，并配置相匹配的基礎架構和資源。如直接面向外部客戶服務、7x24小時、等級保護三級以上的應用系統與面向內部經營管理、5x9小時、等級保護三級以內的系統，在高可用設計、安全性要求及資源配置上會有較大的差異。對于同類型系統，可按照使用頻度再進行細分，如使用頻度較高的聯機業務系統和使用頻度較低的歷史查詢系統有必要在設計之初就予以考慮。

2.3.2 開源軟件使用

除了商業軟件外，共享軟件、免費軟件和開源軟件已成為軟件行業不可或缺的組成部分，越來越受到企業級用戶的關注和使用。結合大型金融企業的實際情況，對這三類軟件的管理和使用，建議如下：

1）限制使用共享軟件。共享軟件往往在使用時間或者功能上有一定限制，因此僅限于短時間、小范圍的試用或驗證，不宜大范圍使用。如需大規模使用，則同商業軟件相同，需購買使用。

2）謹慎使用免費軟件。使用免費軟件時，必須提前研究清楚相關的協議聲明，明確“免費”所指范疇是個人使用還是商業使用，只有對商業使用免費的軟件才能使用。

3）穩妥使用開源軟件。建議優先選擇成熟的、主流的開源軟件。第一，若所選核心基礎軟件（如Linux）為開源軟件時，應同時購買相應的技術支持和服務，以降低使用風險。而對于開源的輔助工具類軟件（如Eelipse等開發工具，或是Firefox等瀏覽器），一般無須技術支持;第二，采用或基于開源軟件源代碼開發大型金融企業專有軟件，應注意開源許可證類型，建議選擇商業友好的開源軟件及其源代碼;第三，開源軟件版本往往變化較快，新老版本的兼容性、穩定性、升級頻度要做好合理評估，有必要做好開源軟件的版本管理[5]。

2.4 高性能

評價應用系統的性能好壞主要有兩個指標，一是吞吐量，即單位時間內能夠處理的交易量，二是響應時間，即用戶執行一筆交易所需的時間。

對于某個特定的業務，應用系統的性能與以下兩方面因素密切相關，一是應用設計的水平，二是基礎軟硬件產品的支撐能力。前者具有主觀能動性，后者為前者提供服務的同時自然也形成了約束，二者相輔相成，不可分割，需要綜合考慮，統籌規劃。

當前，大型金融企業為適應業務發展需要和應用系統特點，不斷豐富、完善基礎軟硬件產品體系，努力改善由基礎軟硬件能力不足所造成的功能缺失或者性能瓶頸等問題，但僅僅依靠更換高端設備和提升資源配置來提高應用系統性能是遠遠不夠的，這種做法治標不治本，且成本消耗巨大。通常來講，采用提升資源配置的方式來提升性能，投入產出比是小于1的，即資源配置增加一倍所獲得的性能提升小于一倍，其效果是邊際效應遞減而且存在拐點，即資源擴充到一定程度反而導致整體性能下降。因此，提升應用及架構設計水平才是解決性能問題的關鍵。

2.5 易維護

系統投產上線后仍會面臨各種業務功能及基礎架構方面的變更，因此為了減輕應用和系統運維工作量，減少變更所需時間，應用系統有必要朝著易于維護的方向設計，盡量避免在運行過程中出現修改代碼等情況。鑒于此，提出如下四條建議：

第一，高內聚、低耦合。高內聚，即應用中單個模塊內部應盡可能完成一系列極為相關的功能，高內聚設計能夠提升系統的可維護性和可重用性。低耦合，即盡量降低兩個模塊之間的依賴程度，比如，程序中應盡量使用DNS或主機別名，而不是固定的IP地址，這樣當IP地址變化時對應用無影響6。

第二，參數化配置。建議將系統或環境變量以參數形式統一放在配置文件或數據庫中管理，當需要進行調整時，僅需要修改對應配置項即可。

第三，良好的日志設計。日志能夠幫助應用或系統維護人員在問題診斷時快速定位，通過參數化的配置可以調整日志的詳簡程度。例如日志輸出問題代碼所在的模塊或函數，甚至能具體到某一行，并且能根據參數設置不同級別的日志輸出。

第四，自我狀態檢測。建議應用具有自我狀態檢測功能，提供狀態檢測接口，并能及時、有效地與公共的集中監控系統通信，便于較早發現運行中的各種異常情況，將問題化解于萌芽狀態。

2.6 可理解

架構是系統成敗的關鍵，只有內聚單一的架構才能足夠的簡單，這樣系統就變得更容易理解，才能更好保證架構的正確性。架構的正確性是設計出來的，而不是測試出來的。如果設計時候架構不夠內聚單一，可理解性就不是很強，而是單單靠功能測試來驗證架構的正確性，就會出現海森堡的測不準原理帶來的問題，即潛在問題無法預知。比如在一個高吞吐流量處理的場景下，設計一個無鎖架構，如果架構不能完全看懂，僅通過測試去保證正確性幾乎不可能，測試時是無法窮盡所有場景的。

不易理解的架構一般都是復雜耦合的內部組成從而帶來的晦澀性，往往都是架構抽象的廣度和深度不足導致的，對問題的本質缺乏足夠理解。如果抽象層次不夠，就會對業務中重復的部分沒有消重合并，造成架構不夠清晰。

當然架構一步抽象到位很難，是一個逐步推薦演變的過程。建議做好架構持續演進，做好簡單的架構設計，逐步豐滿和實現，往往更容易激發出其新的抽象思路。

2.7 經濟性

在此背景下，金融企業為增加生存能力，必然采取降低成本，擴大利潤的做法來應對。追求以最小的投資獲取最大的利益，IT的投人也同樣如此。表現在IT部門需要加強基礎軟硬件使用的精細化管理，為應用系統設計出最合理的基礎架構支撐環境;應用研發部門需要考慮在適應新的基礎架構的同時滿足業務的需求，以最合適的基礎架構和應用架構來支撐業務發展，從而不斷提升系統架構的性價比和投資回報率，降低IT成本。

經濟性的原則主要是根據應用系統的重要性等級制定相匹配的架構設計。例如，對直接面向外部客戶服務或直接影響對外服務的這類應用，其停止服務成本極高，影響巨大，因此不論從應用設計還是基礎架構選型都應優先考慮成熟、穩定、高可用、高性能的解決方案，而對于內部服務且可用性要求相對較低的這類應用在架構設計時要控制投人，滿足業務運營要求即可。當然，如果能夠采取投資不高，而可用性、可擴展性高的方案是最為理想的，當前互聯網企業廣泛采用廉價的IT基礎架構構建集群服務系統值得參考借鑒，在軟件研發投人和基礎架構投入方面尋求比較合理的均衡點，以獲得最佳投資回報率應該是我們共同追求的目標。

3 結束語

本文結合大型金融企業應用系統設計實踐和經驗，制定了系統架構設計規范中的七項設計原則。其中，高可用、可擴展和高安全是大型金融企業系統的根本屬性，在應用設計過程中應始終關注，必須確保系統上線后能夠平穩運行，并且能夠滿足監管部門日趨嚴格的安全性要求;高性能和易維護是大型金融企業系統的關鍵屬性，直接關系到生產運營的效率;可理解是架構抽象程度的表現，對于架構設計的傳承和理念普世起到了關鍵的作用;經濟性是指在滿足系統需求的前提下，還必須考慮系統架構的性價比和投資回報率，防止過度設計造成不必要的浪費。七項設計原則代表了架構設計中的不同考量維度，在實際工作中需要綜合評判和認定，設計出優秀的應用系統架構不再是難事。

參考文獻：

[1]高岳.淺談銀行操作風險管理系統的設計原則與總體架構[J].信息系統工程，2013（12）：62-63.

[2]孟劍萍.高可用性軟件架構設計和實現[J].微型機與應用，2011，30（17）：19-21.

[3]趙峽策.基于Nginx和Memcache的負載均衡集群架構設計[J].電子技術與軟件工程，2014（5）：39-40.

[4]趙玲.淺析數據加密技術[J].電大理工，2008（4）：45-46.

[5]車路，張煥遠，夏亞東.基于開源軟件的云監控平臺設計與實現[J].計算技術與自動化，2015，34（1）：136-140.

[6]程春蕊，劉萬軍.高內聚低耦合軟件架構的構建[J].計算機系統應用，2009，18（7）：19-22.

[通聯編輯：謝媛媛]