傳統(tǒng)金融業(yè)IT真相揭秘：“動物園”“牛群”玩法大不同

2015-05-19 10:09:36

云計算 在互聯(lián)網(wǎng)金融成為IT領(lǐng)域炙手可熱新業(yè)態(tài)的今天，傳統(tǒng)金融行業(yè)的IT團隊似乎還蒙著一層神秘的面紗。他們在做什么?思考什么?對于互聯(lián)網(wǎng)金融又有什么樣的感想?它們與互聯(lián)網(wǎng)行業(yè)有哪些區(qū)別和交融?未來的發(fā)展方向會是如何?本文分享了傳統(tǒng)金融行業(yè)團隊如何借助Golang之上的優(yōu)秀開源技術(shù)，嘗試進入云計算領(lǐng)域的動態(tài)資源管理和容器領(lǐng)域，去應對金融行業(yè)實際面臨的業(yè)務挑戰(zhàn)和激烈的行業(yè)變化

在互聯(lián)網(wǎng)金融成為IT領(lǐng)域炙手可熱新業(yè)態(tài)的今天，傳統(tǒng)金融行業(yè)的IT團隊似乎還蒙著一層神秘的面紗。他們在做什么?思考什么?對于互聯(lián)網(wǎng)金融又有什么樣的感想?它們與互聯(lián)網(wǎng)行業(yè)有哪些區(qū)別和交融?未來的發(fā)展方向會是如何?本文由長期在傳統(tǒng)金融行業(yè)為用戶提供開源專家服務的國內(nèi)領(lǐng)先開源解決方案服務商——上海富麥信息科技有限公司開源解決方案總監(jiān)余軍為大家詳細分析了傳統(tǒng)金融IT行業(yè)的IT技術(shù)情況，并分享了團隊如何借助Golang之上的優(yōu)秀開源技術(shù)，嘗試進入云計算領(lǐng)域的動態(tài)資源管理和容器領(lǐng)域，去應對金融行業(yè)實際面臨的業(yè)務挑戰(zhàn)和激烈的行業(yè)變化。

1.基礎(chǔ)架構(gòu)真相：縱向復雜的集中式“煙囪”結(jié)構(gòu)

對實際項目中復雜的拓撲圖進行抽象后，金融業(yè)IT基礎(chǔ)架構(gòu)如圖1所示。

圖1 金融業(yè)IT基礎(chǔ)架構(gòu)

從圖1可以明顯地看出，整個系統(tǒng)是標準的IOE結(jié)構(gòu)。事實上，在過去的二三十年間，全國***勢資源的投放點一直都是傳統(tǒng)的金融IT領(lǐng)域而非互聯(lián)網(wǎng)領(lǐng)域，因此金融業(yè)的IT系統(tǒng)一點都不落后，并且無論是團隊技術(shù)還是具體構(gòu)成，都可以說是非常先進的，只是外界很少有機會去接觸和了解它的整個架構(gòu)。在之前阿里巴巴去IOE的浪潮中，有些人存在著一些誤解，覺得金融業(yè)IOE的系統(tǒng)比較低端，但真實情況恰恰相反。

那么，為什么與互聯(lián)網(wǎng)電商行業(yè)相比，金融業(yè)的服務器部署規(guī)模會小一些呢?其原因在于，架構(gòu)是根據(jù)業(yè)務生長出來的，所以傳統(tǒng)金融業(yè)與互聯(lián)網(wǎng)、電商行業(yè)在架構(gòu)上的差別取決于業(yè)務形態(tài)的不同。在互聯(lián)網(wǎng)領(lǐng)域，如一些大的平臺化的電商，在橫向上的每一層(如Web接入層、數(shù)據(jù)庫層)都會布置很多臺機器，但這些機器在同一層上做的都是類似業(yè)務，所以從縱向上的業(yè)務種類來說其數(shù)量卻是有限的。而作為傳統(tǒng)行業(yè)，金融業(yè)IT業(yè)務的種類和復雜度要遠超過大家所熟知的一些電商類應用，它們在縱向上有很多犬牙交錯的復雜的業(yè)務關(guān)聯(lián)，但每個業(yè)務線都是在單獨的一套系統(tǒng)里的，彼此隔離，并不要求有太多的橫向傳播。所以金融業(yè)的IT架構(gòu)不是做不到大規(guī)模的多機器布置，而是業(yè)務沒有這個需求。在過去的二三十年當中，由于業(yè)務不斷往下生長，國內(nèi)外絕大部分的金融IT業(yè)***的形態(tài)都是像煙囪一樣垂直的結(jié)構(gòu)，系統(tǒng)之間是上下層的關(guān)系。這樣的確是有限制的，但是它的合理性支撐了過去30年內(nèi)中國的金融秩序和正常運行。舉個例子，大家在上門戶網(wǎng)站或電商網(wǎng)站時，有些會出現(xiàn)網(wǎng)頁打不開的情況，但是到銀行取錢時從來沒有遇到過銀行無法操作的事情，金融業(yè)的交易一直保持非常平穩(wěn)，這就需要業(yè)務背后的系統(tǒng)的有效支撐。

