銀行大型IT系統建設，未來10年何去何從？
2019年秋天的一個晚上，我在某股份制銀行總部的會議室中做分佈式銀行系統架構的研討，會議室中除了銀行方負責技術的領導，還有幾個阿里的P8和P7。我們針對兩個技術專題已經討論了一整天，大家已經非常疲倦。會議室突然安靜了下來，這時，銀行領導突然感嘆道：難道我們只能“摸着石頭過河”嗎？
這個問題當時我們不知道如何作答，只能感受到領導心裏沉甸甸的壓力，還有對新技術的陌生感，以及對未知問題的憂慮。現在4年多時間過去了，我也做了4個銀行核心系統，其中有分佈式的、有單元化的，也有云原生的。不少銀行已經完成分佈式、單元化系統建設，也有很多銀行正在做雲原生轉型。現在我們已經探索出分佈式、單元化，以及雲原生的完整技術方案，以及沉澱了一大批技術產品。
本文我將對分佈式、單元化、雲原生架構中的主要技術產品逐一剖析，對於沒有單元化及雲原生核心實踐經驗的讀者，本文也許能成爲您跨越“信創大河”的墊腳石。對於有實踐經驗的讀者，我姑且拋磚引玉。
01
分佈式、單元化其實是必由之路？
大約自2017年開始，國內中小銀行開始鋪開JAVA銀行核心的建設，這時採用服務註冊發現機制JAVA銀行核心開始號稱爲分佈式銀行核心。隨後大行業逐漸建設分佈式核心，由於數據量較大，不得不模仿支付寶的單元化架構。在客戶數據量達到億級的時候，IBM的小型機處理起來的確很喫力，而大型機則過於昂貴。“堆x86或RAM服務器”成爲了大家不約而同的選擇，支付寶率先遇到海量數據問題，所以它先探索出解決單元化解決方案。
還記得2016年底我們上線貴州農信核心系統，客戶量是7千萬，數據庫服務器採用IBM的兩臺E880服務器，配置是80核1T內存。2018年初我們上線河北農信，客戶量是1個億，數據庫服務器也是採用兩臺E880服務器，配置是88核1T內存。這樣的小型機在國內當時已經是頂配了，我們還是非常擔心無法支撐系統上線，經過程序的大量調優後才上線的。對於農信尚且如此，對於國有大行和股份制銀行其實是很難支撐的，所以說單元化架構也是大型銀行必然的選擇。
另外，銀行的老機房一般是建設在市中心地段，所在區域的房價和地價太高，不宜在原地址擴建機房，必須在其他地方建立新機房。單元化架構正好能協調兩個機房的流量，這也是單元化架構被選擇的必然原因。
02
單元化、雲原生架構是空穴來風？
技術風潮從來都不是空穴來風。最初，我以爲單元化這個詞是英文翻譯過來的，加入阿里之後才發現是我們團隊前輩創造的。爲了打造技術話語權，佔領技術高地，引領技術風潮，最終售賣技術服務和產品。頂尖的佈道者們每個週會都會討論技術方向、技術方案，以及技術名詞，他們是就是風的起點。
單元化架構的推廣離不開佈道者的努力，雲原生架構的成熟也離不開雲廠商的大力宣傳。無論是佈道還是商業宣傳，無疑都大大推動了國內IT技術發展。但是，靠跟風很難做好大型IT系統設計，大型IT系統建設週期和使用週期都很長，一般長達十多年。在十多年間互聯網巨頭的宣傳日新月異，其戰略可能發生了巨大調整。猶記得兩年前某互聯網巨頭大力進軍銀行核心系統，現在已經解散團隊、戰略收縮，這給正在實施其核心繫統的銀行帶來不少麻煩。
本文儘量闡述清楚相關技術的來龍去脈及其本質，使我們能在紛繁複雜的商業宣傳與佈道中認清技術方向、去僞存真，做好大型IT系統的技術選型和規劃。
03
皇冠上的明珠
阿里的一位老領導曾說：“如果金融系統是IT業的皇冠，那麼銀行核心系統則是皇冠上的明珠”。銀行核心的技術架構是最爲規範的，其對技術組件的技術要求也是最爲嚴苛的，本文主要剖析銀行核心的架構和組件，期望管中窺豹，看到技術發展的一些脈絡。雲原生架構分爲IaaS、PaaS、SaaS三層，其中IaaS爲基礎資源層，PaaS爲中間件、開發運行運維組件層，SaaS爲應用層，最近兩年在PaaS層與SaaS層中間出現了aPaaS層。
04
IaaS層
長治久安之道
對於私有云來說IaaS層本質是計算、存儲、網絡的虛擬化管理，公共雲的IaaS則是使用這種虛擬化管理方式向大衆提供共享計算服務。兩者有本質區別，公共雲重點採購便捷靈活、’初期成本低，私有云講究融入企業IT管理現狀中，企業人員方便好用。對於大型企業來說，採用雲來對整個企業的IT資源進行管理，能大幅度提升資源利用率，這的確是一種不錯的選擇。目前需要大量算力的應用只有數據處理、風控、客服等，未來隨着人工智能應用的普及大型企業對算力的需求會越來越高，採用私有云來對算力進行動態管理和分配是必由之路。
大型企業絕不能把希望寄託在公共雲上，這無異於假焉託質。首先是數據在生產運營中的重要性越來越高，未來數據安全將等同於企業的命脈；其次是公有云的水位一般都在90%以上，發達地區Region的水位還會更高。目前上海地區使用公有云的部分大型企業都不得不提前採購一些ECS，以備業務高峯期使用，所以按需採用節約成本也是不成立的。從長期來看，大型企業建立自己的私有云平臺，纔是長治久安的戰略。
量體裁衣自建雲
國內IaaS做得好的廠商有華爲、阿里、騰訊，其中阿里是最早研發雲的廠商，其技術體系較成熟，但也比較老。華爲和騰訊是基於OpenStack進行深度二開實現的，技術較新，也是比較主流的實現方式。近兩年基於OpenStack二開的雲廠商如雨後春筍在國內蓬勃發展，這體現雲的門檻已經沒有幾年前那麼高，稍微大一點的企業完全可以基於OpenStack構建自己的私有云。
OpenStack是一系列IT資源管理的開源軟件組合而成。其主要組成部分有負責計算資源管理的Nova、負責對象存儲管理的Swift、負責塊存儲管理的Cinder，以及負責網絡的Neutron。
簡單的來看，雲就是對計算、存儲、網絡的管理。在計算方面OpenStack採用的是Nova進行管理，其負責虛擬機創建、開機、關機、掛起、暫停、調整、遷移、重啓、銷燬等操作，以及配置CPU、內存等信息規格。真正對物理機做虛擬化（VM）的組件是hypervisor。相當於Nova負責調度hypervisor生成虛擬機，並管理虛擬機。
在雲上要支持動態的擴縮容，容器裏的本地磁盤是隨時可能被釋放的，所以必須有專門的存儲管理軟件。OpenStack支持對象存儲和塊存儲，對象存儲是一種扁平化和離散化管理文件的方式，簡單的看就是把文件拆分成多份，分散到各物理存儲中存放，以提升讀寫速率，並能實現備份。由於是採用扁平化的管理結構，文件查找效率也遠高於塊存儲。雲上的塊存儲類似於傳統的本地磁盤存儲，採用樹狀的文件目錄管理模式，通常掛載爲雲服務器的本地盤。
雲上的網絡是虛擬網絡，簡單的理解就是利用網絡傳輸軟件對物理路由和交換機傳入傳出的數據進行包頭解析，根據包頭信息發送到相應的目標服務器上去。相當於在物理網絡包頭的基礎上封裝一段軟件可以解析的報文頭，用該報文頭來實現虛擬網絡層的數據包傳輸。這樣就能用軟件控制網絡傳輸，通過複雜的控制可以模擬出一個虛擬的網絡（VPC）。OpenStack是採用Neutron實現的虛擬網絡傳輸，它的功能比較簡單，沒有較全面的模擬物理網絡，目前比較成熟的開源虛擬網絡傳輸軟件是Overlay。國內不少雲廠商的虛擬路由和虛擬交換機都是基於這個款開源軟件打造的。用軟件定義路由器和交換機後，就使得在雲上部署複雜的軟件系統集羣，甚至是部署整個機房得以實現。不過，虛擬網絡在物理層數據傳輸是不隔離的，數據傳輸的安全性是需要重點關注的。
OpenStack還有身份服務Keystone、鏡像服務Glance、測量服務Metering、部署編排Heat、數據庫服務Trove。本文就不再一一列舉，以便重點分享我愚鈍的見解和有限的經驗。
私有云本質上是一種企業IT資源管理方式，上述的IaaS組件其實是企業IT物理資源管理的工具。在使用這些組件時一定要無縫對接企業自己的管理系統，把企業的日常IT管理架融入雲中。只有“量體裁衣”建立私有云，才能讓雲提升企業的管理和運營效率，纔是成功的雲原生轉型。
05
PaaS層
PaaS發展的三個階段。
第一階段、利用雲便捷的建立技術組件實例
應用的運行環境從物理機到虛擬機再到容器，支持應用運行的技術組件也逐漸增多，從最初的一個weblogic全部搞定，到現在的統一網關、消息隊列、分佈式事務、分佈式緩存、內存級緩存、數據庫中間等等。隨着雲技術的發展，各種技術組件被雲廠商封裝成技術能力在雲上呈現和售賣，從而形成的雲原生架構中的PaaS層。
PaaS借用IaaS層對物理資源的管理能力，對應用提供便捷的技術能力。例如以前我們項目中若使用到MQ需要在物理機或虛擬機中手工搭建一個MQ環境。在PaaS中只需要點擊一個按鈕能獲得一個MQ環境，其他技術組件亦是如此，這極大的提高了效率，減低了時間成本。
第二階段、採用平臺統一管理技術組件
人們對效率的追求是永無止境的，人心總是難以滿足，這是人的本性，也是技術發展的原始動力。近些年隨着各種技術組件越來越多，各大雲廠商對PaaS技術組件進步進行了集成，形成了更便捷的應用運行平臺，他們把各種技術中間件、監控運維組件等集成在一個統一的運行平臺上，讓應用只需連接到統一運行平臺上，就能使用平臺上的所有中間件，省去了大量中間件和運維監控組件的適配調試工作。阿里的SofaStack、騰訊的TSF、aws的BeanStalk就是目前典型的統一運行平臺。
第三階段、新增aPaaS層，進一步降低業務開發的複雜度
隨着低代碼或零代碼開發的思想逐漸成熟，雲廠商和國內IT服務提供商們發現還能進一步封裝和集成通用的技術能力，進一步減低業務開發的複雜度。於是逐漸產生了aPaaS的概念，aPaaS基於PaaS能力進一步集成並且新增服務編排、批量調度、參數緩存、分佈式序列、熱點資源、對外供數等組件，以及其他輔助業務邏輯實現的技術組件。形成了國內具有特色的大型IT系統開發、運行、維運體系，這些aPaaS組件也許會成爲未來10年國內大型IT系統建設的基石。
註冊中心
註冊中心本質上是一個服務列表管理組件。在註冊中心普及之前服務集羣採用負載均衡進行負載和調度，負載均衡分爲硬負載和軟負載。金融系統對性能和穩定性要求較高而且預算充足，一般採用硬負載，反之則採用軟負載。
2015年～2017年期間，分佈式、微服務架構在國內金融領域應用的初期，有些銀行甚至提出把服務註冊發現機制做到硬負載中去，現在看來是很荒謬，但它體現了註冊中心和負載均衡功能重疊的問題。二者都管理服務列表，只是管理方式不一樣。負載均衡的服務列表需要手工配置，註冊中心的服務列表是自動註冊的。其次交易流量不過註冊中心服務端，而會經過負載均衡。
簡單的說，註冊中心是應用啓動時把服務註冊到其服務端的服務列表，並且同步到消費端的內存中，同時保存一份本地文件。在調用服務的時候直接從內存的服務列表中挑一個服務進行調用。從這個角度來看，我們其實還可以把其他種類控制系統運行的信息推到本地內存中，從而創造其他技術組件，例如我們把業務參數推送到應用系統內存中，從而創造了後文介紹的“緩存同步”。
註冊中心有滿足ACP理論中的AP和CP兩種，目前對性能要求較高的都選滿足AP的註冊中心。註冊中心的功能一般有服務註冊、服務發現、服務註銷、心跳探活、服務訂閱、服務查詢、服務修改等。在單元化架構下注冊中心需要支持單元間註冊信息同步，大部分開源註冊中心是不支持的。單元間服務切換，開源註冊中心也不支持，例如實現當本單元的某個服務存活量低於百分之多少時，流量切換到備單元。另外，一個企業級註冊中心，一定要跟企業的運維監控平臺打通，這要求註冊中心必須提供服務查詢、服務修改、服務註銷等接口，以便於運維管理集成，獲得企業級的服務管理能力。
最早的註冊中心通常是註冊服務接口，這種註冊方式很難實現企業級註冊中心，因爲大型企業的服務接口達到幾萬甚至十萬個，這個量級的服務註冊和發現存在效率問題。這些年大家逐漸採用IP和端口的方式註冊應用實例，這種註冊方式纔可以滿足大型企業幾十萬服務接口的註冊發現。在性能方面除了服務註冊發現的規模和效率，同時啓動進行註冊的節點數量也是重要的考量點，極端情況下的大規模啓動會考驗這個性能點。
配置中心
配置中心和註冊中心本質是一樣的技術組件。當配置信息是服務列表，由服務啓動的時發送通訊進行配置，配置參數消費邏輯改爲服務發現邏輯，配置中心則變成註冊中心。開源的配置中心只是一個demo級的參數管理組件而已，其只能管理key-value類型的參數，多參數間的關係沒法管理，多參數組合的版本也沒法管理，多消費節點間的參數一致性也沒有保證。
大型複雜系統的業務參數是按版本發佈的，每個版本中有大量參數，業務參數的管理和下發開源配置中心無能爲力。隨着分佈式、單元化系統的普及，大型系統的技術參數越來越複雜，在用配置中心下發參數的時候經常遇到下發不及時、每個節點使用的參數版本不一致、複雜的json參數可讀性和可維護性差等問題。在下文中我們自研的參數緩存同步組件已經解決這些問題。
開源的配置中心在大型IT系統中使用時存在着不少問題，但我們爲什麼還把它奉若神器。原因之一是很多人研究源碼但沒有研究原理；其二是不重複造輪子的風氣盛行(什麼情況不用造，什麼情況需要造，在下文將進行論述)；其三是國內的IT技術始終在跟風國際，沒有形成完善的理論體系和產研生態體系。
配置中心一般有配置模板管理、配置值管理、配置訂閱、配置拉取、配置自動推送、配置手動下發等功能。有的配置中心也支持灰度發佈，即配置手動下發時指定單元下發和指定IP和端口下發。企業級的配置中心需要支持多環境多應用管理，以及環境間的參數導入導出。配置中心應提供參數管理接口，以便運維繫統集成，讓運維繫統實現可監可管。形成類似於軍事領域的查打一體的能力，如此才能快速處理系統故障。
在性能方面，企業級配置中心至少要支持一萬個參數以上的配置，同時要支撐幾千個節點拉取參數，參數下發的時效性也不能太長，在實際項目中我們經常發現開源配置中心下發參數太慢，而且沒有下發任務進度管理，導致修改參數後無法知道參數是否已經生效，這對緊急問題處理非常不利。
MQ消息隊列
系統間的通訊一般有同步、異步、文件批量。異步交易主要是用消息隊列實現，也可以用其他方式實現，例如傳統銀行核心採用數據庫記錄實現異步處理。在單元化架構下，分佈式消息組件需要在傳統消息系組件進行一定的封裝，才能爲開發人員提供更簡潔的消息隊列使用方式。例如實現可靠消息機制、分佈式事務消息機制，以及提供多單元、多應用、多環境管理能力、消息交易的路由分發能力。
消息隊列通常的功能有Topic管理(包括Topic的新增、修改、刪除、查找)、消息查詢、消息訂閱關係查詢、手動消息發送等。還有消息重新投遞及設定消息重試投遞次數、設置隊列深度，以及消息類交易的鏈路跟蹤。爲了防止極端情況下消息丟失，在金融場景中通常會對消息進行落庫，以便對消息內容進行查詢、重新處理、存檔。
在監控運維方面，開源的消息隊列組件是比較弱的。企業級消息隊列直接使用開源消息隊列的demo級管理界面顯然是不夠的。未來的系統重在一體化的運維管控，監和控一體的系統管理，這要求消息隊列提供一系列的查詢和控制接口。
在性能方面，消息的投遞耗時主要在於網絡速度和消息體的大小，消息組件自身耗時通常低於1毫秒。消息消費的速度與隊列深度有關，隊列深度一般不設置太深，就能確保消息獲取的速度小於1毫秒。
Redis緩存
Redis 從2024年3月21日開始“不再開源”。其宣佈從 Redis 7.4 版本開始，Redis 將採用 SSPLv1 和 RSALv2 雙重許可證，這種許可下託管 Redis 產品的服務提供商將不再允許免費使用 Redis 的源代碼。這件事現在對很多雲服務提供商產生影響，更深層次的影響是其他開源軟件也有可能隨時“閉源”。如何完成“自主可控”這個課題？這個事件又給我們敲了一記警鐘。
各種中間件，本質上只是輔助我們完成業務邏輯開發的組件，有這些中間件我們能更標準、更便捷的使用各種技術能力，所以只要我們分析透徹各中間件的能力，完全可以自主開發出各種中間。這就是我在文中明確定義和分析各組件功能及性能的意圖，接下來我們詳細分析一下Redis的功能。
Redis其實是一個很雞肋的中間件。在分佈式單元化的大型IT系統中，一般有幾千個JVM節點，每個節點都去訪問Redis緩存，其壓力顯然是很大的，它不適合在大型IT系統當做緩存組件使用。而且Redis在同城雙活架構中無法實現雙活，緩存刷新也需要根據業務系統情況寫代碼進行控制。再則，把緩存放在Redis中，必須通過網絡去獲取，在跨機房訪問場景下需要1~2毫秒，在耗時上完全失去了緩存的高效性。其實它只是在小型系統中使用得較多，例如簡單的鎖場景、簡單的搶購場景、簡單的技術參數或業務數據緩存場景。
在銀行核心系統中，我們一般都不會直接使用Redis。我們在銀行核心系統中一般使用自研的參數緩存同步組件，把緩存直接推送到JVM的內存中去，實現微秒級的緩存獲取能力。
目前的中間件是近10年互聯網技術發展過程中，前人在解決問題過程中沉澱下來的技術組件，我們在解決我們自己遇到的新問題時，也一定會沉澱一批技術組件。特別是在微服務化、單元化、雲原生架構下，我們遇到的問題是10年前的中間無法解決的。其實，在國內銀行核心建設過程中已經沉澱了大量新的“中間件”，但因下文中提到的一些原因並沒有開源出來。Redis已經是10年前的產物，而且在兩地三中心和多地多中心架構下問題頻出，性能受網絡限制並不高。我們爲什麼還會奉若神器？也許是人總善於崇拜，不善於創造。
Redis的閉源事件，更多的是警示，它不會影響我們解決現在和未來的技術問題。它警示我們要打破現有軟件資產管理方式，創造商業軟件開源環境和生態。儘快在國內源碼管理網站，用我們自己的協議開源一批我們自己的中間件，形成產品級開源軟件生態體系。
負載均衡
在系統中能形成負載能力的有很多組件，一般大家講的負載均衡是F5，nginx，SLB等。實際上網關、服務編排、註冊中心等組件進行服務外調的時候，在服務列表中根據算法選擇某個服務進行調用，這過程也能形成負載均衡效果。
在分佈式架構流行之前，應用集羣部署主要靠負載均衡來分發流量，集羣的全部流量都經過負載均衡，使其變成了架構中的‘單點’，該點出現故障全系統都會癱瘓。在之後的分佈式架構中，採用服務註冊發現的方式，通過下發服務列表到消費端，使消費端與服務端直接進行點對點通訊，避免了流量集中經過負載均衡的情況。
負載均衡除了有能按IP和端口轉發流量的四層負載均衡，還有能按報文內容轉發流量的七層負載均衡，四層負載均衡轉發邏輯簡單，流量轉發效率較高，通常可以作爲機房級或大型IT系統入口級負載均衡。七層負載均衡通常需要解析報文，才能根據報文要素進行流量轉發，其處理邏輯複雜，流量轉發效率低，通常用於小型微服務架構系統進行流量分發，在公共雲上的小型互聯網系統常用七層負載均衡。
總之，七層負載均衡看似靈活強大，實則複雜低效。實際項目中，很多架構師總是喜歡靈活強大的組件，抱着既要又要還要的態度，把系統做得極其複雜。其不知架構之道在於平衡，大型IT系統的架構，重在穩定可靠。
在雲原生架構中，網關前面一般由負載均衡GSLB(Global Server Load Balancer)接入流量轉發到網關集羣。其功能一般有監聽配置、後端服務信息配置、心跳探活、順序循環輪詢、加權輪詢、一致性哈希、會話保持等。通常四層和七層負載均衡都支持，四層的TCP協議的負載均衡，即根據IP和端口做負載均衡，七層的HTTP和HTTPS協議的負載均衡，即根據報文信息進行負載均衡。
負載均衡是最重要的流量管控組件，也是服務治理的關鍵節點。有的人認爲服務治理可以用一個產品來實現，實則不然。我見到某公司的一個團隊花了兩年時間做服務治理產品，目前爲止還沒做出可用的產品。根本原因是服務治理不是一個產品，是一系列的規則和理念。需要全系統甚至全企業的各種技術組件配合完成，服務治理的主角其實是監控運維繫統，負載均衡爲監控運維繫統提供流量控制規則的配置接口，監控運維繫統根據監控情況自動或手動調整流量分發規則，才能保障系統長期穩定運行。
在性能方面，四層負載均衡耗時通常在1毫秒內，七層負載均衡則一般需要5毫秒左右。四層負載均衡集羣最大可以支持連接數達10萬以上，新建連接數 (CPS)達一萬以上，每秒查詢數 (QPS)達十萬以上；七層負載效率則低很多，同樣運行資源的情況下，可達到的最大性能指標幾乎是四層負載均衡的十分之一。
分佈式事務
分佈式事務和服務編排有着密不可分的集成關係。某國內互聯網巨頭的服務編排產品最初沒有分佈式事務管理，分佈式事務管理需要在分佈式事務產品中再配置一遍服務流程。我當時給了他們一套分佈式事務管理方案，並建議他們直接把分佈式事務集成到流程編排中。無論是可視化服務編排，還是硬編碼服務編排，只要調用遠程服務就需要分佈式事務組件管理分佈式事務，服務編排可以根據遠程調用服務是否爲非查詢交易，自動開啓分佈式事務的子事務，再根據交易最終狀態調用分佈式事務的回滾或提交，如此則實現分佈式事務的自動管理。
目前，分佈式事務必須跟服務編排結合已基本形成共識，但採用哪種分佈式事務還存在分歧。分佈式事務有XA、AT、SAGA、TCC模式，XA模式性能太低在大型系統中鮮有采用，AT模式在銀行核心系統的自動衝正有采用，但由於它需要登記SQL語句執行的前後值，性能也不高，所以只在對性能要求不高的交易的自動衝正中使用。SAGA和TCC是在大型系統中採用得比較多的，其中建設銀行、中國銀行、郵儲銀行、民生銀行等銀行核心採用的是SAGA模式，支付寶、平安銀行、四川農信等採用的是TCC模式，大家從採用這兩種模式的使用方應該就能感受到兩種模式的優劣。
SAGA採用DO和UNDO一對效果相反的接口，服務編排中的每個節點都先執行DO接口，如果全部執行成功則交易成功返回，如果有某個節點執行失敗則交易返回失敗，然後異步逆序逐個調用UNDO接口，把所有成功的交易都撤銷回原來狀態，形成沒有做過該筆交易的樣子，實現事務的最終一致性。
從SAGA的事務管理過程不難看到，它是沒有隔離性的，也就是交易還沒有最終成功前，部分交易結果已經對外暴露，可以被其他交易修改。如果交易失敗需要回滾，則可能回滾失敗。不過，這種隔離性問題在具體的場景中是可以規避的，例如在銀行的轉賬場景中，可以採用先轉出後轉入的方式避免銀行資損。多借多貸交易中也可以對金額增加方做部分凍結，最後統一解凍的方式規避事務隔離性問。除了個別場景，大部分場景採用SAGA事務是沒有隔離性問題的。
TCC採用Try、Confirm、Rollback三個接口分別實現預留資源、確認資源、回滾資源三個操作。服務編排執行所有節點的Try接口，當全部執行成功時交易返回成功，異步調起所有節點的Confirm接口，對所有資源進行確認。當服務編排中的某個節點執行失敗，則交易返回失敗，異步調起所有節點的Rollback接口，把所有資源都回滾回去，實現事務的最終一致性。
相對SAGA事務模式TCC事務模式較爲複雜，爲了隔離性其設計了中間態，在實際的交易開發時中間態不容易界定，並且有些場景是不宜設置中間態的。例如登記明細，不宜登記一條中間狀態記錄然後再修改爲確定態，因爲明細表的更新效率很低。另外，在實際使用中，對TCC理解不到位的架構師總喜歡把業務邏輯放到Confirm階段執行，因爲這樣比較方便，但實際上Confirm階段只能技術性的確認資源，不能做業務邏輯處理。如果選用TCC，又因很多操作難以抽象成TCC模型，只能使用SAGA，這意味着選擇TCC模型也必須有SAGA模型，這導致系統變成一個混合事務模型，事務管理極其複雜。再加上TCC的二階段需要大量的一階段信息，這種信息的傳遞和存儲對系統的開銷很高。
不少架構師潛意識中喜歡功能齊全、複雜的產品，只有實戰經驗充足的架構師纔會有意識的避免複雜的設計，在功能上去做取捨。從使用案例上來看，大型銀行都使用SAGA，因爲它相對簡單，簡單意味着明確，也意味着可靠。事務組件需要在非常複雜的場景下使用，給使用方提供一個簡單明確的事務規則至關重要。
不重複造輪子是個僞命題。
我爲大型IT系統招聘人員的時候，如果是互聯網IT架構背景的人，我一般都要給他講“造輪子”的道理。目前大部分PaaS層組件基本上是國內互聯網大廠用開源軟件改造的。互聯網技術界流傳着一句話：“不重複造輪子”，這幾乎成爲了所有互聯網軟件架構師的“聖經”。前幾年互聯網2.0在蓬勃發展，互聯網公司採用的是叢林法則，講究的是快速做出能掙錢的產品，砍掉賠錢的產品，其大部分IT系統的生命週期很短。然而大型IT系統的生命週期都是10年左右。當我們做一個生命週期較長的大型IT系統時，我們還是拿“開源的輪子”拼湊嗎？是利用開源深度改造成本高，還是根據技術原理和自身需求進行開發成本高？在大型IT系統生命週期內“開源的輪子”如何更新升級和修復BUG，它閉源了怎麼辦？這些問題都是值得仔細評估的，而不是一句“不重複造輪子”就能定論的。
每個大型企業都有自己的IT歷史、有自己的IT沉澱、有自己的IT規範、有自己的管理規範、有自己的團隊分工。這些是企業的歷史淵源，部分是企業的包袱，部分是企業的資產和驕傲。“開源的輪子”要想完美的架在每一個大型企業下，是不可能的。所以很多大型企業在建大型IT系統的時候儘量都不直接使用“開源的輪子”，他們會根據自身需要新造輪子或深度改造“開源的輪子”，通常會請大量外包人員幫自己造輪子。 幫大型企業造輪子是個“苦力活”，互聯網巨頭們並不願意做這種生意，他們願意做的是那種沒有邊際成本、可以無限複製的標品售賣，至於需要定製的部分交給合作伙伴吧。無論是開源組織、還是有標準產品的大廠，他們都會告訴我們不要重複造輪子，直接使用他們的“輪子”。作爲“輪子”使用方自然不能人云亦云，需要根據企業現狀和未來規劃判定輪子是否合適。對於生命週期較長的大型IT系統，需要根據未來的運維和運營需要來決定是否要“量體裁衣造輪子”。
其實國內銀行核心系統在建設過程中，各軟件服務商已經沉澱了一套能提升業務邏輯開發和運行效率的aPaaS層和工具鏈體系，這些基本上是他們自己造的“輪子”。這些軟件若開源出來，國內也許能形成獨立完整的軟件開發、運行及運維體系。但這些都是商業化產品，而非開源的demo級軟件，這些產品的開源有諸多困難。最大的問題是商業資產外流，如果是國企央企還會涉及國有資產流失問題。其次是國內沒有形成完善的版權機制和共識，開源軟件的盈利模式沒有形成。再次，是產品級的技術組件比demo級的開源組件重很多，綁定了很多特定的應用場景，這不利於其開源推廣使用。只有把這些問題解決了，國內才能形成一套面向當前問題和未來發展的技術組件體系。
06
aPaaS層
當下主要的PaaS組件其實是10年前的技術產物，在單元化、雲原生的架構體系下，直接用PaaS層的技術組件開發應用服務，會產生一系列問題：
業務參數如何同步到各單元、各節點中？
日益突出的熱點問題該如何處理？
按單元拆分的數據如何保證時效的聚合？看似可以使用大數據技術，實則不然。
全局唯一且趨勢遞增的序號如何獲取？
如何讓交易按數據分佈進行路由？
按微服務拆分業務邏輯後，如何快速編排實現完整的聯機交易和批量交易？
如何便捷的實現文件批轉聯機交易？
如何做聯機交易、消息交易、文件交易的協議和格式轉換？
上述問題是近10年來國內外互聯網技術中間件並沒有解決的問題，我們在實際項目建設中需要補充一系列技術組件來解決這些問題。
參數緩存同步
集中式系統逐漸的進行了分佈式、單元化改造，以前的一個大系統拆分成了很多小系統，每個小系統都採用集羣化部署，這使得運行的節點數量增加了十幾倍甚至幾十倍。以往的參數獲取方式在分佈式系統中會導致數據庫連接不夠，並且獲取速度較慢，於是“參數緩存同步平臺”應運而生。與10多年前國外創造Redis的原因一樣，我們也在解決遇到的問題過程中沉澱出我們的技術組件。
大型系統的交易控制較爲複雜，產品、費用、利率等參數很多，交易中使用這些參數的頻率也非常高。如果把這些參數存放在數據庫中，到數據庫中查詢這些參數的總耗時會非常大，即使把這些參數放置在Redis緩存中，訪問參數需要經過網絡，效率依然不高。唯有將參數直接推送到每個應用節點的內存中，纔是效率最高的參數獲取方式。
在大型系統中，業務參數通常是按版本發佈的，所有開源的參數同步產品都無法按版本把參數同步到本地內存中。部分系統爲了提高性能把參數已經加載到內存中，但參數的版本管理、內存參數查看、內存參數覈對等配套功能沒有實現，導致內存中的參數是看不見的黑盒，發生問題時“兩眼一抹黑”。
很多人喜歡把系統的各種緩存混爲一談，總是在全局緩存中加入交易級緩存，在交易級緩存中考慮如何實現全局緩存。分佈式系統中分爲全局緩存、交易級緩存，交易級緩存又分爲組合交易緩存和基礎交易緩存。組合交易緩存是跨遠程調用的，其緩存需要在遠程節點間用返回報文和請求報文傳遞，即聯機引擎自動把緩存內容封裝在上一個節點的返回報文中，在下一個節點通過請求報文傳入，自動解析到內存中，從而實現上一個遠程節點的緩內容傳遞到下一個節點的緩存中。基礎交易的緩存相對簡單，只需在程序中藉助ThreadLocal實現。
參數緩存同只針對全局緩存，主要實現需要按版本管理的業務參數的全局緩存。如果多個技術參數也需要按版本發佈，開源的配置中心是難以實現的，這時也可以用參數緩存同步。參數緩存同步的功能有緩存查詢、緩存加載、緩存更新、緩存同步、緩存覈對、緩存版本管理、緩存版本回滾等。支持版本管理，包括按版本發佈、按版本回退、按版本覈對緩存信息。還支持參數緩存的灰度發佈，即指定IP端口的發佈。爲了實現貫徹監和控一體化的理念，參數緩存同步提供緩存查詢、覈對、手工刷新接口，以便運維管控平臺集成。
應用系統集成參數緩存同步的SDK之後可以在內存中便捷的查詢參數表。其通過攔截DAO層，根據配置自動判斷是否從內存中查詢，使業務程序能無任何改動的方式從查詢數據庫表變成查詢內存表，實現無侵入接入緩存。在查詢緩存的SDK中其建立了一套完善的索引機制，能實現參數查詢只需0.02ms的極致性能。
分佈式序列
2015年阿里提出去“IOE”，其中的O是指Oracle數據庫。喊去掉Oracle數據庫的口號簡單，實則需要付出巨大代價，必須創造一個分佈式序列生成組件是代價之一。
在單元化架構中獲取全局唯一且遞增的序號並不容易，在Oracle數據庫中獲取序列比較簡單，調用一個數據庫函數即可，然而在單元化架構下需要用一個序列生成組件進行產生序列號。其主要原因是去Oracle數據庫後國產數據庫沒有那麼高性能的序列生成能力。個別國產數據庫的Proxy有序列生成能力，但高併發下效率低，而且偶爾會重複；其次，單元化系統的吞吐量一般大於集中式系統，需要的序號生成能力也是大於原來集中式的，這加大了序號生成的難度。所以分佈式序列應運而生，也可以說是在新架構下爲了解決新問題，我們不得不創造這個技術組件。
分佈式序列組件一般分爲序號生產端和序號消費端，消費端一般以SDK方式提供給相應微服務依賴，服務端根據序列配置的起始值和終止值、步長、前綴、後綴、中綴等信息成批生成序號放在緩存中。消費端每次來服務端獲取一小批，保存在消費端的緩存中，應用程序使用的時候實際上是從內存中獲取序號。
分佈式序列的功能一般有序列號規則定義，序列號生成，生產端序列號緩存、消費端序號緩存，序列號回收，序列號監控，序列號管理，還有按日生成序號。有的序列產品甚至支持自選號、吉祥號。在序號生成場景中，有的序號只要求全局唯一，並不要求遞增，這時候可以直接採用sdk生成雪花算法或UUID。其中雪花算法的使用節點數大於1000時，其workid則需要進行統一分配，才能爲隨機數保留足夠的位數，降低序號重複的概率。
在個別對高可用要求較高的序列產品中，還提供按單元生成序號的能力，從而實現了序列的分佈式生成能力。不過，這種能力需要修改老系統的序號規則，在序號中加入單元號。在要求‘對外無感’的項目建設中不能採用這種序列生成能力。
爲了提升效率，在我們的產品中服務端採用雙隊列緩存，消費端採用多隊列緩存，這樣的設計能讓序列獲取耗時降到零點幾毫秒，比Oracle數據庫獲取序列快十多倍，吞吐量也遠遠大於Oracle數據庫的序列。
熱點資源引擎
互聯網大商戶的對公賬號記賬已經成爲了金融IT界的難題。例如拼多多等互聯網商戶的開展的搶購活動，以及各種理財的線上搶購活動，這類活動使賬戶餘額和限額變成熱點資源。以前銀行內部賬戶可以透支，通常採用抓大放小的方式控制餘額，然而互聯網商戶賬號既有爆炸式流量又需要防透支。形成業內難以解決的熱點賬戶難題和熱點限額難題，熱點資源計算引擎主要用於解決這類問題。
某國內互聯網巨頭曾經打造過一款“高速記賬引擎”，熱點記賬性能號稱到達2萬筆/秒，但其做了綁定硬件優化，對硬件有要求，通用性不好。技術也極其底層，據說到達彙編層，可維護性也極差。最主要的是由於產品售賣不好，績效不好，研發團隊已經解散了，內部的售前人員都不敢售賣該產品。其實這是一個不錯的產品，能徹底解決熱點資源這個行業難題，但只注重短期盈利的互聯網公司沒有給這個產品太多時間，實在可惜。
目前熱點資源的解決方案有三類，異步處理、散列處理，以及採用高速引擎。
異步處理和散列處理都是利用主流數據庫實現，具有較高的可靠性，通用性和可維護性也比較高。異步處理模式的熱點記賬性能可以達到2000多筆每秒，散列處理的熱點記賬性能可以達到1萬多筆每秒，它已經完全可以滿足大型銀行的熱點記賬效率要求。
異步處理方案是採用異步記錄熱點數據的策略，將熱點資源競態條件的判斷和熱點資源數值的更新兩個步驟進行分離，先記錄熱點交易值，並做透支或超限判定，然後異步做彙總更新熱點資源值。這樣做可以實現熱點交易全程無鎖，從而提高併發能力。
異步處理的熱點資源方案可以與TCC或SAGA兩種記賬方式進行整合。按照TCC的流程對熱點資源的操作進行拆分，把對熱點資源競爭態的判斷操作與TCC的Try進行整合，把對熱點資源交易數據確認的動作放在CONFIRM(確認階段)，把對交易數據狀態回滾狀態的動作放在CANCLE(取消階段)，最後由異步任務對交易確認後的記錄進行彙總更新到熱點資源值中去；熱點資源與SAGA記賬的整合也是類似步驟，但執行SAGA的DO接接口的時候可以省去資源確認步驟，執行UNDO節點的時候反向登記一筆交易記錄。
散列的處理方式就是把一個熱點資源拆分成多個熱點，通過橫向拆分來擴展併發度。具體來說，如果把一個熱點值爲1000的資源拆分成10個，每個平均分到100，進行熱點值扣減計算時，隨機取一個子熱點來進行扣減，如果不夠則再取一個進行計算，直到足夠爲止，取完所有子熱點值還是不夠則交易返回失敗。
散列的熱點處理方式在絕大部分情況下都能在一個子熱點值中扣減結束返回，所以具有較高的熱點記賬性能。只有在大額扣減或熱點值快扣完時出現多個子熱點值同時扣減的情況，這種情況實際上是要整體加鎖串行的。爲了讓各子熱點值相對平均，除了進行隨機扣減，還要有定時機制把熱點值重新分配到各子熱點值中。
熱點資源引擎通過分析傳統的熱點處理模式，通過剝離傳統的熱點記賬的業務邏輯，抽象出一個通用的熱點資源技術組件，用於解決熱點資源計算這個行業級難題。熱點資源引擎分爲分同步處理、異步處理、熱點資源監控、並行處理框架四個模塊。同步處理包含增減的熱點值、熱點資源值查詢、維護熱點值狀態、清除熱點記錄等接口；異步處理包含異步彙總餘額、異步更新交易後餘額、異步彙總限額等功能；熱點資源監控包括熱點事件識別、熱點資源設置、熱點資源取消、熱點事件掃描等；並行處理框架是針對熱點資源需要極高的異步彙總效率，而打造的一個基於令牌桶機制的並行處理框架，該框架除了能高效的調度異步處理任務，在高可用方面也做了很多考量。
熱點資源引擎跟具體的記賬或記限額的應用是以SDK方式集成的，耦合度比較高，在實施過程中有些人可能直接把它作爲應用的一部分，然後逐漸的再把這個業務問題納入進來考慮，這樣會又回到傳統處理熱點問題的方案。最後既難以效率問題，也失去了通用性，這需要我們在實施過程中注意。
數據聚合
我在南方某股份制銀行做核心系統技術平臺時，最初行方計劃採購的數據庫沒有數據聚合能力。由於大數據部門也很難在秒級時效上做數據聚合，我們不得不創造一個數據聚合產品。項目實施做過程中，行方更換了數據庫，這個數據庫有一個多源同步的配套產品，但該產品已經不演進了。在互聯網大廠中，不演進的產品一般不妙，不是產品團隊解散了就是已經轉向其他方向，有責任心售前和銷售人員都會避開這種產品售賣。
數據聚合在大數據技術難以保障數據時效性，數據庫又沒有可靠的數據庫聚合工具的背景下應運而生。
數據聚合有數據捕獲、數據同步、同步模板配置、數據分庫分表、同步任務管理等功能。數據捕獲是通過數據捕獲SDK攔截應用系統的DAO層，對數據的增刪改操作進行進行攔截，觸發異步的方式查詢操作結果數據同步到數據聚合服務端。數據同步是在數據同步服務端根據數據同步模板對數據進行解析，並且落庫聚合庫。在數據存入聚合庫的時候可以按照配置策略對數據進行分庫分表，以支持海量數據的聚合，並且能高效的更新不同維度進行查詢。
在性能方面，由於數據聚合是採用攔截DAO的方式異步觸發同步，其幾乎不影響原交易性能。而且它可以按交易、按表、按操作動作去進行同步，比解析Binlog方式同步靈活性強很多，時效性也較爲可控。在實際測試中，幾千TPS的交易數據同步，可以輕鬆實現秒級時效性。
單元化路由
我是在2018年參與民生科技分佈式核心研發的時候接觸到的單元化路由組件，後來民生科技平臺研發的原班人馬把這個產品‘帶入’了郵儲銀行新核心系統。最初單元化路由的巧妙構思和設計給我恍然大悟、眼前一亮的感覺，我心中對設計者的敬佩油然而生。直到我到阿里後，才發現單元化路由的雛形是在支付寶單元化改造過程中，爲了解決單元定位問題自然而然創造出來的。這又一次證明了技術的形成是問題解決過程中自然產生的。
支付寶的單元化路由只是雛形，真正的單元化路由是在幾個大型銀行核心項目中才真正變成一個技術組件的。對於技術的標準化、產品化、工程化，銀行IT部門在這方面的能力應是首屈一指，特別是銀行核心系統的技術團隊，他們對技術方案、代碼質量、測試質量的要求是最高的。
目前主流的拆分單元是按客戶拆分的，當上送客戶號時直接採用客戶號取hash，後取絕對值，再對單元總數取模獲取一個數字，這個數字則可以對應着單元號。在最初的支付寶中方案中，交易都是上送客戶號的，所以它的單元路由相對簡單。在銀行的交易中，有些交易並沒有上送客戶號。單元路由是在交易沒有上送客戶號的情況下，根據賬號、證件類型和證件號碼、手機號等信息找到客戶號，再根據客戶算出分片號，以確定該筆交易路由到哪個單元。這需要建立客戶號與賬戶、證件號、手機號之間的關係，在國產數據庫下保存這個對應關係的表本身又需要進行分庫分表。這樣就逐漸增加的單元路由的複雜度，複雜度增加後自然就需要一個獨立的技術組件來進行封裝，這也是單元化路由在銀行核心項目中被完整創造出來的原因之一。
單元化路由的功能有映射管理、路由管理、切換過度支持、訪問權限控制、參數管理、統一數據訪問功能、客戶鎖、賬戶鎖、流水日誌功能、運維支持功能等。其分爲SDK和服務端兩大部分，SDK給到使用單元路由能力的應用集成，一般是網關、服務編排等組件在外調的時候會使用到單元路由。服務端的主要功能是同步和管理客戶號與其他要素對應關係，並且提供客戶/賬戶鎖功能。
如果交易上送客戶號，單元化路由只需要在SDK集成一個路由算法即可解決路由定位問題，沒有客戶號則需要去服務端查詢。但是，目前所有的單元化路由都做成了無論是否上送客戶號都需要訪問單元化路由，原因是把鎖的功能和遷移過度的功能也加入到單元化路由中。在銀行核心項目中，一次單元路由耗時可以控制在5ms一下，可以一次性把交易中涉及到的多方客戶號的單元路由信息查詢回來也能提高單元路由效率。
聯機引擎
“聯機引擎”這個詞是IBM在郵儲銀行分佈式核心項目中創造的，顧名思義它就是驅動聯機交易的運行的引擎。最初的核心功能是交易流程控制、分佈式事務控制、防重冪等、流水處理等。這兩年聯機引擎逐漸跟服務編排結合了起來，變成了可視化服務編排的交易執行引擎。再加之“業技一體化”理念的落地實施，聯機引擎逐漸變成一個集成交易運行所需各種技術組件的平臺，運行業務建模流程的平臺。
但是，目前並沒有公司把它當做一個平臺來規劃和設計，甚至有的公司把它當做流程引擎的擴展，把分佈式事務、分佈式鎖等複雜組件簡單的往上集成，使整個聯機引擎複雜極高，且沒有清晰的設計和架構。在南方某股份制銀行核心項目中，80%以上的問題產生於聯機引擎。聯機引擎設計之初並不是“複雜的組件”，而是封裝交易處理流程中的公共處理的組件，主要目的是提供標準的公共邏輯處理層，讓具體的業務開發人員不用重複寫每隻交易的公共邏輯，降低業務開發難度，提升項目質量。
目前完整的聯機引擎功能一般有：報文解析與映射，流水管理，公共檢查，防重冪等，服務控制，服務前後處理嵌入，交易上下文管理、交易級緩存、優雅停機、SPI擴展機制、日誌切面、本地事務管理、異常處理和封裝、超時配置和處理、錯誤碼管理、通用工具封裝。以及集成分佈式事務、樂觀鎖、服務治理、運維監控等組件。
聯機引擎對性能要求是極爲苛刻的，在對其性能調優的時候，甚至要把能獲得零點幾毫秒的耗時減少的優化點都進行了優化。在通信方面，大部分銀行在聯機引擎中基本上都採用效率較高的RPC通信。聯機引擎中分佈式事務的管理開銷特別高，主要是其需要開啓大量的獨立事務，分佈式數據庫每次提交事務需要2-6ms，導致聯機引擎耗時的三分之二都在事務提交上。
未來在聯機引擎事務控制設計中可能需要更加註重其架構，只有搭好足夠大的“架子”，才能在其上優雅的集成各種組件。另外，需要重新評估獨立事務帶來的收益和消耗，在交易設計中也應該儘量減少獨立事務提交。分佈式式事務提交效率低的問題將是分佈式數據庫最大的特點，只有客觀評估當下問題，打破固化思維，才能找到有效的解決方案，從而創造出新的方案或產品。
批量調度引擎
2018年我們在民生科技做分佈式核心研發，那時沒人知道在分佈式核心中日終批量如何運行。於是我把銀行核心日終批量的70多個作業全部梳理和分析了一遍，最終我們論證通過了一種分佈式核心系統跑批的方式：先收集待處理數據集，然後把待處理數據集逐條封裝成請求報文，通過聯機請求觸發聯機交易去處理日終批量邏輯，也就是現在大家說的”批轉聯”。批轉聯中的收集待處理數據集對應着集中式系統日終作業中的大循環的循環數據集，其循環內的邏輯則需要封裝爲聯機交易邏輯。
批量引擎與集中式的批量平臺相比較，除了批轉聯的整體思路改變，其中的流程控制還是跟集中式的控制邏輯一樣。在任務分發和管理方面也需要做相應的改變，任務分發需要支持按單元分發，任務狀態管理需要根據批轉聯任務執行情況來處理任務狀態。批量引擎在分佈式單元化架構中對其高可用方面也提出了新的要求。任務拆分均勻程度和吞吐量也有了更高的要求。一個新問題的解決，人們總是傾向於原有方案中做修改，以期解決新問題。在銀行核心系統做分佈式改造的初期就是如此往下推進批處理問題解決的。
目前市面上的批量引擎主要基於spring batch或xxl-job二開而成。其功能主要有作業定義、作業向執行機分發、單元化的作業分發、企業級系統間的作業分發；還有持作業狀態管理，由下層批量任務控制器反饋作業執行狀態並進行持久化存儲供狀態查詢，以及按單元查詢和統計。在流程控制方面，聯機引擎有作業流程控制，包括基於作業依賴和時間依賴以及事件觸發等多種作業調度編排方式；在流程控制中有分支流程、串行流程、併發流程、循環流程等，批量作業的操作有中斷、恢復、跳過等。批量引擎對批量任務的數據段進行分片，分片策略通常有分段、一致性哈希、取模、按單元等方式。
批量調度引擎的任務執行實際上是的任務是在執行器中處理。要實現高可用和故障自動恢復，對執行器的管理和任務分發有很多細節性的要求。例如任務分發時記錄和維護任務執行狀態和執行器節點信息；還有執行器與批量調度服務端有註冊發現機制；以及需要爲運維管控平臺提供相應的管控接口，比如調控批量併發數、發出監控告警信息等，避免系統高壓力運行時出現批量爭取聯機資源，導致聯機交易運行失敗。
基於spring batch開發的批量調度引擎，一般採用開源軟件比較簡單和輕量級的特點，不會記錄業務處理詳細記錄，只記錄任務處理的chunk數據，而且它進行多次拆分，任務能較均爲的分散到執行器中。這類調度引擎效率通常比較高，缺點就是任務記錄較爲簡單，任務拆分邏輯比較抽象沒有業務含義，很難適應大型業務系統建設中進行大規模開發。在大型系統的開發中，除了要求效率，而且還要求有詳細的操作過程記錄和批處理情況記錄，相應的記錄勢必會造成性能下降，這是批量調度引擎設計時需要權衡。
文件引擎
某國內大廠採用spring batch進行稍微改造後號稱爲批量平臺，再加上一個文件解析job後有又成了文件引擎。當時我在該廠工作，給他們產品部門詳細講解過文件引擎功能，今年我在某股份制銀行看到該大廠給他們做的文件引擎還只是一個文件解析的job。
其實，文件引擎是一個具有很深歷史積澱的技術組件，絕對不是拿着開源組件稍微改造就可以的。在銀行中，從最傳統的文件批處理流程到最新的流程，只是接入渠道增加了，其傳統的處理流程幾乎沒有改變。文件引擎有很多技術處理細節是老銀行IT人員的習慣或者經驗，就如一位銀行IT前輩所說：“按照以往的方式處理不一定是最好的，但我能確定是沒問題的”。
在銀行中，文件批量類交易通常都是代發代扣，最傳統的代發通常是企業會計人員使用銀行給的加密軟件，對工資發放的excle做加密，然後用光盤或U盤存儲後給到櫃員，櫃員用櫃面系統進行上傳到中間業務業務系統做校驗和登記，然後轉換爲核心的文件格式發送到核心系統記賬。現在也有大量的文件批量來自網銀代發、銀企直連等渠道。
文件引擎的處理步驟通常是：文件上傳、文件通知、文件解析落庫、文件內容校驗（文件頭處理）、文件內容執行（文件體處理）、文件處理結果核驗（文件處理）、回執文件等。在文件引擎中必須有文件批類型管理和文件批次管理，文件批類型管理用於創建、修改文件批對應的文件模板、上送/返回文件路徑、掛載文件頭體尾處理邏輯、設置文件批的優先級、控制文件批量訪問渠道等等；文件批次管理則是管理具體的次運行的文件批任務，包括批次的狀態、批次的流程控制、批次信息的查詢等。
在性能方面，文件拆分、落庫，以及任務的拆分和分發，都需要併發進行，併發度的動態控制是最大的難點。在批轉聯情況下，併發度還需要考慮對聯機交易資源的搶佔。
統一網關
在企業級架構中，各系統集成一直都是企架的難點和重點。以往主要採用ESB串聯大型企業中的各系統。但隨着服務註冊發現、聲明式API等技術的普及，企業的微服務數量爆炸式增長，ESB的集成能力顯得力不從心。
聯機網關是最常見的一種網關，與聯機交易一樣，還有消息交易和文件交易，消息網關和文件網關也越來越被大家重視起來。另外，系統外調其實也需要進行協議轉換和報文轉換。因爲這些網關有很多共通之處，例如協議轉換、報文轉換、鑑權、驗籤等都是它們的共同能力，我們在此把聯機網關、消息網關、文件網關、外呼網關並稱爲統一網關。
聯機網關一般有轉換層，包括接口協議轉換、接口報文映射、業務相應碼轉換、簡單邏輯轉換；接口管理，包括接口定義、接口維護、接口刪除、接口查詢，以及企業級接口同步；服務治理，包括限流、熔斷、降級，開源的網關是通常是服務級的，通常需要做到一定改造才能實現接口級服務治理。造成這個問題的原因是互聯網架構師認爲的服務通常是一個接口，而大型金融系統的架構認爲的服務通常是一個微服務；服務控制，包括訪問鑑權、黑白名單；以及參數映射、服務分組管理、路由轉發、灰度。
網關雖然有很多功能，其中重點還是協議轉換和報文轉換，支持的協議類型是判定網關能力的重要考量點。協議轉換和報文轉換的效率也是網關最重要的性能指標，一個高性能的網關，做一個50參數的協議和報文轉換耗時不應超過5ms，爲了提高性能，有些網關還採用了只解析報文頭的方式。甚至有些網關在RPC協議中，通過查找字節碼方式截取報文頭進行解析，以極高的效率做報文轉換、協議轉換，以及流量控制。有TCP協議的握手機制非常消耗性能，有的網關直接採用長連接的方式。總之，網關是一個系統的門戶，對穩定性和高效性要求極高，採用多少性能優化措施都不爲過。
消息網關與聯機網關很類似，除了報文來源是消息體，其他的都可以複用聯機網關能力。不過，需要處理好消息消費失敗的場景，消費失敗分爲業務系統消費失敗和網關組件消費失敗，兩種情況需要採用不同方式進行處理。外呼網關其實就是聯機網關的反方向處理流程，但其需要一個SDK把系統內的請求轉發到外呼網關中，外呼網關也應該跟聯機網關和消息網關分開部署，以便靈活控制系統流入流量和流出流量。文件網關與聯機網關有一定區別，首先是其不適合跟聯機網關和消息網關部署在一起，通常會跟文件引擎或文件批量部署在一起。
微服務和系統的數量越來越多，微服務和系統間的集成一定越來越複雜，集成技術從ESB逐漸轉爲網關，未來一定還需要更適合未來企業架構的“網關”，Mesh也許是一個方向，但開源的demo級Mesh肯定是不能滿足金融級場景的，金融級的Mesh可能還是需要國內軟件服務商在項目中根據實際需求進行創造。
莫把開頭當結尾
過去10年互聯網的蓬勃發展，爲分佈式、單元化、雲原生技術發展“開了個頭”。隨着銀行等金融機構和國內頭部IT服務企業在這些技術上逐漸增加投入，特別是銀行核心系統應用了這些技術，這些技術的運用將更加標準化、工程化、產品化。在運用單元化、雲原生技術過程中，金融機構和頭部IT服務企業也沉澱了大量aPaaS中間件，例如：單元化路由、參數緩存同步、熱點資源引擎、數據聚合等。
國內大型金額機構和頭部IT服務商在信創和雲原生轉型過程中，沉澱的這些aPaaS中間件如果開源出來，國內將形成新一代中間件，這代中間件將支持着我國大型IT系統在未來10年高效平穩運行。至於國外開源的註冊中心、配置中心、MQ消息、Redis緩存等產品，沒必要照抄一遍。因爲這些產品在單元化、雲原生架構下，以及大型系統的應用場景中需要進行深度的改造才能使用，不如根據新架構、新技術及信創要求研發新的產品，去解決我們遇到的新問題，只有這樣我們才能擺脫“技術跟屁蟲”的窘境。
不能提高應用開發和運行效率的技術平臺就不是好的技術平臺。aPaaS提供一些使應用開發更加便捷、應用運行更加標準高效的能力，其必然會成爲雲原生技術平臺最有生命力的一層。
07
SaaS層
大型系統在國內SaaS化情況
幾年前我在阿里銀行核心的雲先鋒團隊中工作，當時我們調研過國內銀行核心SaaS化的情況。從理論上分析，軟件SaaS化後只需增加運行的硬件資源就能支撐更多客戶運行，也就是其擴大售賣規模的邊際成本很低。這是互聯網大廠最喜歡的商業模式，SaaS化幾乎成爲所有商業軟件都想走的一條路。一個產品是否優秀，能否無邊際成本的大規模售賣是最重要的衡量指標。
然而，在國內的監管下銀行核心系統SaaS化幾乎不可能。不過也有采用“多租戶”來實現一個系統多個客戶使用的，本質上多租戶也是SaaS化的一種形式。國內主要有某數金和某城商聯盟在提供銀行核心的“多租戶”服務，其中某數金並沒有特別好的盈利，某城商聯盟的系統維護和升級也異常艱難。金融系統的SaaS化似乎是一條艱難的路，然而餐飲管理、直播、電商、協同辦公等行業卻蓬勃發展。
金額系統SaaS化難度高的原因，除了監管嚴格和數據安全問題，還有定製化需求多、系統複雜性高、安全性要求高、穩定性要求高等。我們先拋開政策性問題，僅從技術上分析，近幾年服務編排逐漸應用在大型系統建設中，複雜模塊也逐漸進行了引擎化或工廠化，軟件的分層封裝也做得越來越好，這些技術發展趨勢可以使複雜的大型系統SaaS化成爲可能。
下面我們就從服務編排、引擎化、工廠化、分層管理等方面來分析如何做SaaS化的應用。
服務編排，讓SaaS具備輕鬆定製業務流程的能力。
服務編排，簡單來講就是把內部和外部的各種服務接口編排起來，提供一個完整的服務，或者提供一個一站式服務。它讓系統根據可視化流程的運行起來，業務人員能根據業務流程需要調整流程節點，也可以改變節點執行條件。專業的服務編排是要圖菱完備的，還要與分佈式事務融合，在對遠程服務調用過程中自動管理分佈式事務。這樣業務人員可以自行修改系統運行流程，真正實現IT系統的敏捷響應業務需求。
引擎化，讓SaaS具備強大的參數配置和調節能力。
大型IT系統有很多複雜的模塊，其邏輯複雜性高，而且特別集中，這類模塊通常可以抽象成一個引擎。例如限額引擎、規則引擎、熱點資源引擎等。限額引擎專門用於控制各種額度以及數值的最大值、最小值。規則引擎則用於控制系統中各種狀態變化和流轉的，熱點資源引擎則是上文在aPaaS中闡述的一個技術組件。在銀行核心這種標準的系統中，這類引擎很常見。抽象成引擎後其參數可以由專門的引擎管控端進行配置，限額引擎和規則引擎基本上可以把系統中各種額度限制和狀態流轉都配置出來，通過改變配置就能改變各種數值的限制和狀態的變更，這樣的系統運行起來就非常靈活，實現真正的敏捷。
工廠化，通過產品工廠快速創建產品，滿足市場需求。
2013年的時候我們本土化改造Oracle的一款銀行核心系統Flexcuble。這是國內引入的首款Java銀行核心，這款產品異常複雜，本土化改造量很大，實施成本非常高，但還是拿下了好幾個客戶，其中有一個股份制銀行和兩個農信。Flexcuble的最大亮點就是產品工廠做得特別好，當時國內核心普片還在做參數中心的時候，它已經把銀行核心系統的參數進行整理歸類，形成了產品工廠。產品工廠能讓產品研發人員快速的配置出市場所需的產品，這纔是真正的敏捷，這種敏捷是敏捷開發無法企及的，對於對穩定性、安全性要求較高的系統應該追求這種敏捷，而不是敏捷開發。
Flexcuble等國外產品的引進，給國內銀行核心系統廠商做了些參考，使後來國內新研發的java核心系統從面向參數設計演變成了面向產品設計。以往面向參數設計的系統也能做到很高的靈活度，但沒有對參數按業務屬性進行整理，甚至有些核心系統的參數直接是鍵值對形式的，取名也比較偏技術。產品人員根本看不懂，也配置不明白。所以真正的產品工廠是要採用業務語言描述，產品人員能看懂、能配置。這一波銀行核心建設主要是信創推動，業務人員很少參與，個別項目業務人員甚至明確不參與。這種情況下新建的核心繫統，是否有產品工廠似乎也沒人關心。
加入適配層（防腐層），在多版本演進時增強核心邏輯的穩定性。
適配層包括對外接口的適配層，以及數據模型持久化的適配層。也就是在對外接口層到業務邏輯層之間加入一層適配層，讓定製化版本在適配中進行改動。另外，核心業務邏輯要與數據模型解耦，避免不同版本對存儲的信息有不同的要求，導致數據模型改變，從而改動核心業務邏輯。這要求業務邏輯不能直接操作數據模型，而是操作業務邏輯所需的實體模型，在業務邏輯層和持久化層中間加適配層，做定製化版本的持久化層適配，以保護核心業務邏輯穩定。
封裝環境層，降低應用開發人員對運行環境的認知要求，使其專注於應用開發。
aws的雲平臺中有一款很優秀的產品叫Beanstalk，它對環境的封裝就非常好，可謂是真正的大師級產品。真正的技術大師不會把技術菜單和按鈕擺滿屏幕，而是把用戶直接意圖所需的操作放在最顯著的位置，用戶在沒有閱讀操作手冊的情況下，憑藉直接意圖就知道點哪個按鈕。順着用戶意圖逐漸要求客戶去補充相關配置和信息，並且給出很多的默認配置，儘量降低用戶的知識要求。反觀國內大廠的同類產品，把所有菜單都展示出來，菜單欄上幾十個菜單，必須認真研讀其操作手冊，理解其中複雜的關係後才能勉強會用，要想熟練掌握必須考一個證書纔行。有的產品有導航式引導，但它是引導客戶進行基礎參數配置的，而不是用戶的直接意圖，用戶一開始就很疑惑爲什麼要配置那些繁瑣的配置，而且用戶必須要看操作手冊才知道如何配置。
封裝環境層則是將環境作爲一個整體，應用是運行在其上，應用開發人員不用關心環境內部的機制。環境中有全套中間件、數據庫、負載均衡，以及配套的網絡配置和運行的資源，乃至配套的運維監控。目前的雲環境太複雜的，應用開發人員完全理解雲環境中的各種概念很困難，所以對環境整體的封裝是必然的選擇，Beanstalk給我們做了很好的示範。
數據安全問題是SaaS化的攔路虎。
最近這些年我經常接到各種莫名其妙的促銷電話，有時甚至接到國外的詐騙電話。讓人恐懼的是騙子能準確知道我的身份證、住址、職業、喜好，以及剛纔網上購物情況，我相信很多人都深受其苦，但無能爲力。這說明我們對個人信息數據的保護並沒有明顯的成效，唯有讓大家感覺到數據安全的確有保障，SaaS化纔有可能快速發展。
數據的權利大致可分爲所有權、管理權、使用權。數據的所有權理應屬於相應的個人或機構，管理權則屬於管理相關數據的機構或個人，使用權屬於被數據所有人授權使用的機構或個人。這三種權利需要嚴格區分和保障，數據所有者有權對自身數據的使用授權進行管理及享受數據使用的收益，數據不應被數據管理者擅自使用，數據更不能被數據管理者默認佔有，數據管理者只要數據除存儲加工處理權利不應有使用權利。只要有對這些權利進行嚴格規範和管理，人們才能在這個數字化的世界中安全生存。
上述的數據權限分離和保障，當下是有技術手段可以實現。採用數據加密手段，限制數據管理者的權限是關鍵。數據管理者是最容易侵權的一方，其利用管理職能，很輕鬆就能利用海量數據獲取鉅額利用，只有對數據進行嚴格加密，密碼掌握在數據所有者手中，才能避免數據被數據管理者濫用。
在公共雲環境中數據加密更爲重要，公共雲其實就是把客戶的數據放到互聯網絡環境中，數據安全問題尤其突出。一方面是雲環境的管理者可以輕易獲取數據，另一方面是互聯網環境本身容易受到滲透和攻擊。把企業的IT系統運行在公共雲上，相當於把企業的生命託付在雲上，只有讓數據所有者採用自己可信的加密方式對數據進行了加密，數據所有者纔會放心的把數據放到公共雲上。這樣SaaS化纔有可能高速發展。
大型IT系統SaaS化，耐心是關鍵。
國內某互聯網巨頭在2018年信誓旦旦進軍銀行核心系統，直到2022年5月落地實施了一家銀行互聯網核心。銀行賬務核心的關鍵微服務也正在一家農信和一家城商行落地過程中。然而，該互聯網巨頭卻無視客戶訴求、不顧項目影響，毅然停止了其銀行賬務核心關鍵微服務的版本演進，拆解相關團隊。
一家國內做銀行核心的民營企業，全年營收沒超過3億。有一個40-60人的銀行核心研發團隊，花了3年時間研發了Java版銀行核心，又花了3年時間在一家客戶關係非常好的城商行進行了落地實施。前後花了6年時間，纔算獲得了一個銀行核心系統1.0版。由此可見要把類似於銀行核心這樣的大型系統進行SaaS化，其時間週期將是非常長的，公司或投資者的耐心是成敗的關鍵。
在新興領域需要的是快速試錯、及時止損；在大型核心系統領域則需要高瞻遠矚的技術人才和耐心的資本。國內互聯網大廠用新興領域的模式進軍核心領域，必定是水土不服的。
SaaS服務一定要部署在公共雲上嗎？
SaaS化大家通常理解是把系統部署到公共雲中。其實不然，大型企業可以把應用部署到私有云中，再通過前置系統向外部合作伙伴或客戶提供服務，這是大型IT系統SaaS化更加合理的部署方式。因爲數據安全、網絡安全、公共雲可信度等問題尚未解決，大型核心系統很難在公共雲上進行SaaS化部署。而且很多大型企業已經自建雲平臺，也沒必要把關鍵系統放到公共雲上。
生態雲或行業雲也不一定要把所有系統都上公共雲，關鍵系統部署在私有云中通過前置系統把幾個私有云中的系統串連接起來，同樣也能形成更加安全可靠的生態雲或行業雲。所以，SaaS服務並不是特指公共雲上的服務，未來更多必將是私有云中的SaaS服務。
08
採用什麼理論能確保你的系統10年後依然好用？
一個基礎的理論
目前很多大型系統建設都是“聞風而動”，一陣技術風潮吹過就重構一遍系統，使用週期長達10年以上的IT系統肯定是跟不上技術風潮的，這種情況亟需更基礎的理論指導，從更加長遠角度指導大型IT系統建設。本文姑且拋轉引玉，提出一個可能適用的基礎理論概述。
近20年IT技術的發展是伴隨互聯網崛起而發展的，其從來沒有什麼理論指導，也不需要理論指導，能掙錢的互聯網公司就活下來了，反正則已經消失在技術迭代的浪潮中。“物競天擇，適者生存”正是《進化論》的基本原理。
假設存在更廣義的進化論：“事物總是以自身存在爲目的，進行對外作用和對內調整”。這似乎是一條必然正確的假設，因爲如果某個事物不以自身存在爲目的而對外作用和對內調整，該事物就已經不存在，所以現存的事物應該都遵循這個假設。動物的進化是如此、公司發展亦是如此，那麼IT系統的演進是否也是如此呢？
假敏捷與真敏捷
自從互聯網的敏捷開發之風吹起後，很多大型企業也掀起了敏捷之風，熟不知對於大型複雜系統來說那是假敏捷。對於大型IT系統，快速的迭代需要大量的人力，而且難以保障系統的穩定性。只有在全新的領域，業務模式還在探索階段的領域，才適合快速迭代、測試、發版。對於業務規則幾十年都沒怎麼變化的金融系統，爲何需要頻繁迭代更新？原因只是系統設計之初並沒有考慮如何敏捷的支持業務變更。
那麼大型IT系統如何做到真敏捷？如何具有更強的適應性？以確保在未來的競爭中適合並且生存下來。我想其設計理念應該是離不開上面談到的基礎理論的。根據上述理論：“事物總是以自身存在爲目的，進行對外作用和對內調整”，IT系統滿足這個理論則可經久不衰，滿足這個理論這需要三個模塊或部分：內部調整部分、輸出部分、接入部分。理論上，一個IT系統只要這三個模塊足夠強大，那麼它就有對未來環境的強大適應能力，並且能真正敏捷的支持業務發展。
在當前技術條件下，做好內部調整部分可以是做好系統的參數化、引擎化、可視化流程編排、產品工廠等方面；輸出部分則可以有對外供數、數據聚合、數據清洗和分析等，也可以有系統監控、自檢、外呼等，還可以有系統運行效能、運行成本等；輸入部分目前大家比較注重聯機網關、消息網關、Mesh等，其實還應有IT系統對業務變遷的感知，比如“業技一體化”之類的技術和理念，它彌合了業務與IT實現間的鴻溝，讓IT隨業務而動，此乃真敏捷。
完美的系統
人其實本身就是一個非常完美的系統，其大腦類似於一個強大的控制引擎。人的身體構造本身幾萬年來都沒太多變化，變化比較大的是其大腦裏的思想。通過快速改變大腦的思想來適應環境，使人這個“超級系統”存在了幾萬年。對應這人的一些特徵，系統設計時應該爲其設計各種參數引擎、流程編排器、產品工廠等，以提升系統對內的調整能力；其次還需要有對外的感知部分，比如同業的同類系統業務開展情況，通過一些公開的數據進行分析，以調整快速調整自身產品參數，確保產品比同業產品更受市場歡迎；再則需要對外輸出模塊，以便和外部系統協同，例如向監控系統輸出系統運行狀態，以及向數據下游系統提供豐富的數據。只有對內可調整維度足夠多、調整幅度足夠大，對外作用精準有效的系統才能在長時間內更好的適應環境。未來，採用深度神經網絡作爲控制引擎的系統也許更能適應環境。
老子說：“道可道，非常道，名可名，非常名”，人的認知與總結能力是有限的，人不能創造完美的系統，只不斷推進系統的演進。每次無法通過修改參數或流程來滿足業務需求，都應該作爲系統設計者的一次反思，採用面向對象的方法進行分析、總結經驗，讓下個升級版本更加適應需求。當大部分需求都無法通過修改參數或流程來滿足時，系統則應被淘汰在業務演進的浪潮中。
佛說：“諸法空相”，現實業務本身才是完美的，當我們在IT系統的邏輯中迷茫時，回到現實業務本身，乃可重拾方向。（作者微信：wcsmomo）
說明：本文僅代表作者個人觀點