建站
咨詢
售后
建站咨詢
新聞中心
大家好，我是騰訊微服務平臺TSF 產(chǎn)品經(jīng)理劉閻，目前主要負責TSF高可用能力建設及演進規(guī)劃工作，本次分享我會結合自己對微服務架構的理解以及TSF在高可用能力建設上的最佳實踐與大家共同討論如何構建高可用的微服務架構。
創(chuàng)新互聯(lián)建站專注于豐臺企業(yè)網(wǎng)站建設,成都響應式網(wǎng)站建設公司,商城建設。豐臺網(wǎng)站建設公司,為豐臺等地區(qū)提供建站服務。全流程按需求定制開發(fā)，專業(yè)設計，全程項目跟蹤，創(chuàng)新互聯(lián)建站專業(yè)和態(tài)度為您提供的服務
微服務架構挑戰(zhàn)
軟件架構的演進歷程
首先我們先來看下軟件架構的演進歷程：
單體架構：沒有復雜邏輯分層，前后代碼耦合，單個應用可能與多個數(shù)據(jù)庫關聯(lián)
適用于：迭代頻率低，并發(fā)量小，業(yè)務邏輯簡單的應用場景，目前單體架構在政府、金融、工業(yè)領域仍有廣泛應用。
SOA架構：按業(yè)務邏輯進行服務拆分，服務間通過服務總線進行服務管理及流量轉發(fā)
其主要問題在于：服務總線成為系統(tǒng)新的瓶頸，難以伴隨業(yè)務的不斷發(fā)展?jié)M足線性擴容的要求。
微服務架構：服務架構通過服務注冊中心實現(xiàn)服務注冊發(fā)現(xiàn)，服務啟動時將服務實例注冊到注冊中心，調(diào)用方在發(fā)起調(diào)用時通過注冊中心進行服務尋址，直接與提供方進行通信。理論上服務可以伴隨業(yè)務發(fā)展實現(xiàn)線性擴展，不同服務之間可單獨迭代，實現(xiàn)敏捷開發(fā)。
服務網(wǎng)格：版本云原生k8s及容器技術發(fā)展，服務網(wǎng)格技術已趨于成熟，相較于傳統(tǒng)的微服務架構，服務網(wǎng)格通過sidercar模式進行流量代理和服務注冊發(fā)現(xiàn)，無需業(yè)務感知，輕松實現(xiàn)跨語言服務治理，幫助業(yè)務快速遷移，使業(yè)務應用更加專注自身業(yè)務邏輯實現(xiàn)。
每種軟件架構沒有嚴格意義上的好壞之分，用戶需要根據(jù)自身的業(yè)務特點進行架構選型。
微服務應用常見問題
微服務架構在滿足高并發(fā)、敏捷迭代的同時，業(yè)務模塊數(shù)量成幾何數(shù)增長，給應用運維帶來了嚴峻挑戰(zhàn)，微服務架構相較于傳統(tǒng)單體架構，具有流量洪峰激增、模塊依賴復雜、故障定位難度大、故障恢復耗時長的特點。
- 流量激增：單體應用拆分為微服務應用后，原有的單一請求邏輯拆分為多個微服務應用的組合業(yè)務邏輯，接口調(diào)用量成1:N的增長關系，面對流量洪峰，接口調(diào)用量激增。
- 模塊依賴復雜：原有的單體應用僅存在單一進程內(nèi)的業(yè)務邏輯組合，微服務應用拆分為多個進程，各模塊間的服務上下游依賴關系復雜，單個微服務或單個接口異常通常引發(fā)鏈式反應，造成服務雪崩。
- 故障定位難度大：單次請求異常需要依據(jù)各模塊的依賴關系分析整個調(diào)用鏈路定位故障原因，由于橫跨多個微服務應用進程的不同業(yè)務邏輯，故障定位難度陡增。
- 故障恢復耗時長：由于各微服務模塊依賴關系復雜，需要根據(jù)調(diào)用鏈準確定位故障問題根源并進行逐級恢復，故障恢復及恢復后驗證評價結果耗時長。
如何度量系統(tǒng)可用性指標
管理學大師彼得德魯克曾說“你如果無法度量它，就無法管理它”(“It you can’t measure it, you can’t manage it”)。要想有效管理，就難以繞開度量的問題。
那如何度量分布式系統(tǒng)的可用性指標呢，這里有一個簡單公式，可用性=平均故障間隔時間/平均故障間隔時間與平均故障恢復時間之和。
所謂平均故障間隔時間是指相鄰兩次故障之間的平均工作時間，也稱為平均故障間隔。平均修復時間是從出現(xiàn)故障到修復中間的這段時間。MTTR 越短表示易恢復性越好。
MTBF：即平均故障間隔時間，英文全稱是“Mean Time Between Failure”。是衡量一個產(chǎn)品（尤其是電器產(chǎn)品）的可靠性指標。單位為“小時”。
MTTR：全稱是 Mean Time To Repair，即平均修復時間。是指可修復產(chǎn)品的平均修復時間，就是從出現(xiàn)故障到修復中間的這段時間。MTTR 越短表示易恢復性越好。
高可用架構設計的道、法、術
那如何設計高可用的微服務架構呢？接下來我將分別從道、法、術三個層面講高可用微服務架構設計的基本原理、架構設計原則、以及高可用架構常用的解決方法。
道：從CAP到BASE
CAP 理論：在一個分布式系統(tǒng)中， 一致性（C：Consistency）、可用性（A：Availability） 和 分區(qū)容忍性（P：Partition Tolerance），最多只能同時滿足其中兩項。其中分區(qū)容忍性（P：Partition Tolerance）是復雜網(wǎng)絡環(huán)境下的必須要素，因此分布式系統(tǒng)的架構設計需要在一致性和可用性之間進行取舍。就誕生了諸如：Paxos 算法 和 Raft 算法強一致性共識算法，以及2階段提交，3階段提交的最終一致性算法。
BASE 理論：BASE是對 CAP 中一致性和可用性權衡的結果，它的理論的核心思想是：即使無法做到強一致性，但每個應用都可以根據(jù)自身業(yè)務特點，采用適當?shù)姆绞絹硎瓜到y(tǒng)達到最終一致性。
法：微服務高可用架構設計原則
結合我對微服務高可用架構的理解，總結出以下6點高可用架構設計的原則，分別是服務無狀態(tài)、異步解耦、分區(qū)容錯、故障隔離、快速恢復、最終一致性：
服務無狀態(tài)：服務應用進行無狀態(tài)設計，將服務應用的狀態(tài)數(shù)據(jù)通過緩存、數(shù)據(jù)庫進行集中存儲，通過nginx或網(wǎng)關進行負載均衡實現(xiàn)水平擴展。
異步解耦：各服務模塊通過發(fā)布訂閱、事件驅動方式進行異步解耦，單次請求調(diào)用通過異步回調(diào)方式快速響應，將通知事件與處理結果分離，避免異常雪崩。
分區(qū)容錯：基于指定的業(yè)務規(guī)則實現(xiàn)業(yè)務分流路由，將流量分發(fā)至多個可用區(qū)，不同可用區(qū)通過數(shù)據(jù)同步、多備份機制保障數(shù)據(jù)一致性。
故障隔離：單一進程、單一接口、單一服務通過熔斷、降級機制實現(xiàn)故障隔離，避免系統(tǒng)關聯(lián)異常，引發(fā)雪崩效應。
快速恢復：通過流量切分，版本管理、應用回滾機制實現(xiàn)應用快速回退至健康版本，快速恢復應用。
最終一致性：通過多數(shù)據(jù)源雙寫、數(shù)據(jù)稽核、數(shù)據(jù)修復實現(xiàn)數(shù)據(jù)跨可用區(qū)數(shù)據(jù)最終一致性。
術：高可用常用手段
分區(qū)容錯：
異地容災是高可用架構典型的應用場景，通過將不同地域的數(shù)據(jù)中心構建多套應用服務，當單一地域服務宕機時可快速通過流量切換災備中心保障業(yè)務持續(xù)、穩(wěn)定。異地容災按保障級別不同分為，多可用區(qū)、同城冷備、同城雙活、異地冷備、兩地三中心五個級別，其保障級別、應用成本、恢復延遲都呈遞增趨勢。
異步解耦：
在微服務應用中通過引入消息中間件將上游組合服務對下游多個微服務的同步調(diào)用進行異步解耦，基于消息的可靠投遞能力快速響應用戶請求，能夠大幅提升服務并發(fā)訪問性能及用戶體驗，并通過數(shù)據(jù)補償手段保障數(shù)據(jù)最終一致性。
服務限流：
由于 API 接口無法控制調(diào)用方的行為，因此當遇到瞬時請求量激增時，會導致接口占用過多服務器資源，使得其他請求響應速度降低或是超時，嚴重導致服務器宕機。服務限流主要是保護服務節(jié)點或者數(shù)據(jù)節(jié)點，防止瞬時流量過大造成服務和數(shù)據(jù)崩潰，導致服務不可用。
局部限流：基于簡單計數(shù)、令牌桶、漏斗算法在單個節(jié)點內(nèi)的限流，僅能限制傳入此節(jié)點的請求，無需引入中間件，通過局部限流達到全局限流的目的，同時避免實例級別單一接口訪問量激增問題
全局限流：基于簡單計數(shù)、令牌桶算法，通過引入中間件如redis，針對整個集群流量進行全局控制。
服務熔斷：
服務熔斷是應對服務異常，實現(xiàn)服務容錯，避免服務雪崩的有效手段。
從下圖中可以看出，當網(wǎng)關入口服務請求下游多個服務接口，當服務C接口異常將導致入口服務流量的不可用，服務A、服務E請求則白白占用。
從下圖中可以看出，當網(wǎng)關入口的服務請求下游的單一服務接口，當服務B接口異常將導致入口請求夯住，占用網(wǎng)關請求資源，導致整體業(yè)務異常。
針對以上兩種異常場景，通過在服務調(diào)用時配置熔斷策略能夠快速失敗，直接反饋上游業(yè)務異常結果，避免請求線程夯死及服務雪崩。
降級容錯：
服務降級是在服務器壓力陡增的情況下，利用有限資源，根據(jù)當前業(yè)務情況，關閉某些服務接口或者頁面，以此釋放服務器資源以保證核心服務的正常運行。
TSF高可用最佳實踐
TSF微服務平臺針對業(yè)務流量激增、服務異常容錯等問題提供架構容災、灰度發(fā)布、服務容錯兜底、實例優(yōu)雅啟停、應用性能管理的一體化高可用服務架構。突出立體化、自動化、可視化的優(yōu)勢，提供端到端的應用性能監(jiān)控，多維度可視化的運行監(jiān)控數(shù)據(jù)聚合分析，實現(xiàn)故障自動感知，自動處理，快速恢復故障業(yè)務，保障系統(tǒng)的穩(wěn)定高效運行。
單元化架構部署
單元化架構是一種高級的高可用架構設計模式，通過對核心業(yè)務數(shù)據(jù)分片，應用服務無狀態(tài)設計將相同領域的業(yè)務服務劃分為一個個獨立的部署單元，單元內(nèi)整體業(yè)務閉環(huán)。通過單元化部署架構能夠有效滿足彈性伸縮，故障隔離，異地容災等高可用建設要求。此外基于單元化部署可以實現(xiàn)以部署單元為基準，構建靈活的發(fā)布策略。
單元化架構產(chǎn)品能力：
- 網(wǎng)關業(yè)務單元路由標簽
- 支持跨單元橫向調(diào)用
- 單元內(nèi)服務容錯兜底
彈性伸縮
通過配置動態(tài)伸縮規(guī)則，TSF中控服務基于agent上報的監(jiān)控數(shù)據(jù)實現(xiàn)實時統(tǒng)計，滿足流量激增自動擴容或流量低峰自動縮容能力，有效保障服務高效穩(wěn)定及資源利用率提升。
全鏈路灰度發(fā)布
灰度發(fā)布是將具有一定特征或者比例的流量分配到需要被驗證的版本中，用來觀察新的驗證版本的線上運行狀態(tài)。相比全量上線，灰度發(fā)布是更加謹慎的發(fā)布形式。當線上調(diào)用鏈路較為復雜時，全鏈路灰度發(fā)布可以將線上的各個服務隔離出一個單獨的運行環(huán)境。
全鏈路灰度產(chǎn)品能力：
- 基于業(yè)務級別的全鏈路灰度發(fā)布能力
- 支持按照業(yè)務級別請求參數(shù)對流量進行劃撥
- 泳道間流量隔離
優(yōu)雅啟停
在應用滾動發(fā)布過程中，可以通過調(diào)整部署組滾動發(fā)布更新策略達到服務優(yōu)雅下線，降低發(fā)布過程中業(yè)務中斷影響。
這里簡單介紹優(yōu)雅下線的簡單流程
- 下線實例在注冊中心進行反注冊，注銷該實例注冊信息；
- 注冊中心節(jié)點訂閱更新周期為15s，調(diào)用方在感知注冊中心實例變更后，更新本地緩存服務地址，不再將流量路由到下線實例，期間保障業(yè)務無中斷；
- 下線實例等待30s（2個心跳周期）后進行實際下線操作；
優(yōu)雅啟停產(chǎn)品能力：
- 支持容器、虛機部署方式
- 實例反注冊下線事件詳情
- 實例啟動就緒檢測
服務限流
TSF 限流基于監(jiān)控服務流量的 QPS 指標，當達到指定的閾值時進行流量控制，避免被瞬時高峰流量沖垮，從而確保服務的高可用。支持在網(wǎng)關配置全局限流策略保障入口服務流量穩(wěn)定支持針對單一服務配置局部限流策略保障當前服務流量穩(wěn)定，同時提供靈活的限流規(guī)則配置及動態(tài)生效，提供可視化的限流操作及監(jiān)控數(shù)據(jù)展示。
服務熔斷
TSF服務熔斷能力支持服務、實例、API多維度的熔斷隔離級別，提供控制臺可視化配置及熔斷事件展示，滿足熔斷配置熱生效需求。
熔斷器狀態(tài)轉換：
熔斷器開始處于closed狀態(tài)，一旦檢測到錯誤（或慢響應）達到一定閾值，便轉為open狀態(tài)，此時不再調(diào)用下游目標服務。
一段時間后轉化為half open狀態(tài)，嘗試放行一部分請求到下游服務。
一旦檢測到響應成功，回歸到closed狀態(tài)，也即恢復服務；否則回到open狀態(tài)。
健康檢查與注冊中心聯(lián)動流程
健康檢查分為存活檢查及就緒檢查；存活檢查主要作用是確定進程存活狀態(tài)，判斷是否需要進行實例重啟。就緒檢查主要作用是確定服務實例能否支持對外服務，將健康檢查結果與注冊中心狀態(tài)聯(lián)動避免流量接入異常節(jié)點。
健康檢查與注冊中心聯(lián)動流程
1.就緒檢查，檢查實例狀態(tài)是否ready
2.如果就緒檢查ready則更新實例注冊狀態(tài)為passing，反之則檢查狀態(tài)為cirtical
3.監(jiān)聽注冊中心服務提供方實例狀態(tài)變更
4.存在狀態(tài)變更更新緩存及本地文件
5.發(fā)起服務調(diào)用
- 健康檢查產(chǎn)品能力：
- 存活檢查
- 就緒檢查
- 多種探測方式：http，tcp，執(zhí)行命令
- 支持虛機&容器部署
應用性能管理能力
最后我們從一個問題排查流程全局展示tsf應用性能管理能力：
- 用戶收到監(jiān)控平臺發(fā)送的告警信息，確定異?；拘畔ⅰ?/li>
- 通過服務依賴拓撲確定異常服務的上下游依賴關系，進行全局視圖分析。
- 接下來可以服務接口調(diào)用情況確定是全局接口異?；蚴菃我唤涌诋惓?。
- 如果是全局接口異常說明服務提供方服務實例存在異常問題，找到對應的異常實例通過日志檢索或JVM監(jiān)控分析排查具體問題；如果是單一接口異常說明提供方接口邏輯處理，通過日志檢索可排查具體問題。
- 當然也可以在全局視圖分析后通過對直接服務進行調(diào)用鏈分析排查單筆請求的調(diào)用鏈路，通過調(diào)用鏈與日志聯(lián)動排查具體異常。
新聞名稱：服務器又崩了？深度解析高可用架構的挑戰(zhàn)和實踐
文章URL：http://www.5511xx.com/article/djshdie.html