2.IT環(huán)境真相：分而治之，嚴格管控

傳統(tǒng)金融業(yè)的IT環(huán)境包括三個部分：Dev/Test、Staging和Production，如圖2所示。

圖2 金融業(yè)IT環(huán)境構(gòu)成

圖2中環(huán)境的設定與互聯(lián)網(wǎng)行業(yè)叫法類似，但物理上的表現(xiàn)可能會完全不同。而在傳統(tǒng)金融業(yè)內(nèi)部，不同項目組技術(shù)團隊成員在開發(fā)流程和方法上有比較大的差異。比如Dev/Test場景，金融業(yè)內(nèi)部有多樣的團隊可能為同一個項目服務，有自己的技術(shù)開發(fā)團隊，有做產(chǎn)品的金融專業(yè)團隊，還有外包團隊，這就導致了在流程上無法高效融合。此外，金融業(yè)對于以上環(huán)境的安全管控也會非常嚴格。在 staging 環(huán)境中，銀行會導入一些經(jīng)過脫敏的真實的交易數(shù)據(jù)，有一些業(yè)務網(wǎng)點甚至會直接來到staging環(huán)境里做實驗性業(yè)務，或者完成完整的業(yè)務視角的UAT測試。因此它的安全性、可用性、容量等都是嚴控制的，甚至在一些大型金融行業(yè)的數(shù)據(jù)中心staging機房設置有多門崗，對進出人員進行管控。而 Production環(huán)境就不用說了，只會在管控上更加嚴格。

#p#

3.技術(shù)發(fā)展真相：互聯(lián)網(wǎng)做的，他們都懂

2000年，金融業(yè)開始了從RISC到IA的架構(gòu)轉(zhuǎn)變，這場變化進行得如火如荼，大家都在探討是否要在系統(tǒng)核心外圍和邊界上面把大型的UNIX系統(tǒng)替換成Linux。這個過程持續(xù)了四五年的時間，UNIX To Linux在一些機構(gòu)開始推行。接下來是開源架構(gòu)，2004-2005年用戶開始在一些網(wǎng)銀系統(tǒng)外圍的生產(chǎn)環(huán)境中使用一些工具。后來分布式架構(gòu)出現(xiàn)了，2005-2007年間金融客戶開始在前端核心的外圍和渠道業(yè)務(如銀證、銀基、銀保，水電煤支付或者代理的當他交易)中使用開源架構(gòu)，甚至有一些走得比較快的金融用戶，會從國外學習。國內(nèi)的金融及證券交易所跟美國的互聯(lián)網(wǎng)公司、電商企業(yè)一直都在進行著交流，雙方的專家也會互相深入到對方的實際工作環(huán)境中進行分享。從2008年開始，虛擬化出現(xiàn)了，接下來就是云計算和大數(shù)據(jù)。這時，銀行的業(yè)務受到了所謂的影響，實際上金融行業(yè)最熟悉如何包裝市場需要的金融產(chǎn)品。早在四五年前金融互聯(lián)網(wǎng)化剛剛出現(xiàn)苗頭時，相當一部分的金融企業(yè)向?qū)诒O(jiān)管機構(gòu)申請，并且做出了類似余額寶的業(yè)務，當時某些產(chǎn)品的投資回報率還是相當可觀的。但是后來監(jiān)管機構(gòu)從整個市場的運行安全角度考慮，同時政策指引層面也需要時間去了解和消化，這些業(yè)務開展提案大多數(shù)都沒有通過。

