見習記者黃傑深圳報道

　　馬智濤有種如釋重負的感覺。

　　一年前，他還在順豐速運時，在一次飯局上朋友説起微眾銀行，他想到的是一張白紙，以及一個百年難遇的機會。而此刻，他的身份已經是微眾銀行首席資訊官（CTO）。

　　這是整個專訪裏難得出現的形容詞：“如果從一張白紙開始搭建一個銀行平臺，我們都不敢跳出過去的框框走向‘去IOE’這條路，我們的代價不僅僅是自己還有整個行業。這一步是必須走的，只不過不知道是誰來走。”

　　馬智濤的另一段經歷是：一些大行在銀行IT上想法與微眾一致，但囿于傳統架構和海量賬戶遷移風險，難以做去IOE的決策。馬智濤了解這種決策的難處，因為早前的十年間，他就在中國平安負責IT，深諳一個沒有歷史包袱的機會，便成了百年難遇。

　　為什麼要去IOE？

　　IOE分別指IBM（國際商用機器）、Oracle（甲骨文）和EMC（易安信），三者分別是小型機、數據庫和高端存儲的領導廠商，他們組成的系統被視為大型金融機構後臺的“黃金架構”。

　　傳統金融機構普遍沿用IOE架構，即集中式架構+閉源商用系統。程式基本運作在一、兩台主機伺服器上，其中一台是備用機。IOE還提供了應用程式以外的所有基礎軟體，包括作業系統、中間件、數據庫等。而這些基礎軟體的源代碼一般都是不公開的。

　　這些閉源系統的安全性討論自“斯諾登事件”後被放大。關於銀行業去IOE，監管層曾發佈《關於應用安全可控資訊技術、加強銀行業網路安全和資訊化建設的指導意見》，意見核心在於自主可控、減少對IOE等廠商的依賴。

　　“為什麼會選擇走這條技術路徑？事實上對於微眾來講，我們別無選擇。”馬智濤説。在App推出時，微眾銀行將自己定位為中國首家“去IOE”銀行IT系統。

　　行業談到去IOE時，更多被關注的是成本問題。但在馬智濤看來，新型銀行需要掌握核心技術，這是創新業務和自主可控的前提；另一方面網際網路銀行海量交易、數據和事件驅動行銷的特點，會帶來許多突增的業務量，因此需要一個具備靈活伸縮性的平臺；回到普惠金融的定位，微眾也必須在成本結構上具備優勢。

　　具體到銀行IT系統的搭建，這些想法的落地也決定了微眾“去IOE”的路徑，創新即技術上不能依賴外部廠商，而現成的銀行IT解決方案也難以具備微眾所要求的伸縮能力，回到成本，IOE架構背後的成本是微眾無法承擔的。

　　成本優勢如何體現？根據馬智濤的測算，通過標準化的硬體及開源軟體，微眾所能夠做到的成本應該是傳統銀行的十分之一。

　　“我們的判斷是，兩千萬的賬戶規模是一個比較重要的節點，超過這個規模，微眾銀行IT成本架構的優勢是非常突出的。”馬智濤説。

　　如何去IOE？

　　馬智濤所説的成本優勢，簡而言之是通過標準化的硬體和開源軟體來實現的。這與傳統銀行集中式架構+閉源商用系統相反，而是參照網際網路企業通常採用的開放式架構。

　　講分佈式架構之前，馬智濤用了一個比方：往一個很大的水杯里加水，當水杯滿了，可能要更換一個更大的水杯來把這些水倒到大水杯上去，而微眾的做法，是一個一個的小水杯，當一個水杯滿了以後，只需要增加水杯，就可以裝更多的水。

　　回到傳統銀行的IOE架構，在需要擴容的時候，更換計算硬體、數據遷移都是非常複雜的操作，對銀行IT系統安全性和穩定性構成極大風險，這也是大行去IOE一大難點。

