互連網金融高並發方案

標籤：

小微金融、情境金融等新興銀行金融業務亟需一種新型的彈性架構來應對高並發、大流量的業務衝擊，同時，要滿足應用快速版本迭代升級、敏捷營運管理等需求。本文分享了BoCloud博雲如何利用互連網應用架構與Docker容器技術協助銀行業應對“互連網+”挑戰，建設基於PaaS平台的敏捷IT架構。

移動互連網渠道創新是傳統企業無法也不能躲避的業務變革，無論是接入或者自建互連網渠道都需要回答如下問題：現在的IT架構能否應對互連網渠道創新業務的爆炸性衝擊？什麼樣的IT架構才能夠解決這個問題並具備應對未來需求的良好擴充能力？以銀行業為例，傳統的銀行渠道比較單一，基本上圍繞各個分公司和營業網點運營，整個IT系統的建設中效能指標在整個指標體系中的重要性往往要低於業務可靠性。然而，這一切正在發生改變，圍繞互連網渠道的渠道創新業務已經改變了這種現狀。

新金融IT需求

銀行業已經告別了傳統的以銀行業務為中心的業務模式，開始轉變成以客戶需求為核心進行業務設計與金融創新，這也正是情境金融的內涵。無論是傳統的電子銀行業務，還是渠道創新的直銷銀行業務，以及互連網金融的各種寶們，都是滿足客戶各種情境金融需求而建立的金融業務。是現代銀行的一些業務及其基於的運營平台。

圍繞客戶、渠道、資料和平台，銀行業CIO們需要解決三個主要問題：

• 如何快速實現業務上線來應對快速變化的市場？
• 應用架構如何應對互連網渠道帶來的瞬時大規模並發請求帶來的負載壓力？
• 如何?大量業務應用、服務與資料的統一化管理並確保上述兩個問題的解決？

採用過去煙囪式建設模式具有如下三個弊端：

• 建設周期過長。傳統的建設模式從規劃、採購、開發、上線、試運行等階段才能上線一個新的業務應用，時間跨度可以實現從幾個月到幾年，十分漫長。像基於互連網事件的營銷類應用需要及時對事件作出響應，對業務上線周期具有十分苛刻的要求，傳統模式顯然無法滿足。

• 擴充性不能滿足業務需要。傳統的應用一般都是基於規劃容量進行設計與開發，使用者的規模是可以估計，在極端的條件下可以通過排隊等機制降低負載壓力。然而，“秒殺”、“搶購”等應用模式卻不具有這樣的前提條件，使用者規模會在極短的時間內爆炸性增加。簡單的排隊策略會讓使用者大大降低產品和服務的品質評價，無法滿足快速擴充的需要。

• 業務封閉。傳統的業務與業務之間很少互相訪問，商務服務在設計與運營過程中也缺乏複用的考慮，更不用說滿足多個情境並發訪問的需求。

建設思路

為瞭解決上述問題，我們和多家銀行架構部門合作，規划了“重平台、輕應用、服務化”的新金融IT基礎平台。

新一代的IT架構應該具備如下特點：

• IT基礎設施與服務平台已經整合了應用程式所需要的基礎件或服務，比如資源申請服務、調度服務、Message Service、資料服務等等。重平台的概念的內涵就在於大量的基礎服務或者經驗資料能夠在“沉積”在平台中，構成應用基礎架構的核心。
• 應用的開發、上線、迭代升級都需要足夠的敏捷。這一方面依賴與平台整合的基礎服務，另一方面需要平台能夠快速的實現對於應用封裝、發布、迭代升級的支援，具備一鍵式部署、升級等特性。
• 應用的架構需要由平台服務或組件“封裝”而成，服務或組件能夠提高系統的並發性，同時具備可並行化特徵，除了能降低服務響應延遲外，最重要的是可以通過整個平台服務來支撐大並發訪問需求。

從業務需求的角度來說，“輕應用”的平台能夠快速“組裝”出新的業務形態來滿足市場快速變化的需求，“服務化”一方面加強各個業務之間更多的關聯提高了服務品質，另一方面可以把優秀的經驗和實踐固化下來增強企業業務競爭力。“重平台”特性可以通過整個平台的“能力”有效支撐業務負載壓力，確保應用的資源需求、擴充性需求、並發需求等得到滿足。

當然，上述特性不是天然就具備的，需要從應用架構和平台創新兩個方面進行改變來確保目標達到。