后來移動業(yè)務開始興起，基本上每個銀行都在做并且越做越好。然后是敏捷和DevOps的來臨，敏捷在很多走在前面的金融機構(gòu)早已開展，但是DevOps對于金融行業(yè)來說跟進是比較困難的，這不是技術(shù)上或是人力上的原因，而是在管理上更多的考慮和限制。

接著開始了所謂的“去IOE”話題，大型金融企業(yè)也紛紛投身到了IT建設自主可控的大潮當中。所以，從金融行業(yè)的IT基礎(chǔ)架構(gòu)建立起至今，技術(shù)和結(jié)構(gòu)上的革新從來沒有停止過，而是保持了對新技術(shù)的高度關(guān)注，順時而動。到現(xiàn)在出現(xiàn)了 Docker，出現(xiàn)了自動化運維等一批新興技術(shù)，這些金融機構(gòu)的IT團隊也在積極的研究。但是在金融行業(yè)實際的場景中，對于這些目前停留在調(diào)研階段，因為金融業(yè)的業(yè)務場景中風險控制和生產(chǎn)安全是首位的。

4.技術(shù)選型真相：從集中式到分布式，“動物園”的資源分配

這里需要引入一個關(guān)于架構(gòu)模型的問題，即“動物園”跟“牛群”之間的關(guān)系。由于業(yè)務的特點，金融行業(yè)形成了目前這種集中式的結(jié)構(gòu)，它具有和電商、互聯(lián)網(wǎng)領(lǐng)域完全不同的業(yè)務形態(tài)——業(yè)務種類繁多，但每個業(yè)務的IT結(jié)構(gòu)中的每一層規(guī)模相比于代行互聯(lián)網(wǎng)企業(yè)的結(jié)構(gòu)來說沒有那么大，不同業(yè)務之間邊界相對比較清楚。所以實際上這樣的場景是一個“動物園”場景，管理者要去精細分類管理照料這些動物。而在互聯(lián)網(wǎng)及電商領(lǐng)域，IT系統(tǒng)多采用分布式架構(gòu)，架構(gòu)的每一層都是一個“牛群”。在這樣的一個模型里，每一頭“牛”對整體來說都幾乎是同質(zhì)的。同一層的 “牛群”中的“牛”，獲得資源是盡可能平均的。但是“動物園” 模式里就不一樣，由于不同“動物”對資源的消耗存在差別，會產(chǎn)生不同的管理模式。將“動物園”和“牛群”的具體模型對比如圖3所示。

圖3 金融業(yè)與互聯(lián)網(wǎng)行業(yè)的IT模型示意圖

所以在“動物園”，即傳統(tǒng)金融領(lǐng)域，解決的是在這樣一個環(huán)境里面如何實現(xiàn)資源的高效合理分配的問題，這是集中式“煙囪”模型向分布式結(jié)構(gòu)轉(zhuǎn)換時必須要重點解決的。那么，針對資源管控的解決，結(jié)合開源精神，需要進行以下思考。

1)是否存在已知的解決方案

目前可以選擇的方案有HPC中的PBS，Conder及Platform的資源調(diào)度和服務管理技術(shù)，這是傳統(tǒng)分布式計算領(lǐng)域的;還有來自現(xiàn)代互聯(lián)網(wǎng)領(lǐng)域的分布式資源調(diào)度和服務管理技術(shù)，比如Hadoop YARN、Apache Mesos和Google Kubernetes等。

2)它們是否適合金融業(yè)的問題場景

然后要看看一下這些解是不是能解決我們實際面臨的問題，如果可以，就能直接做一些實施集成的工作來實現(xiàn)了。下面依次對這些產(chǎn)品進行分析。

Condor

Condor是過去十年里，傳統(tǒng)IT領(lǐng)域在大型集群調(diào)度方面做得非常好的產(chǎn)品。Condor系統(tǒng)是面向高吞吐率計算而設計的，它的主要目的就是利用網(wǎng)絡中工作站的空閑時間來為用戶服務。

