有貨雙中心雙活架構(gòu)實踐
一沪停、總述
隨著有貨業(yè)務(wù)不斷發(fā)展煤辨，有貨系統(tǒng)架構(gòu)從原來LAMP一直發(fā)展到現(xiàn)在基于混合公有云的雙中心雙活架構(gòu)；在2017雙十一活動中木张，系統(tǒng)在十幾倍高流量的沖擊下運行穩(wěn)定众辨，用戶體驗流暢。
二舷礼、架構(gòu)演進
1鹃彻、LAMP–>分布式服務(wù)化(成本、效率)
A妻献、從LAMP到基于JAVA的分布式服務(wù)化：提升系統(tǒng)性能蛛株，開發(fā)效率提升
B、IDC遷移到公有云：降低設(shè)備成本育拨，提升運維效率
2谨履、單中心–>混合云雙中心雙活（高可用、容災(zāi)）
A熬丧、彈性服務(wù)能力笋粟，避免活動高峰期間中心資源緊缺
B、中心級災(zāi)備和高可用
C、核心業(yè)務(wù)按用戶維度進行拆分矗钟，關(guān)鍵業(yè)務(wù)在本中心完成唆香，避免跨中心數(shù)據(jù)操作
三、有貨雙中心雙活架構(gòu)
1吨艇、架構(gòu)設(shè)計前的思考
a)、哪些業(yè)務(wù)需要做到雙中心雙活
圖1理想的雙活架構(gòu)
理想情況下腾啥，用戶所有業(yè)務(wù)都在指定中心完成东涡，中心之間只需要數(shù)據(jù)同步，這種架構(gòu)下數(shù)據(jù)同步也可以根據(jù)容災(zāi)級別倘待，分別進行實時同步或離線同步疮跑。但要做到理想中的雙活架構(gòu)，系統(tǒng)中所有數(shù)據(jù)都需要進行單元化凸舵，這對于運行較長時間祖娘，數(shù)據(jù)已經(jīng)大量積累的系統(tǒng)來講，難度和成本都是極大的挑戰(zhàn)啊奄。
基于有貨現(xiàn)有業(yè)務(wù)場景分析渐苏，實現(xiàn)電商核心購物流程(注冊、登錄菇夸、瀏覽琼富、購物車、下單業(yè)務(wù))的雙活是成本最小庄新，收效最大的方案鞠眉。實際落地時，在注冊择诈、登錄械蹋、庫存場景中，仍然使用主從方案羞芍，后續(xù)章節(jié)有具體分析哗戈。
b)、數(shù)據(jù)單元化拆分
單元化是雙活架構(gòu)的核心涩金，一般來說谱醇，單元化有按用戶維度、功能維度以及用戶功能結(jié)合三種方式步做。
有貨雙活架構(gòu)的核心目標為實現(xiàn)核心購物流程的雙中心雙活副渴，采用基于用戶維護進行單元化。
2全度、有貨雙中心雙活架構(gòu)
圖2有貨雙中心雙活架構(gòu)
前端：
a)煮剧、通過自建問詢服務(wù)器實現(xiàn)雙中心分流，根據(jù)uid拆分策略將用戶引導到各自中心，兩個中心同時提供服務(wù)勉盅。
b)佑颇、使用HttpDNS，解決LocalDNS緩存問題草娜，防止DNS劫持挑胸。
入口層：
a)、使用動態(tài)CDN宰闰，提升服務(wù)QoS茬贵。
b)、自研分布式服務(wù)框架移袍，服務(wù)注冊解藻、發(fā)現(xiàn)與治理自動化
服務(wù)層：
a)、自研分布式服務(wù)框架葡盗，服務(wù)注冊螟左、發(fā)現(xiàn)與治理自動化。
b)觅够、用戶信息胶背、訂單、優(yōu)惠券相關(guān)數(shù)據(jù)庫蔚约、表實現(xiàn)數(shù)據(jù)庫拆分奄妨，實現(xiàn)用戶登錄、瀏覽苹祟、購物車砸抛、下單等核心流程在本中心內(nèi)完成。
c)树枫、非關(guān)鍵業(yè)務(wù)使用數(shù)據(jù)庫跨中心主備方式直焙，從中心通過專線跨中心寫入。
d)砂轻、雙中心間通過MQ Fedration插件實現(xiàn)消息跨中心復制奔誓，實現(xiàn)業(yè)務(wù)層跨中心數(shù)據(jù)同步(用戶session、訂閱搔涝、收藏等數(shù)據(jù))厨喂。
數(shù)據(jù)層：
a)、前臺服務(wù)統(tǒng)一通過分布式數(shù)據(jù)中間件(cobar)接入mysql庄呈， 由cobar實現(xiàn)讀寫分離和分庫分表蜕煌，兩個中心cobar通過配置中心(ConfigureCenter)獲取配置
b)、各中心內(nèi)數(shù)據(jù)庫采用MySQL Master-Slave架構(gòu)诬留，通過MHA進行故障切換
c)斜纪、中心間使用MySQL主主復制進行同步贫母。
d)、非核心數(shù)據(jù)庫(曬單盒刚、商品咨詢腺劣、意見反饋、社區(qū)回復因块、點贊信息)主中心master可寫橘原，從中心服務(wù)通過專線跨中心寫主中心master。
e)涡上、用戶信息靠柑、訂單、優(yōu)惠券業(yè)務(wù)相關(guān)表基于用戶維度進行拆分吓懈，兩中心各承擔一半業(yè)務(wù)數(shù)據(jù)。
四靡狞、雙活架構(gòu)-重點流程分析
1耻警、用戶注冊/登錄流程
由于歷史原因，當前用戶profile表中存在較多的多個uid歸屬同一用戶的情況甸怕，這對profile表拆分造成較大困難甘穿。因profile表一旦拆分到雙中心，會造成用戶登錄時匹配不到真實uid的情況梢杭；profile涉及用戶注冊和登錄温兼，相關(guān)業(yè)務(wù)采用如下流程：
圖3新用戶注冊
圖4用戶登錄(賬號密碼或第三方賬號)
a)、提供用戶注冊信息保存和用戶session保存API武契，UIC服務(wù)通過DNS從公網(wǎng)訪問該API募判，API支持強會話、獨立簽名驗證以保障接入安全咒唆。
b)届垫、雙中心同時提供保存API并能夠立即提供服務(wù)，當前哪個API提供服務(wù)由DNS配置指定全释。
2装处、庫存服務(wù)流程
庫存服務(wù)目前為商品庫存、優(yōu)惠券領(lǐng)取數(shù)量浸船，由于涉及原子操作妄迁，雙中心拆分實現(xiàn)在當前優(yōu)勢不明顯，目前暫時使用主中心寫入李命，再同步到從中心方案登淘。
圖5商品庫存和優(yōu)惠券庫存流程
同登錄注冊API一樣， 庫存操作API需要使用強會話项戴、獨立的安全校驗形帮，以保證接入安全槽惫。
3、推薦服務(wù)架構(gòu)
推薦服務(wù)不進行雙中心部署辩撑，當前架構(gòu)中界斜，實時推薦數(shù)據(jù)通過MQ Federation機制將推薦數(shù)據(jù)發(fā)到兩個中心，前臺推薦服務(wù)接收到消息后合冀，將消息緩存到redis各薇。離線推薦數(shù)據(jù)在凌晨計算完成后直接寫入本中心redis，然后通過腳本同步到另一中心君躺。
圖6推薦服務(wù)與前臺交互
4峭判、前后臺接口架構(gòu)
后臺系統(tǒng)與前臺服務(wù)存在MQ和API調(diào)用接口，業(yè)務(wù)基本為狀態(tài)通知或后臺手工發(fā)起的修改操作棕叫，接口調(diào)用頻次低林螃，數(shù)據(jù)量較小。
后臺為雙中心主備架構(gòu)俺泣，當前未進行雙中心拆分疗认；前臺服務(wù)拆分后，cobar層仍支持跨中心寫伏钠，業(yè)務(wù)流程如下圖：
圖7前后臺數(shù)據(jù)同步流程
五横漏、有貨雙活架構(gòu)-容災(zāi)
支持中心級故障容災(zāi)，一切皆可故障：
圖8雙活架構(gòu)下分層故障切換
六熟掂、架構(gòu)落地中典型問題
1缎浇、訂單號生成
數(shù)據(jù)單元化后訂單號不能簡單使用數(shù)據(jù)庫序列，數(shù)據(jù)庫切換時可能導致數(shù)據(jù)沖突使得數(shù)據(jù)沖突赴肚。
業(yè)內(nèi)有較好的分布式id生成方案素跺，如UUID、snowflake算法等尊蚁；有貨現(xiàn)有訂單號使用全數(shù)據(jù)亡笑，長度較小，因此當前采用中心編號+uid分庫信息+數(shù)據(jù)庫序列號
2横朋、跨中心數(shù)據(jù)庫切換中數(shù)據(jù)同步問題
當故障發(fā)生需要將主庫切換到另一中心時仑乌，需要檢測數(shù)據(jù)同步是否完成；否則在切回時會出現(xiàn)數(shù)據(jù)丟失琴锭，這會造成故障時切換時間延長晰甚；根據(jù)雙中心間數(shù)據(jù)同步時延，一般會有幾十~100ms.
3决帖、數(shù)據(jù)庫切換后如何及時更新配置
有貨使用分布式數(shù)據(jù)中間件cobar進行數(shù)據(jù)主從和分庫分表厕九，在雙活架構(gòu)下，我們對cobar進行部分定制地回，數(shù)據(jù)庫配置放到配置中心扁远；配置中心支持subscribe/notify機制俊鱼，當數(shù)據(jù)庫切換時，修改配置中心中數(shù)據(jù)庫配置畅买，可以及時通知cobar更新配置并闲。