應用架構最佳化

回到移動互連網模式下應用應該具備特點：1，需要能夠應對大量使用者同時並發訪問需求，即應用架構要具有優秀的並發性和彈性；2，應用要能夠快速迭代，一方面滿足業務發展需要，另一方面可以不斷對效能進行調優來改進服務品質；3，應用架構要滿足能夠快速“組裝”出新的業務應用來支撐快速變化的市場需要。也就是說，應用架構要具備：

• 強大的並發能力；
• 靈活的彈性；
• 敏捷的迭代能力；
• 標準化可組裝性；

這幾種能力的獲得需要從多個角度對系統進行最佳化，典型的最佳化包括：流量負載平衡、非同步IO、訊息佇列、讀寫分離、分庫分表、對象緩衝、服務拆分、索引服務、分布式內容管理、CDN、空間換時間最佳化等手段。

i.負載平衡

根據業務模型和商務服務協議，一般可選擇的負載平衡方案包括：鏈路層負載平衡、IP層負載平衡、Http反向 Proxy、DNS網域名稱解析負載平衡、Http重新導向負載平衡。大型網站或商務服務往往採用多種手段進行流量的負載平衡，比如先基於DNS實現多資料中心的負載平衡，再根據IP實現資料中心內多業務負載平衡，最後在基於反向 Proxy實現統一業務的不同伺服器之間的負載平衡。

ii.非同步IO

非同步IO是提高系統並發性的重要技術，和非同步IO共同出現的還有任務（訊息）隊列、線程池和持久化串連等技術。非同步IO技術是事件驅動的編程模型實際應用的典範：使用者請求先被放入任務隊列，然後喚醒任務分發器，任務分發器從任務隊列取下任務分發到閒置線程上，線程觸發非同步IO操作並註冊回調方法，當IO返回後回調方法重新從任務隊列中把任務取下並把結果返回。整個過程如下：

iii.訊息佇列

訊息佇列對於提高系統並發效能具有四個方面的作用：1，通過訊息佇列實現非同步處理，如上述非同步IO中的任務隊列就是可以基於訊息佇列實現；2，任務並存執行，通過訊息佇列可以把傳統串列執行的任務盡量改造成可並行的程式；3，應用解耦，提高系統的擴充性； 
4，流量削峰，通過訊息佇列引入排隊機制，可以把尖峰負載盡量平整化。為一個Web網站的訊息系統。

iv.資料庫讀寫分離/分庫分表

隨著訪問量的增多，資料庫系統的壓力會越來越大。在一個資訊系統中，資料庫系統的效能往往是對系統整體效能影響最為關鍵的指標。從資料庫結構描述設計的角度，常用的最佳化手段為讀寫分離與分庫分表。前者是採用讀寫請求分別路由到不同的庫中來降低資料庫系統壓力的一種技術，採用該技術可以最大程度上提高系統的並發讀，特別是對讀多寫少的訪問模式十分有效。兩個庫之間通過資料同步，可以確保資料的一致性。讀寫分離模式如示：

隨著業務的運行，資料庫中的資料量隨之不斷增多。當達到一定的記錄條目時，一次查詢往往需要消耗很長時間才能返回結果。這是分庫分表設計就提到了議程。分庫設計一般根據業務把不同的內容存到不同的資料庫中，也成為垂直分割。這種拆分模式比較靈活，也易於操作，不足之處在於需要考慮跨多資料庫的符合業務查詢join問題。分表設計也叫水平分割，就是把同一個表中的資料拆分到兩個甚至多個資料庫中。產生資料水平分割的原因是某個業務的資料量或者更新量到達了單個資料庫的瓶頸，這時就可以把這個表拆分到兩個或更多個資料庫中。Mycat是最為常用的分庫分庫中介軟體，為Mycat的架構，有興趣的同學可以前往Mycat官方網站學習瞭解。

v.服務拆分

服務拆分是把過去全部運行在一個應用程式容器內部的商務邏輯子系統拆分出來，單獨運行在獨立的容器內部。這樣做有兩個好處：1，可以降低系統耦合度，使得業務具備快速迭代能力；2，方便的定位影響效能的子系統，針對性的進行效能最佳化。例如，簡訊子系統從整個系統中拆分出來後，系統可以方便的測試簡訊收發的並發效率及延遲，這樣可以針對性的進行設計改進與架構最佳化。

vi.記憶體緩衝