• Condor采用集中式調(diào)度模式,且不能保障用戶服務質(zhì)量。
• 最小完成時間算法MCT(Minimum Completion Time)是以任意的順序?qū)⑷蝿沼成涞骄哂凶钤缤瓿蓵r間的主機上，它并不保證任務被指派到執(zhí)行它最快的主機上，而僅關(guān)心如何最小化任務完成時間，因而可能導致任務在資源上的運行時間過長，從而潛在地增加了調(diào)度跨度。
• 以MCT算法為基礎(chǔ)演伸出了Min-Min算法，它是利用MCT矩陣，先分別找到能夠最短完成該任務的機器及最短完成時間，然后在所有的最短完成時間中找出最小的最短完成時間對應的任務。Min-Min算法存在著一個很大的缺點，就是算法的資源負載均衡性能(Load Balancing)不高。
• Max-Min算法與Min-Min算法相似，都是將任務指派給具有最小預測完成時間的主機，不同的是Max-Min算法從所有任務的最小完成時間中選取一個***值，然后進行相應任務。主機映射，之后重復此過程直至待調(diào)度任務集合為空。
• 輪詢調(diào)度(Round Robin Scheduling)算法就是以輪詢的方式依次將請求調(diào)度不同的服務器，即每次調(diào)度執(zhí)行i = (i + 1) mod n，并選出第i臺服務器。輪叫調(diào)度算法假設所有服務器處理性能均相同，不管服務器的當前連接數(shù)和響應速度。該算法相對簡單，不適用于服務器組中處理性能不一的情況,而且當請求服務時間變化比較大時，輪詢調(diào)度算法容易導致服務器間的負載不平衡。

Mesos和YARN

• Mesos 采用了DRF(Dominant Resource Fairness)調(diào)度機制。YARN自帶FIFO、Capacity Scheduler和Fair Scheduler(借鑒了Mesos的DRF)。
• Mesos中的DRF調(diào)度算法過分的追求公平，沒有考慮到實際的應用需求。在實際生產(chǎn)線上，往往需要類似于Hadoop中Capacity Scheduler的調(diào)度機制，將所有資源分成若干個queue，每個queue分配一定量的資源，每個user有一定的資源使用上限。
• Mesos采用了Resource Offer機制，這種調(diào)度機制面臨著資源碎片問題，即每個節(jié)點上的資源不可能全部被分配完，剩下的一點可能不足以讓任何任務運行，這樣便產(chǎn)生了類似于操作系統(tǒng)中的內(nèi)存碎片問題。
• YARN適合Long running job和數(shù)據(jù)分析類資源的調(diào)度，對于數(shù)據(jù)庫類等短運行時場景資源調(diào)度效果較差。
• YARN采用了增量資源分配機制(當應用程序申請的資源暫時無法保證時，為應用程序預留一個節(jié)點上的資源直到累計釋放的空閑資源滿足應用程序需求)，這種機制會造成浪費，但不會出現(xiàn)餓死現(xiàn)象。
• Mesos和YARN的調(diào)度器的擴展和定制在開發(fā)上都比較繁瑣。

Kubernetes

• Kubernetes僅僅是實現(xiàn)了一個極其簡單的調(diào)度器。鼓勵開發(fā)者編寫自己的調(diào)度器注冊進框架。
• 調(diào)度策略分為兩大類：Predicates和Priorities，其中Predicates判斷是否將pod調(diào)度到特定 minion(host)上運行，而Priorities則是在Predicates的計算基礎(chǔ)上，通過積分Score方式，決定調(diào)度量。
• redicates包括：PodFitsPorts、 PodFitsResources、NoDiskConflict、MatchNodeSelector和 HostName，即一個minion能夠被選中的前提是需要經(jīng)歷前面提到的這5個Predicates的檢驗，而Priorities又包括：LeastRequestedPriority、ServiceSpreadingPriority和EqualPriority，分別為通過 Predicates檢驗的minion計算優(yōu)先級(score)，score是一個范圍是0-10的整數(shù)，0代表***優(yōu)先級，10代表***優(yōu)先級。
• 調(diào)度機制還是過于平均，Predicates本質(zhì)上作為一個過濾器，帶有太多資源的物理屬性。
• 調(diào)度機制非常適合公有云場景，對于私有云領(lǐng)域欠缺靈活性。

#p#

5.求解之路：基于場景的加權(quán)算法SWF