　　以銀行業務系統和賬戶體系為例，在傳統銀行架構下，假設一台伺服器能裝500萬賬戶，當容量達到500萬賬戶以前，就要換上一台可以裝1000萬賬戶的機器，然後把500萬賬戶搬過去。這個過程涉及數據遷移，操作風險高，擴容週期長，成本投入亦不菲。

　　微眾式的去IOE，首先在硬體上，採用大量標準化的硬體，分佈式架構決定了用低端設備X86替代IBM的可能性。數據庫方面，運作在X86伺服器上的數據庫TD-SQL（騰訊基於MySQL開源體系下開發的數據庫），可實現數十萬級IOPS（每秒讀寫操作次數）的讀寫能力。

　　軟體方面，微眾大量採用了開源技術，如Java、MySQL、Linux、LVS等，以及多個結合騰訊經驗改造優化的開源軟體，包括TGW、TLinux、TDW等。

　　網際網路銀行海量數據、交易，移動支付、同業合作的特點，也決定了分佈式架構落地。打散的數據分佈一方面實現了海量數據處理能力，不同節點的分佈，也帶來橫向擴展和可伸縮性的可能。

　　這一IT設計理念，實際上借鑒了早期商業銀行按照分行部署業務系統的經驗，在微眾的實踐中昇華至“數據分佈、管理集中”的整體設計原則。

　　安全性之考

　　分佈式架構和開源系統決定了微眾銀行的成本優勢，而金融機構的安全性和穩定性要求，是否能沿用網際網路公司的IT架構？

　　這個問題上，傳統銀行的懷疑恐怕多於想像。而馬智濤認為，這是一個誤解。打散的數據分佈，每個計算節點上承載的數據量和風險已經被大幅度降低，“億級的數據你可能不敢放在一台低端設備上，但把它們打散到十個、二十個節點後，這些設備的處理能力和穩定性是綽綽有餘的。”

　　傳統銀行基於安全的考慮，使用兩地三中心的容災體系，通常是一個中心工作、一個備用。而微眾的做法是兩個同城中心同時運作，此前這兩個中心承載的計算量是6：4，兩個星期前微眾將其切換為7：3，驗證了其跨中心切換方案行之有效。這種同城多中心多活的架構設計，也是微眾銀行IT架構滿足高可用性要求的基礎。。

　　在馬智濤看來，金融IT高可用性的頭號殺手是“ 變更”。每次大的功能升級、版本發佈，涉及的系統變更都會構成風險，容易導致服務中斷。在傳統IT集中架構模式下，變更風險往往影響整體。而在分佈式IT架構體系下，變更可以在某一節點上測試，再推至整體，規避全局性風險。

　　IOE體系下另一個問題是，當軟硬體出現問題時，不時需要海外專家跟進處理，而這個週期往往會被延長，這對業務影響是巨大的，這也是監管層關注自主可控的主要原因之一。

　　微眾銀行開業之初，曾將部分賬戶託管在興業銀行銀銀平臺之上，在微眾銀行自身體系搭建起來之前，支援銀行的基本資金運作。

　　這一託管協議的啟示是，在民營銀行試點擴大，利率市場化下競爭加劇背景中，銀行IT的科技輸出將是一片藍海。馬智濤的思考是，微眾銀行可以在直銷渠道和科技能力上幫助新型銀行，類似于微眾此前與銀銀平臺的關係，新型銀行快速開展業務，微眾可以作為服務提供方幫助中小銀行快速開展業務。

　　如何實現科技輸出的標準化？馬智濤認為，這種合作並非一次性或階段性的合作，在微眾銀行平臺上提供的增值服務，包含了數據能力、風控能力、科技能力。

　　有鋻於此，在建設微眾平臺之初，一個重要原則是：需要支援多法人部署的雲服務模式。微眾希望在這種模式下，同業能將業務或應用系統部署在其金融雲平臺之上。“很多同業跟我們交流，都表現了濃厚的興趣，希望在技術方面建立合作，這是一個很大的市場。”馬智濤説。