細解網易寶系統架構之高可用篇

時間 2019-11-10

原文原文鏈接

網易寶支撐了整個集團業務絕大部分的支付場景，平均天天的支付訂單有100萬單，接近1億的交易額。對系統的可用性要求極高。下面就從個人理解上說說網易寶的系統是如何實現高可用的。linux

1. 網易寶系統的總體架構

先看看網易寶的系統總體架構(16年初的架構)nginx

網易寶目前系統總體架構圖web

中間大的淺藍色的部分爲網易寶系統的整個體系。按照從下到上的層次關係分爲存儲層、技術組件、服務層、接入層。每一個層都有系統監控來監控系統的狀態。服務層和接入層有風控系統來監控風險行爲，保障用戶資金的安全。算法

存儲層：數據庫主要使用Oracle。網易寶的核心支付服務是基於本地事務去保證數據強一致性的。用戶支付完成，訂單狀態修改成成功，扣除餘額，產生資金流水，須要強一致性的保證。訂單和流水的數據佔了網易寶數據庫業務數據的絕大部分。Oracle在單機大表的性能上是很是高的。因此數據庫採用的Oracle。文件存儲主要使用的FTP。用於存放銀行清算文件、對帳文件、結算文件。sql

技術組件層：包括dubbo分佈式遠程調用中間件、消息隊列中間件kafka、分佈式應用程序協調服務Zookeeper、分佈式緩存存儲memcached、杭研調度系統、linux-crontab（逐步遷移到杭研調度系統上，後續廢棄）數據庫

服務層：爲網易寶的核心層，提供高內聚的服務。網易寶支持多樣化的支付需求是經過組裝服務層的服務來完成業務流程的。包括用戶帳戶服務，訂單查詢服務，支付核心服務（實現了實名，綁卡，充值，支付，提現，退款的核心流程）；網關服務payments-trans接入了幾十家銀行和其餘支付通道；積分服務提供積分成包的充值、提現、發放和消費服務；網關路由服務gate-service提供支付時路由到具體的支付通道的服務；sign-service提供簽名服務，保證內部系統之間和外部系統的調用請求的安全性；pay-gate提供第三方支付通道的對接服務；platform-module提供商戶數據的查詢服務。接入服務層的服務的方式包括dubbo,http,依賴jar組件。對帳中心和結算中心不參與用戶支付的流程，對帳中心支持全部銀行通道的對帳，覈對咱們的備付金和用戶商戶的帳戶資金徹底無誤，對網易寶的資金流水按會計分錄作到日切，符合人行的監管要求。結算中心給商戶提供人民幣結算服務和外幣結算服務。後端

接入層: 分爲前臺系統（界面交互，後臺API接口）和管理後臺系統。前臺系統包括用戶前臺epay-web、收銀臺cashier(從epay-web拆分出來，正在開發中)、網易寶用戶端APP、可嵌入第三方APP的支付SDK組件、活動系統promotion、商戶前臺系統platform-web。管理後臺系統包括後臺管理epay-admin、網關管理payments-admin、商戶後臺管理platform-boss（正在開發中）。緩存

風控：對用戶在網易寶的整個行爲作風險控制，保障用戶帳號和資金的安全。風控經過kafka異步方式同步網易寶的業務數據，運用大數據處理技術作分析。安全

與網易寶接入層人機交互的有用戶、商戶、後臺管理人員（技術支持&客服&財務），商戶的應用（遊戲、考拉、一元奪寶、郵箱、理財等）。性能優化

網關係統和對帳中心後臺依賴幾十家銀行的網關。

以上對網易寶的整個體系架構按照層次作了個簡單的介紹，下面進入主題，網易寶系統是怎麼實現總體系統的高可用性的。

2. 系統高可用性的分析

2.1 集羣部署、負載均衡、備份(消除單點問題)

網易寶的全部核心應用和中間件都是集羣部署的，經過負載均衡，平均分配流量。

對於業務系統，在nginx服務器(nginx集羣部署，負載均衡使用LVS)上配置了負載均衡策略，路由請求到後端的應用服務器resin。若是web應用集羣某臺機器掛了，nginx經過心跳健康檢查，3秒內能檢測到，把這臺機器從可用列表中剔除出去。

中間件dubbo的consumer基於負載均衡算法，獲取zookeeper上統計的provider的負載狀況，決定請求哪臺provider。Kafka也是相似的原理。若是dubbo服務的某臺provider掛了，與provider維持長鏈接的zookeeper心跳線程會檢測到，把provider從服務的可用provider列表中剔除，並快速通知到全部依賴該服務的consumer(也是維持的TCP長鏈接)，consumer更新本地緩存的provider列表。

對於有狀態的服務器，都有數據備份機制。

