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

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

新金融IT需求

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

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

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

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

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

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

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

建設思路

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

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

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

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

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

應用架構優化

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

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

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

i.負載均衡

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

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. 平臺要能夠實現對業務、元件（服務）和資料儲存個子系統的運維管理，確保其在負載壓力增大時能夠自動彈性伸縮提升使用者體驗。 
   這就涉及應用封裝、業務編排和彈性伸縮（自動運維）等方面的技術。BoCloud博雲基於Docker的雲應用釋出與運維管理平臺正是基於這樣的理念和需求而開發的。下圖為BoCloud的BeyondContainer產品架構：

如圖所示，BeyondContainer包括三個主要部分：

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

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

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