隨著訪問量的增加，逐漸出現了許多使用者訪問同一部分內容的情況，對於這些比較熱門的內容，沒必要每次都從資料庫讀取。我們可以使用緩衝技術，例如可以使用memcacahe作為應用程式層的緩衝，也可以使用redis作為資料庫層的緩衝。另外，緩衝系統也可以用來儲存一些需要分享的資料，比如使用者登入的會話資訊（Session）。通過緩衝系統共用工作階段是實現單點登入及會話管理的重要技術。加入緩衝後的系統架構如下。

vii.索引系統

對於模糊尋找，利用讀資料庫進行查詢往往力不從心，即使做了讀寫分離，這個問題依然是影響效能的一種重要情境。以交易網站型為例，基於關鍵詞尋找商品或服務是一種最為常用的功能，尤其是根據商品的標題來尋找對應的商品。對於這種需求，在資料庫操作中我們都是通過like功能來實現的，但是這種方式的開銷很大，且針對大數量查詢時非常耗時。此時我們可以使用搜尋引擎的索引來完成。

viii.分布式儲存系統/CDN

針對非結構化資料的訪問最佳化，一般的策略是構建分布式儲存系統。支撐分布式儲存系統是具備良好擴充性和並發效能的儲存系統，設計良好的分布式儲存系統能夠實現訪問檔案的快速定位、加速讀寫、實現高並發性。例如ceph就是一個優秀的開源分布式儲存系統。 
CDN是更大尺度的最佳化手段，通常使用者大型或超大型網路服務運營。利用CDN，可以把不常變化的資源放置在網路的邊緣，加速終端使用者擷取資源的速度。

ix. 空間換時間最佳化

空間換時間的最佳化一個典型的應用情境是應對不同解析度螢幕時向使用者提供統一圖片的不同解析度的版本，這是根據常見的螢幕解析度在使用者上傳圖片時自動產生不同解析度的圖片避免使用者請求時即時進行轉換的開銷。這種最佳化對於視頻、多格式隱藏檔等也非常有用。

綜上所述，利用各種最佳化手段後整個互連網應用架構如所示。

平台創新

上述架構的落地還面臨一系列挑戰，包括：

1.如何部署實施這麼複雜的系統？ 
2.如何快速的定位高負債壓力瓶頸子系統並自動進行擴容處理？ 
3.版本的迭代升級如何可控有序的得到執行？

上述問題如何解決呢？。回顧前文所說的新一代平台架構的三個特性，即“重平台、輕應用、服務化”，其中重平台和服務化的特性就是上述問題解決思路的方向。

重平台和服務化概念的背後是整個平台已經固化了大量可獨立對外提供服務的組件或子系統，應用只需要負責商務邏輯的部分即可完成整個系統的部署上線。要實現這一點，需要做到如下三點：

1. 應用需要進行商務邏輯、資料存放區和服務元件的分離，實現商務邏輯、資料和元件服務的獨立運行；
2. 平台要具備根據業務、資料和服務（組件）定義（編排）業務架構的能力，能夠實現業務的編排部署；
3. 平台要能夠實現對業務、組件（服務）和資料存放區個子系統的營運管理，確保其在負載壓力增大時能夠自動Auto Scaling提升使用者體驗。 
   這就涉及應用封裝、業務編排和Auto Scaling（自動營運）等方面的技術。BoCloud博雲基於Docker的雲應用發布與營運管理平台正是基於這樣的理念和需求而開發的。為BoCloud的BeyondContainer產品架構：

，BeyondContainer包括三個主要部分：

• 基礎設施子平台：負責管理平台的基礎設施，除了伺服器、儲存、網路等基礎設施外，還包括圍繞應用相關的基礎組件管理，如鏡像倉庫、容器、組件等。
• 應用管控子平台：負責管理平台上的各類應用，提供應用部署、維護、日誌等管理管控，同時實現多租戶環境，實現基於服務類別目錄的應用發布服務。
• 一體化監控子平台：負責對整個平台中的資源、應用、通訊等進行監控，並以可視化形式對外呈現系統各類監控資訊。

限於篇幅，關於BeyondContainer的架構和特性就不再這裡進行展開闡述。

總結 
本文分享了BoCloud博雲在協助傳統企業在應對移動互連網業務衝擊時在應用與平台架構上如何進行創新實踐的經驗，希望能夠對大家有所啟發。

  

互連網金融高並發方案