本文作者：李亞瓊，博雲BoCloud CTO
本文爲《程序員》原創文章，未經允許不得轉載，更多精彩文章請訂閱2016年《程序員》
小微金融、場景金融等新興銀行金融業務亟需一種新型的彈性架構來應對高併發、大流量的業務衝擊，同時，要滿足應用快速版本迭代升級、敏捷運維管理等需求。本文分享了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.版本的迭代升級如何可控有序的得到執行？
上述問題如何解決呢？。回顧前文所說的新一代平臺架構的三個特性，即“重平臺、輕應用、服務化”，其中重平臺和服務化的特性就是上述問題解決思路的方向。
重平臺和服務化概念的背後是整個平臺已經固化了大量可獨立對外提供服務的組件或子系統，應用只需要負責業務邏輯的部分即可完成整個系統的部署上線。要實現這一點，需要做到如下三點：
- 應用需要進行業務邏輯、數據存儲和服務組件的分離，實現業務邏輯、數據和組件服務的獨立運行；
- 平臺要具備根據業務、數據和服務（組件）定義（編排）業務架構的能力，能夠實現業務的編排部署；
- 平臺要能夠實現對業務、組件（服務）和數據存儲個子系統的運維管理，確保其在負載壓力增大時能夠自動彈性伸縮提升用戶體驗。
這就涉及應用封裝、業務編排和彈性伸縮（自動運維）等方面的技術。BoCloud博雲基於Docker的雲應用發佈與運維管理平臺正是基於這樣的理念和需求而開發的。下圖爲BoCloud的BeyondContainer產品架構：
如圖所示，BeyondContainer包括三個主要部分：
- 基礎設施子平臺：負責管理平臺的基礎設施，除了服務器、存儲、網絡等基礎設施外，還包括圍繞應用相關的基礎組件管理，如鏡像倉庫、容器、組件等。
- 應用管控子平臺：負責管理平臺上的各類應用，提供應用部署、維護、日誌等管理管控，同時實現多租戶環境，實現基於服務目錄的應用發佈服務。
- 一體化監控子平臺：負責對整個平臺中的資源、應用、通信等進行監控，並以可視化形式對外呈現系統各類監控信息。
限於篇幅，關於BeyondContainer的架構和特性就不再這裏進行展開闡述。
總結
本文分享了BoCloud博雲在幫助傳統企業在應對移動互聯網業務衝擊時在應用與平臺架構上如何進行創新實踐的經驗，希望能夠對大家有所啓發。