總述
隨著有貨業務不斷發展，有貨系統架構從原來LAMP一直發展到現在基于混合公有云的雙中心雙活架構；在雙十一活動中，系統在十幾倍高流量的沖擊下運行穩定，用戶體驗流暢，
架構演進
1、 LAMP –> 分布式服務化 (成本、效率)
- A、 從LAMP到基于JAVA的分布式服務化：提升系統性能，開發效率提升
- B、 IDC遷移到公有云：降低設備成本，提升運維效率
2、單中心 –> 混合云雙中心雙活（高可用、容災）
- A、彈性服務能力，避免活動高峰期間中心資源緊缺
- B、中心級災備和高可用
- C、核心業務按用戶維度進行拆分，關鍵業務在本中心完成，避免跨中心資料操作
有貨雙中心雙活架構
1、 架構設計前的思考
A、哪些業務需要做到雙中心雙活
理想情況下，用戶所有業務都在指定中心完成，中心之間只需要資料同步，這種架構下資料同步也可以根據容災級別，分別進行實時同步或離線同步，但要做到理想中的雙活架構，系統中所有資料都需要進行單元化，這對于運行較長時間，資料已經大量積累的系統來講，難度和成本都是極大的挑戰，
基于有貨現有業務場景分析，實作電商核心購物流程(注冊、登錄、瀏覽、購物車、下單業務)的雙活是成本最小，收效最大的方案，實際落地時，在注冊、登錄、庫存場景中，仍然使用主從方案，后續章節有具體分析，
B、資料單元化拆分
單元化是雙活架構的核心，一般來說，單元化有按用戶維度、功能維度以及用戶功能結合三種方式，
有貨雙活架構的核心目標為實作核心購物流程的雙中心雙活，采用基于用戶維護進行單元化，
2、有貨雙中心雙活架構
前端：
- a.通過自建問詢服務器實作雙中心分流，根據uid拆分策略將用戶引導到各自中心，兩個中心同時提供服務，
- b.使用HttpDNS，解決LocalDNS快取問題，防止DNS劫持，
入口層： - a.使用動態CDN，提升服務QoS，
- b.自研分布式服務框架，服務注冊、發現與治理自動化
服務層： - a.自研分布式服務框架，服務注冊、發現與治理自動化，
- b.用戶資訊、訂單、優惠券相關資料庫、表實作資料庫拆分，實作用戶登錄、瀏覽、購物車、下單等核心流程在本中心內完成，
- c.非關鍵業務使用資料庫跨中心主備方式，從中心通過專線跨中心寫入，
- d.雙中心間通過MQ Fedration插件實作訊息跨中心復制，實作業務層跨中心資料同步(用戶session、訂閱、收藏等資料)，
資料層： - a.前臺服務統一通過分布式資料中間件(cobar)接入mysql， 由cobar實作讀寫分離和分庫分表，兩個中心cobar通過配置中心(ConfigureCenter)獲取配置
- b.各中心內資料庫采用MySQL Master-Slave架構，通過MHA進行故障切換
- c.中心間使用MySQL主主復制進行同步，
- d.非核心資料庫(曬單、商品咨詢、意見反饋、社區回復、點贊資訊)主中心master可寫，從中心服務通過專線跨中心寫主中心master，
- e.用戶資訊、訂單、優惠券業務相關表基于用戶維度進行拆分，兩中心各承擔一半業務資料，
雙活架構 - 重點流程分析
1、用戶注冊/登錄流程
由于歷史原因，當前用戶profile表中存在較多的多個uid歸屬同一用戶的情況，這對profile表拆分造成較大困難，因profile表一旦拆分到雙中心，會造成用戶登錄時匹配不到真實uid的情況； profile涉及用戶注冊和登錄，相關業務采用如下流程：
- a.提供用戶注冊資訊保存和用戶session保存API， UIC服務通過DNS從公網訪問該API， API支持強會話、獨立簽名驗證以保障接入安全，
- b.雙中心同時提供保存API并能夠立即提供服務，當前哪個API提供服務由DNS配置指定，
2、庫存服務流程
庫存服務目前為商品庫存、優惠券領取數量，由于涉及原子操作，雙中心拆分實作在當前優勢不明顯，目前暫時使用主中心寫入，再同步到從中心方案，
同登錄注冊API一樣， 庫存操作API需要使用強會話、獨立的安全校驗，以保證接入安全，
3、推薦服務架構
推薦服務不進行雙中心部署，當前架構中，實時推薦資料通過MQ Federation機制將推薦資料發到兩個中心，前臺推薦服務接收到訊息后，將訊息快取到redis，離線推薦資料在凌晨計算完成后直接寫入本中心redis，然后通過腳本同步到另一中心，
4、前后臺介面架構
后臺系統與前臺服務存在MQ和API呼叫介面，業務基本為狀態通知或后臺手工發起的修改操作，介面呼叫頻次低，資料量較小，
后臺為雙中心主備架構，當前未進行雙中心拆分； 前臺服務拆分后，cobar層仍支持跨中心寫，業務流程如下圖：
有貨雙活架構-容災
支持中心級故障容災，一切皆可故障：
架構落地中典型問題
1、訂單號生成
資料單元化后訂單號不能簡單使用資料庫序列，資料庫切換時可能導致資料沖突使得資料沖突，
業內有較好的分布式id生成方案，如UUID、snowflake演算法等；有貨現有訂單號使用全資料，長度較小，因此當前采用中心編號+uid分庫資訊+資料庫序列號，
2、跨中心資料庫切換中資料同步問題
當故障發生需要將主庫切換到另一中心時，需要檢測資料同步是否完成；否則在切回時會出現資料丟失，這會造成故障時切換時間延長；根據雙中心間資料同步時延，一般會有幾十~100ms，
3、資料庫切換后如何及時更新配置
有貨使用分布式資料中間件cobar進行資料主從和分庫分表，在雙活架構下，我們對cobar進行部分定制，資料庫配置放到配置中心；配置中心支持subscribe/notify機制，當資料庫切換時，修改配置中心中資料庫配置，可以及時通知cobar更新配置，
轉載請註明出處，本文鏈接：https://www.uj5u.com/ruanti/16284.html
標籤：架構設計
上一篇：微信搶紅包過期失效實戰案例