很可惜，以上提到的這些技術(shù)都分別有不適合傳統(tǒng)金融業(yè)的應用環(huán)境的地方，但開發(fā)人員也從對他們的分析中得到了一些啟發(fā)。比如，Kubernetes算法跟其他算法相比***的優(yōu)勢在于關(guān)注到了服務使用資源的需求是不一樣的，但是它的調(diào)度做得非常簡單，基本上還是個平均的調(diào)度。因此，我們開發(fā)團隊進行一段時間的深入研究，設計了一套基于場景數(shù)據(jù)的加權(quán)算法(SWF，Scene Based Weighted Fairness)，即將性能和一些場景數(shù)據(jù)按照時間片采集下來，然后經(jīng)過算法計算，用短期和中長期分類來對應應用在資源池內(nèi)投產(chǎn)的不同階段，因為基礎(chǔ)項目建設一開始資源用得相對少，后面會逐步增多，也可能出現(xiàn)業(yè)務爆發(fā)，支撐平臺出現(xiàn)資源請求高峰。而且通過和業(yè)務場景對應的權(quán)重，實現(xiàn)人工干預調(diào)度里面的資源的均衡狀況。還可以通過權(quán)重比, 從利用率優(yōu)先、容量優(yōu)先和可用性優(yōu)先進行調(diào)控。SWF具體的開發(fā)實現(xiàn)采用了較為獨立的模塊方式，方便將來開源后被第三方用戶使用、定制和集成。它具備以下特性：

• 適合金融行業(yè)架構(gòu)和業(yè)務場景的資源調(diào)度機制，圍繞各種對資源有不同分配使用要求的應用開展調(diào)度工作;
• 針對不同生產(chǎn)區(qū)域(devops/test，staging，production)實現(xiàn)基于權(quán)重比的調(diào)度調(diào)整方式;
• 實現(xiàn)局部調(diào)度的個性化和全局調(diào)度的公平性 ;
• 杜絕簡單粗暴的調(diào)度，對關(guān)鍵業(yè)務應用的運行影響降低。

目前該算法正在面向金融行業(yè)應用場景，進行持續(xù)地開發(fā)演進和代碼調(diào)整。

雛形與未來：將容器技術(shù)運用到實際場景

目前，余軍的團隊在圍繞容器技術(shù)正在做一些面向金融行業(yè)場景的嚴肅而有趣的嘗試。

首先，他們構(gòu)建了一套資源池管理系統(tǒng)，所有工作都圍繞資源池的調(diào)度來進行。在其上做了一層開放層的資源池的調(diào)度工具，包括資源調(diào)度、彈性伸縮、服務發(fā)現(xiàn)等，如圖4所示。

圖4 資源池及調(diào)度工具示意圖

然后，構(gòu)建了調(diào)度批處理的作業(yè)調(diào)度、性能管理，此外還基于算法以及資源池的調(diào)度系統(tǒng)做了一個跨邏輯數(shù)據(jù)中心的方案，如圖5所示。

圖5 數(shù)據(jù)中心方案示意圖

值得一提的是，以上所有工作均采用Go語言編寫，并且100%自主研發(fā)，并逐步完整開源給社區(qū)，希望幫助到那些有同樣業(yè)務場景需要解決資源調(diào)度的開發(fā)人員和團隊。相信未來這些方案的具體實現(xiàn)會為云計算領(lǐng)域提供一個優(yōu)秀的金融行業(yè)場景落地案例。

可以看出，無論是“動物園”還是“牛群”，雖然由于業(yè)務形態(tài)和監(jiān)管力度的不同，二者在技術(shù)應用的具體形態(tài)上存在差異，但IT系統(tǒng)在本質(zhì)上，都有著共同的訴求：對業(yè)務的完善支撐、穩(wěn)定性、可靠性以及對資源的高效合理分配。相信通過余軍的介紹，可以為對于傳統(tǒng)金融IT行業(yè)感到好奇的人們打開一扇窗，讓大家一睹窗內(nèi)實際的景象，并在自身系統(tǒng)的構(gòu)建中借鑒到一些技術(shù)思想。

博文出處：http://blog.qiniu.com/archives/2552

當前題目：傳統(tǒng)金融業(yè)IT真相揭秘：“動物園”“牛群”玩法大不同
瀏覽路徑：http://fisionsoft.com.cn/article/djshjec.html