傳統金融業IT真相揭秘：“動物園”“牛群”玩法大不同
在互聯網金融成為IT領域炙手可熱新業態的今天，傳統金融行業的IT團隊似乎還蒙著一層神秘的面紗。他們在做什么?思考什么?對于互聯網金融又有什么樣的感想?它們與互聯網行業有哪些區別和交融?未來的發展方向會是如何?本文由長期在傳統金融行業為用戶提供開源專家服務的國內領先開源解決方案服務商——上海富麥信息科技有限公司開源解決方案總監余軍為大家詳細分析了傳統金融IT行業的IT技術情況，并分享了團隊如何借助Golang之上的優秀開源技術，嘗試進入云計算領域的動態資源管理和容器領域，去應對金融行業實際面臨的業務挑戰和激烈的行業變化。
1.基礎架構真相：縱向復雜的集中式“煙囪”結構
對實際項目中復雜的拓撲圖進行抽象后，金融業IT基礎架構如圖1所示。
圖1 金融業IT基礎架構
從圖1可以明顯地看出，整個系統是標準的IOE結構。事實上，在過去的二三十年間，全國***勢資源的投放點一直都是傳統的金融IT領域而非互聯網領域，因此金融業的IT系統一點都不落后，并且無論是團隊技術還是具體構成，都可以說是非常先進的，只是外界很少有機會去接觸和了解它的整個架構。在之前阿里巴巴去IOE的浪潮中，有些人存在著一些誤解，覺得金融業IOE的系統比較低端，但真實情況恰恰相反。
那么，為什么與互聯網電商行業相比，金融業的服務器部署規模會小一些呢?其原因在于，架構是根據業務生長出來的，所以傳統金融業與互聯網、電商行業在架構上的差別取決于業務形態的不同。在互聯網領域，如一些大的平臺化的電商，在橫向上的每一層(如Web接入層、數據庫層)都會布置很多臺機器，但這些機器在同一層上做的都是類似業務，所以從縱向上的業務種類來說其數量卻是有限的。而作為傳統行業，金融業IT業務的種類和復雜度要遠超過大家所熟知的一些電商類應用，它們在縱向上有很多犬牙交錯的復雜的業務關聯，但每個業務線都是在單獨的一套系統里的，彼此隔離，并不要求有太多的橫向傳播。所以金融業的IT架構不是做不到大規模的多機器布置，而是業務沒有這個需求。在過去的二三十年當中，由于業務不斷往下生長，國內外絕大部分的金融IT業***的形態都是像煙囪一樣垂直的結構，系統之間是上下層的關系。這樣的確是有限制的，但是它的合理性支撐了過去30年內中國的金融秩序和正常運行。舉個例子，大家在上門戶網站或電商網站時，有些會出現網頁打不開的情況，但是到銀行取錢時從來沒有遇到過銀行無法操作的事情，金融業的交易一直保持非常平穩，這就需要業務背后的系統的有效支撐。
2.IT環境真相：分而治之，嚴格管控
傳統金融業的IT環境包括三個部分：Dev/Test、Staging和Production，如圖2所示。
圖2 金融業IT環境構成
圖2中環境的設定與互聯網行業叫法類似，但物理上的表現可能會完全不同。而在傳統金融業內部，不同項目組技術團隊成員在開發流程和方法上有比較大的差異。比如Dev/Test場景，金融業內部有多樣的團隊可能為同一個項目服務，有自己的技術開發團隊，有做產品的金融專業團隊，還有外包團隊，這就導致了在流程上無法高效融合。此外，金融業對于以上環境的安全管控也會非常嚴格。在 staging 環境中，銀行會導入一些經過脫敏的真實的交易數據，有一些業務網點甚至會直接來到staging環境里做實驗性業務，或者完成完整的業務視角的UAT測試。因此它的安全性、可用性、容量等都是嚴控制的，甚至在一些大型金融行業的數據中心staging機房設置有多門崗，對進出人員進行管控。而 Production環境就不用說了，只會在管控上更加嚴格。
#p#
3.技術發展真相：互聯網做的，他們都懂
2000年，金融業開始了從RISC到IA的架構轉變，這場變化進行得如火如荼，大家都在探討是否要在系統核心外圍和邊界上面把大型的UNIX系統替換成Linux。這個過程持續了四五年的時間，UNIX To Linux在一些機構開始推行。接下來是開源架構，2004-2005年用戶開始在一些網銀系統外圍的生產環境中使用一些工具。后來分布式架構出現了，2005-2007年間金融客戶開始在前端核心的外圍和渠道業務(如銀證、銀基、銀保，水電煤支付或者代理的當他交易)中使用開源架構，甚至有一些走得比較快的金融用戶，會從國外學習。國內的金融及證券交易所跟美國的互聯網公司、電商企業一直都在進行著交流，雙方的專家也會互相深入到對方的實際工作環境中進行分享。從2008年開始，虛擬化出現了，接下來就是云計算和大數據。這時，銀行的業務受到了所謂的影響，實際上金融行業最熟悉如何包裝市場需要的金融產品。早在四五年前金融互聯網化剛剛出現苗頭時，相當一部分的金融企業向對口監管機構申請，并且做出了類似余額寶的業務，當時某些產品的投資回報率還是相當可觀的。但是后來監管機構從整個市場的運行安全角度考慮，同時政策指引層面也需要時間去了解和消化，這些業務開展提案大多數都沒有通過。
后來移動業務開始興起，基本上每個銀行都在做并且越做越好。然后是敏捷和DevOps的來臨，敏捷在很多走在前面的金融機構早已開展，但是DevOps對于金融行業來說跟進是比較困難的，這不是技術上或是人力上的原因，而是在管理上更多的考慮和限制。
接著開始了所謂的“去IOE”話題，大型金融企業也紛紛投身到了IT建設自主可控的大潮當中。所以，從金融行業的IT基礎架構建立起至今，技術和結構上的革新從來沒有停止過，而是保持了對新技術的高度關注，順時而動。到現在出現了 Docker，出現了自動化運維等一批新興技術，這些金融機構的IT團隊也在積極的研究。但是在金融行業實際的場景中，對于這些目前停留在調研階段，因為金融業的業務場景中風險控制和生產安全是首位的。
4.技術選型真相：從集中式到分布式，“動物園”的資源分配
這里需要引入一個關于架構模型的問題，即“動物園”跟“牛群”之間的關系。由于業務的特點，金融行業形成了目前這種集中式的結構，它具有和電商、互聯網領域完全不同的業務形態——業務種類繁多，但每個業務的IT結構中的每一層規模相比于代行互聯網企業的結構來說沒有那么大，不同業務之間邊界相對比較清楚。所以實際上這樣的場景是一個“動物園”場景，管理者要去精細分類管理照料這些動物。而在互聯網及電商領域，IT系統多采用分布式架構，架構的每一層都是一個“牛群”。在這樣的一個模型里，每一頭“牛”對整體來說都幾乎是同質的。同一層的 “牛群”中的“牛”，獲得資源是盡可能平均的。但是“動物園” 模式里就不一樣，由于不同“動物”對資源的消耗存在差別，會產生不同的管理模式。將“動物園”和“牛群”的具體模型對比如圖3所示。
圖3 金融業與互聯網行業的IT模型示意圖
所以在“動物園”，即傳統金融領域，解決的是在這樣一個環境里面如何實現資源的高效合理分配的問題，這是集中式“煙囪”模型向分布式結構轉換時必須要重點解決的。那么，針對資源管控的解決，結合開源精神，需要進行以下思考。
1)是否存在已知的解決方案
目前可以選擇的方案有HPC中的PBS，Conder及Platform的資源調度和服務管理技術，這是傳統分布式計算領域的;還有來自現代互聯網領域的分布式資源調度和服務管理技術，比如Hadoop YARN、Apache Mesos和Google Kubernetes等。
2)它們是否適合金融業的問題場景
然后要看看一下這些解是不是能解決我們實際面臨的問題，如果可以，就能直接做一些實施集成的工作來實現了。下面依次對這些產品進行分析。
Condor
Condor是過去十年里，傳統IT領域在大型集群調度方面做得非常好的產品。Condor系統是面向高吞吐率計算而設計的，它的主要目的就是利用網絡中工作站的空閑時間來為用戶服務。
- Condor采用集中式調度模式,且不能保障用戶服務質量。
- 最小完成時間算法MCT(Minimum Completion Time)是以任意的順序將任務映射到具有最早完成時間的主機上，它并不保證任務被指派到執行它最快的主機上，而僅關心如何最小化任務完成時間，因而可能導致任務在資源上的運行時間過長，從而潛在地增加了調度跨度。
- 以MCT算法為基礎演伸出了Min-Min算法，它是利用MCT矩陣，先分別找到能夠最短完成該任務的機器及最短完成時間，然后在所有的最短完成時間中找出最小的最短完成時間對應的任務。Min-Min算法存在著一個很大的缺點，就是算法的資源負載均衡性能(Load Balancing)不高。
- Max-Min算法與Min-Min算法相似，都是將任務指派給具有最小預測完成時間的主機，不同的是Max-Min算法從所有任務的最小完成時間中選取一個***值，然后進行相應任務。主機映射，之后重復此過程直至待調度任務集合為空。
- 輪詢調度(Round Robin Scheduling)算法就是以輪詢的方式依次將請求調度不同的服務器，即每次調度執行i = (i + 1) mod n，并選出第i臺服務器。輪叫調度算法假設所有服務器處理性能均相同，不管服務器的當前連接數和響應速度。該算法相對簡單，不適用于服務器組中處理性能不一的情況,而且當請求服務時間變化比較大時，輪詢調度算法容易導致服務器間的負載不平衡。
Mesos和YARN
- Mesos 采用了DRF(Dominant Resource Fairness)調度機制。YARN自帶FIFO、Capacity Scheduler和Fair Scheduler(借鑒了Mesos的DRF)。
- Mesos中的DRF調度算法過分的追求公平，沒有考慮到實際的應用需求。在實際生產線上，往往需要類似于Hadoop中Capacity Scheduler的調度機制，將所有資源分成若干個queue，每個queue分配一定量的資源，每個user有一定的資源使用上限。
- Mesos采用了Resource Offer機制，這種調度機制面臨著資源碎片問題，即每個節點上的資源不可能全部被分配完，剩下的一點可能不足以讓任何任務運行，這樣便產生了類似于操作系統中的內存碎片問題。
- YARN適合Long running job和數據分析類資源的調度，對于數據庫類等短運行時場景資源調度效果較差。
- YARN采用了增量資源分配機制(當應用程序申請的資源暫時無法保證時，為應用程序預留一個節點上的資源直到累計釋放的空閑資源滿足應用程序需求)，這種機制會造成浪費，但不會出現餓死現象。
- Mesos和YARN的調度器的擴展和定制在開發上都比較繁瑣。
Kubernetes
- Kubernetes僅僅是實現了一個極其簡單的調度器。鼓勵開發者編寫自己的調度器注冊進框架。
- 調度策略分為兩大類：Predicates和Priorities，其中Predicates判斷是否將pod調度到特定 minion(host)上運行，而Priorities則是在Predicates的計算基礎上，通過積分Score方式，決定調度量。
- redicates包括：PodFitsPorts、 PodFitsResources、NoDiskConflict、MatchNodeSelector和 HostName，即一個minion能夠被選中的前提是需要經歷前面提到的這5個Predicates的檢驗，而Priorities又包括：LeastRequestedPriority、ServiceSpreadingPriority和EqualPriority，分別為通過 Predicates檢驗的minion計算優先級(score)，score是一個范圍是0-10的整數，0代表***優先級，10代表***優先級。
- 調度機制還是過于平均，Predicates本質上作為一個過濾器，帶有太多資源的物理屬性。
- 調度機制非常適合公有云場景，對于私有云領域欠缺靈活性。
#p#
5.求解之路：基于場景的加權算法SWF
很可惜，以上提到的這些技術都分別有不適合傳統金融業的應用環境的地方，但開發人員也從對他們的分析中得到了一些啟發。比如，Kubernetes算法跟其他算法相比***的優勢在于關注到了服務使用資源的需求是不一樣的，但是它的調度做得非常簡單，基本上還是個平均的調度。因此，我們開發團隊進行一段時間的深入研究，設計了一套基于場景數據的加權算法(SWF，Scene Based Weighted Fairness)，即將性能和一些場景數據按照時間片采集下來，然后經過算法計算，用短期和中長期分類來對應應用在資源池內投產的不同階段，因為基礎項目建設一開始資源用得相對少，后面會逐步增多，也可能出現業務爆發，支撐平臺出現資源請求高峰。而且通過和業務場景對應的權重，實現人工干預調度里面的資源的均衡狀況。還可以通過權重比, 從利用率優先、容量優先和可用性優先進行調控。SWF具體的開發實現采用了較為獨立的模塊方式，方便將來開源后被第三方用戶使用、定制和集成。它具備以下特性：
- 適合金融行業架構和業務場景的資源調度機制，圍繞各種對資源有不同分配使用要求的應用開展調度工作;
- 針對不同生產區域(devops/test，staging，production)實現基于權重比的調度調整方式;
- 實現局部調度的個性化和全局調度的公平性 ;
- 杜絕簡單粗暴的調度，對關鍵業務應用的運行影響降低。
目前該算法正在面向金融行業應用場景，進行持續地開發演進和代碼調整。
雛形與未來：將容器技術運用到實際場景
目前，余軍的團隊在圍繞容器技術正在做一些面向金融行業場景的嚴肅而有趣的嘗試。
首先，他們構建了一套資源池管理系統，所有工作都圍繞資源池的調度來進行。在其上做了一層開放層的資源池的調度工具，包括資源調度、彈性伸縮、服務發現等，如圖4所示。
圖4 資源池及調度工具示意圖
然后，構建了調度批處理的作業調度、性能管理，此外還基于算法以及資源池的調度系統做了一個跨邏輯數據中心的方案，如圖5所示。
圖5 數據中心方案示意圖
值得一提的是，以上所有工作均采用Go語言編寫，并且100%自主研發，并逐步完整開源給社區，希望幫助到那些有同樣業務場景需要解決資源調度的開發人員和團隊。相信未來這些方案的具體實現會為云計算領域提供一個優秀的金融行業場景落地案例。
可以看出，無論是“動物園”還是“牛群”，雖然由于業務形態和監管力度的不同，二者在技術應用的具體形態上存在差異，但IT系統在本質上，都有著共同的訴求：對業務的完善支撐、穩定性、可靠性以及對資源的高效合理分配。相信通過余軍的介紹，可以為對于傳統金融IT行業感到好奇的人們打開一扇窗，讓大家一睹窗內實際的景象，并在自身系統的構建中借鑒到一些技術思想。