數據庫主庫會異步同步數據到備庫。數據庫主庫掛了，若是切到備庫，可能會丟失部分業務數據(異步複製，網絡穩定狀況下10ms之內的延遲，不是同步寫多份的)。Kafka每條消息都會複製到不一樣的機器(broker)上。Zookeeper上的數據也是多寫的。Kafka的主broker掛了或者zookeeper的主服務器掛了，經過選舉算法選舉出新的leader。Leader用於讀寫，slavers用於備份。Leader掛了，從slavers中選舉出新的leader快速恢復服務。Kafka和zookeeper是作了數據高可靠性保證的，極小機率會出現丟失數據的狀況。

多機房部署上，網易寶有杭州、北京兩地機房。杭州是主機房，北京是備，不是多活的。北京的機房服務器數量較少，數據庫服務器性能較差，數據複製也有秒級的延遲。因此不到萬不得已，是不會切到備用機房的。目前網易支付已經在搭建義橋的機房，2017年實現濱江機房和義橋機房的雙活,解決機房的單點問題。

綜上所述，在同一個機房，網易寶不管是無狀態的服務器，仍是有狀態的服務器，從存儲層，到中間件層，到應用層，都不存在單點問題。機房的單點問題也會在不久後解決。

2.2 緩存：空間換時間

更新不頻繁的基礎熱點數據，如配置項、全部商戶信息、網關數據，在應用啓動時，加載到本地緩存。減小對數據庫的頻繁調用。

2.3 應用無狀態化，支持橫向擴展

網易寶的session管理使用中心化的memcached集羣，業務流程中的一些狀態數據，也是存放到memcached。系統之間使用文件數據交互的，文件保存到FTP。須要持久化的業務數據保存到中心化的數據庫。不論是業務數據，仍是非業務數據，都不會保存到本地應用服務器，保證應用無狀態化，使得應用集羣能夠快速的橫向擴展。

2.4 讀寫分離

爲了保證核心支付服務的穩定性，數據庫上作了讀寫分離。核心業務的讀寫走主庫。對於讀實時性要求不高的查詢場景，查詢備庫。如商戶系統訂單的查詢請求。對於耗時長的sql的查詢場景，查詢異構庫，如商戶的對帳單下載。

2.5 異步化

熱點帳戶處理異步化

爲了不熱點帳戶上的行鎖的激烈競爭影響系統吞吐，網易寶對熱點帳戶的餘額更新和資金流水生成，作了異步處理。業務完成後若是須要變更熱點帳戶的金額，先生成緩衝流水，而後由調度任務異步去消費緩衝流水去更新餘額、生成資金流水。使熱點帳戶的併發鎖競爭變成了串行處理，大大下降了行鎖競爭致使的線程阻塞，提升了系統的吞吐。

提現、退款處理異步化

提現、退款處理對實時性的要求不高，經過異步化，對於處理失敗的訂單能夠用重試機制補償。避免了同步調用失敗給用戶很差的體驗。

2.6 系統拆分解耦、核心代碼多版本歸一

早期的網易寶只包括epay、epay-admin、payments、sign幾個系統。大部分的業務功能都集中在epay一個應用裏。epay應用很是的龐大，包含了用戶前臺、收銀臺、積分成包、活動、商戶前臺功能、API、風控、資金對帳監控。存在如下幾個問題：

a.核心業務功能和非核心業務功能在一個系統裏，代碼緊耦合，而且公用服務器資源，非核心業務功能出現問題容易影響到核心業務功能。

b.在一個應用上大量的分支並行開發feature，合併代碼容易衝突。應用的一次發佈包含幾十個feature。一個feafure發佈出問題，發佈回滾，致使其餘feature也一塊兒回滾了。形成開發效率和發佈效率低。

c.epay系統通過幾年的業務和技術選型升級，遺留下代碼多套並存的問題。一個需求的變動，可能須要從上層到下層，改動多套代碼。核心代碼的多套並存、低內聚，代碼難以維護，使開發的工做量變大，而且容易出bug。使後續的系統拆分，服務化改造困難重重。

爲了提升系統的總體可用性，提升你們的工做效率，針對以上幾個問題，網易寶在過去的一兩年裏作了不少的重構改造工做。包括如下幾個方面：

2.6.1 系統拆分

積分成包底層service從epay中拆分出來，獨立jifen系統，提供服務化的接口。

活動功能從epay中拆分出來，獨立promotion系統，提供活動業務功能。

風控模塊從epay中拆分出來，獨立risk系統，提供限額服務、黑白名單服務、反洗錢監控、用戶風險評級。

網關路由模塊從epay中拆分出來，獨立gate-service系統，提供網關查詢和路由支付、提現通道的高可用服務。

Epay與網關路由服務的調用關係

商戶前臺系統從epay中拆分出來，獨立platform-web系統，提供商戶的業務功能。

商戶系統模塊依賴關係圖

2.6.2 代碼重構

在此我向你們推薦一個架構學習交流羣。交流學習羣號：821169538 裏面會分享一些資深架構師錄製的視頻錄像：有Spring，MyBatis，Netty源碼分析，高併發、高性能、分佈式、微服務架構的原理，JVM性能優化、分佈式架構等這些成爲架構師必備的知識體系。還能領取免費的學習資源，目前受益良多。