會員服務在高可用架構的實戰探索
概述
▌高可用的方案
網路層 | 多區域,多出口,出口有互備和切換的能力 | 根據目前的CDN結構,將地域劃分為北方,華中,華南,海外四個區域,每個區域支援主流運營商,保證流量均衡 |
應用層 | 多機房部署,相互獨立 | 到少保證兩個機房互備,實現基礎架構兩地三中心的戰略規劃 |
儲存層 | 多例項,可以指定切換方向 | Mysql/Redis都可以自動將故障的例項下線 |
訊息層 | 統一使用RMQ | RMQ支援高可用,可能自動備切,將amq替換為rmq |
監控層 | 監控DNS,應用,資料庫等例項,進行資料修復 | 提供監控功能,監控結點覆蓋資料庫和網路層,異常時,報警和切換。提供資料處理工具。 |
▌升級網路架構
1.運營商出口的互備
系統網路部門研發了域名,LB的運維管理平臺,支援故障監測,業務異常時切換到備用資源,變更配置時進行通知。會員在使用過程中,提出了很多最佳化需求,如展示IP的地域和運營商資訊,提升使用者體驗,目前部署了三套獨立的出口IP,相互之間可以在網路層隔離和自動切換。因為資料庫的主庫暫時無法多機房部署,所以訂單、權益等核心服務和資料庫保持同城部署。目前在同城機房部署了兩套出口IP,可以進行互備和自動切換。
使用者訪問最近的機房總是最快的,會員將DNS區域劃分出北方,華中,華南三個獨立的區域進行部署,設定獨立的出口IP,區域劃分上也保證了流量的均衡。網路組提供自動化的運維設施,透過故障演練,已經可以在故障時進行流量的自動切換。
在人員方面,邀請網路部門專業人員對會員團隊進行網路基礎架構和網路保障方案等的講解,對過往故障進行整體分析總結,並一起對業務災備方案做出調整。透過大家的共同努力,近一年來將業務故障率降為零。
2.內網IDC機房的互備
各機房透過專線互連互通。應用的部署與上下游的服務保持在同一個機房最佳,不佔用專線頻寬,提升服務穩定性,減少網路抖動和晚高峰的影響。在統計了應用的上下游的流量分佈之後,應用在部署上覆蓋了主要的機房,將最早的自建機房定義為備用機房。當主機房故障時,DNS系統透過定時檢測,發現異常後會自動切換到備用機房。內網服務間東西向流量是很大的,高峰時直接切換到另一個機房可能會引起機房不穩定,所以每個服務從Nginx層配置了應用級別的限流。極端情況下的流量監控和限流成為保障服務安全穩定的最後屏障。流量可以在機房間進行切換,如果流量超過機房承載能力,會觸發限流和報警。
▌升級應用服務
1.改造單點的應用
部分應用如worker一般都存在單點的情況,將應用改造成可以部署在多個IDC中,形成多個互備的叢集。Worker一般會執行定時任務,透過改造定時任務,並使用了開源專案xxl-job,開發出了非同步任務框架和排程系統(vip-job),定時任務由排程系統觸發,隨機選擇一臺伺服器進行任務排程,解決了單點問題。
2.核心應用多機房部署
核心服務(如會員影片播放鏈路上的應用)會覆蓋儘量多的IDC,期望流量在同機房流轉,保證服務質量,同時核心應用的DNS配置根據地域和運營商兩個維度進行最佳化,給使用者提供最優的服務體驗。
3.升級資料庫
公司的資料庫部署架構為DNS+HA。透過實現Raft協議,開發了HA-Master/HA-Agent監控和切換軟體。當資料庫例項當機時,agent會傳送心跳檢查,觸發主備切換或是將當機例項從DNS中下線,避免人工運維成本和當機帶來的資料丟失。
▌訊息中介軟體和Redis的高可用
會員使用服務雲提供的RocketMQ,申請支援跨機房互備。
將ActiveMQ和歷史不支援HA的RocketMQ進行替換和升級以支援互備。
Redis使用Sentinal機制進行主備切換。兩者都具備HA的能力,使用起來比較方便。
1.會員應用的部署架構
會員將目前的機房進行了抽象和劃分,自建的核心機房可以承載所有的流量,部署了會員全套的應用。租賃機房存在擴容困難,機器折舊,流量單一,應用覆蓋不全的問題。將租賃機房劃分成一個整體,抽象成一個虛擬機器房,從外部看,虛擬機器房和自建機房一樣,支援多運營商,容量大,應用覆蓋全面,可以提供高質量的服務。目前會員實現的是自建機房與虛擬機器房的互備。
2.運維平臺
會員打通了從DNS到虛擬機器的資源資訊,開發了運維平臺,建立了一系列的監控指標和運維工具。為機房之間業務切換和日常運維提供支撐服務和工具,架構如圖所示:
▌砥礪前行與未來展望
會員服務的高可用方案隨著公司的網路與計算設施部門的工作進展而不斷最佳化升級,基礎設施部門提供了更多的能力和服務,方案也更整潔和強大。未來的重點將放在提升資源利用率,最佳化會員服務,同時保證業務的故障恢復在使用者無感知的情況下進行。
來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/69945252/viewspace-2671318/,如需轉載,請註明出處,否則將追究法律責任。
相關文章
- 用 Hystrix 構建高可用服務架構架構
- 高可用架構之高可用的應用和服務架構
- MySQL資料庫實現高可用架構之MHA的實戰MySql資料庫架構
- Redis高可用之戰:主從架構Redis架構
- 高可用架構架構
- MHA高可用架構的實現方式架構
- Keepalived實現服務高可用
- Redis 高可用架構最佳實踐Redis架構
- Oracle 高可用架構Oracle架構
- MySQL 實現高可用架構之 MHAMySql架構
- MySQL高可用架構之MHA實踐MySql架構
- MySQL高可用架構之PXC實踐MySql架構
- 構建高併發高可用的電商平臺架構實踐架構
- MySQL 高可用架構之 MMM 架構MySql架構
- MySQL資料庫各場景主從高可用架構實戰MySql資料庫架構
- Canal高可用架構部署架構
- 【Redis】Sentinel 高可用架構Redis架構
- Redis Sentinel高可用架構Redis架構
- Oracle高可用架構(MAA)Oracle架構
- Mysql高可用架構方案MySql架構
- 高可用服務之Keepalived利用指令碼實現服務的可用性檢測指令碼
- Twitter 高併發高可用架構架構
- 分散式服務高可用實現:複製分散式
- MySQL高可用架構之MaxScale實踐MySql架構
- 基於 RocketMQ 的 MQTT 服務架構在小米的實踐MQQT架構
- 構建MHA實現MySQL高可用叢集架構MySql架構
- 微服務業務架構的探索微服務架構
- 來自 Google 的高可用架構理念與實踐Go架構
- 如何用3臺機器輕鬆搭建一個高可用Redis服務架構?Redis架構
- 挑戰 - 微服務架構下的服務端測試微服務架構服務端
- WEB叢集- 高可用服務Web
- 乾淨架構在 Web 服務開發中的實踐架構Web
- MySQL高可用架構對比MySql架構
- AWS 高可用AWS架構方案架構
- mysql高可用架構MHA搭建MySql架構
- Keepalived 架構高可用 Mysql架構MySql
- mysql MHA 高可用架構部署MySql架構
- 遊戲服務端的高併發和高可用遊戲服務端