国产一级a片免费看高清,亚洲熟女中文字幕在线视频,黄三级高清在线播放,免费黄色视频在线看

打開APP
userphoto
未登錄

開通VIP,暢享免費電子書等14項超值服

開通VIP
微博config service實踐

一.配置的那些事兒

1.業(yè)務(wù)背景

作為大型復雜分布式系統(tǒng),微博平臺中存在大量的配置信息,這些配置信息定義了平臺中的RPC服務(wù)和資源(memcached、redis、mysql等)的地址,以及這些服務(wù)和資源的元數(shù)據(jù)信息。

在微博早期,配置信息散落在工程的代碼中,這種方式簡單方便,但是微博平臺系統(tǒng)規(guī)模擴大和業(yè)務(wù)部署復雜度的提升帶來了一些問題:

  • 服務(wù)按照業(yè)務(wù)和重要程度部署在多個池子,不同池子的配置信息不同。
  • 服務(wù)多機房部署,不同機房的配置信息也不同。
  • 開發(fā)、測試以及上線部署的配置信息亦不同。

為了解決以上問題,微博平臺對配置做了一次大規(guī)模調(diào)整,將代碼和配置分離,配置按照機房、業(yè)務(wù)池以及環(huán)境拆分,并且存儲在本地文件系統(tǒng)中約定的位置。分離之后,各業(yè)務(wù)池、各機房的配置更加靈活,也為配置向 config service遷移提供了條件。

隨著微博平臺服務(wù)器規(guī)模的持續(xù)增長,RPC服務(wù)和資源的故障和變更已經(jīng)變?yōu)橐环N常態(tài),在日常維護過程中,經(jīng)常會遇到以下場景:

  • 某一組memcacheq資源突然流量猛增,需要快速擴容
  • 某一redis資源訪問過載,需要立即降級調(diào)用它的服務(wù)

而現(xiàn)有的解決方案無法解決這些問題,我們迫切需要一個分布式環(huán)境下的持久配置系統(tǒng),提供高效的配置注冊獲取和及時變更通知服務(wù),于是vintage(config service在微博內(nèi)部的代號)應運而生。

2.vintage

Vintage是典型的基于pub-sub模型的通訊框架,在業(yè)界類似的系統(tǒng)很多,比如淘寶的diamond和軟負載中心,zookeeper在某些系統(tǒng)中(如kafka)也扮演著類似的角色。

Vintage 將信息集中管理在云端,并且提供實時的變更通知。Vintage主要應用于兩種主要場景:配置管理和命名管理,配置管理主要維護靜態(tài)配置數(shù)據(jù)(如服務(wù)超時時間、降級開關(guān)狀態(tài));命名管理主要維護RPC服務(wù)地址信息。兩種場景看起來極為相似,但是也存在如下差別:

  1. 生命周期不同:命名服務(wù)需要管理服務(wù)的生命周期,實時探測服務(wù)的存活狀態(tài);配置服務(wù)主要管理靜態(tài)的信息。
  2. 數(shù)據(jù)產(chǎn)生方式不同:命名服務(wù)數(shù)據(jù)來源于服務(wù)的注冊;配置服務(wù)數(shù)據(jù)來源于OP手動添加。
  3. 數(shù)據(jù)精確度不同:命名服務(wù)數(shù)據(jù)可能會存在一定時間窗口內(nèi)的誤判(后面會提到);配置服務(wù)的數(shù)據(jù)會非常精確。

Vintage在微博平臺內(nèi)部已經(jīng)獲得了很大的推廣和使用,RPC service、cache service、分布式trace系統(tǒng)、queue service都在一定程度上依賴vintage,它的重要程度是不言而喻的。 那么如此重要的服務(wù)是如何設(shè)計的呢?

二.Vintage設(shè)計和架構(gòu)

1. 架構(gòu)設(shè)計

Vintage在設(shè)計之初就明確了以下的目標:

  1. 高可用:vintage管理著服務(wù)的地址和元數(shù)據(jù)信息,其本身的高可用性決定著系統(tǒng)整體成敗。
  2. 低延遲:微博平臺中每次調(diào)用理論上都會與vintage有一次或者多次的交互,因此vintage訪問延遲影響著系統(tǒng)整體的性能。
  3. 時效性:對于變更及時響應和通知

vintage選擇redis作為配置信息的落地存儲,結(jié)構(gòu)簡單,無單點,具體如下圖所示:

2. 容災機制

vintage以高可用性為設(shè)計根本,我們在容災機制上投入了很大的精力。配置數(shù)據(jù)存儲在redis、服務(wù)端緩存、客戶端snapshot文件中,在多種故障場景下,vintage均能輕松應付:

  1. redis主庫crash,可以迅速切換到從庫,繼續(xù)提供服務(wù)
  2. redis主庫和從庫同時crash,服務(wù)端的內(nèi)存緩存可以保證vintage服務(wù)正常運行。
  3. vintage服務(wù)端全部不可用,客戶端本地snapshot文件也可以提供服務(wù),只是變更通知功能將失效。

由此可知,只有在服務(wù)端redis、tomcat全部不可用,客戶端的snapshot文件被刪除或者損壞的情況下,客戶端應用才會無法從vintage獲取配置信息,導致服務(wù)不可用,這種場景出現(xiàn)的幾率極低。

3.變更通知

vintage相比于本地文件系統(tǒng)保存配置信息最大的優(yōu)勢就在于可以對配置變更的實時通知。實現(xiàn)變更通知最直觀的做法就是客戶端定期查詢配置信息,但是這種方式存在很多問題。

首先,配置信息在redis中以hash格式存儲,對信息的每次全量獲取都是一次hgetall操作,這個操作會極大的增加redis負載,降低吞吐量。

其次,vintage對應的客戶端很多,其本身存儲的數(shù)據(jù)量也很大,大量的全量獲取會壓滿網(wǎng)卡。

vintage的解決方案是這樣的:

vintage中除了存儲配置信息以外還會存儲信息的MD5碼,同時配置信息和MD5碼也會緩存在客戶端??蛻舳藨冒l(fā)起的每次查詢操作實際上只是查詢客戶端緩存中信息。而vintage client會定期的訪問server獲得最新的MD5碼與本地緩存的MD5比對,如果發(fā)生變化才會從server獲得最新的信息,并且緩存在客戶端緩存和snapshot文件中。具體流程如下圖所示:

4.服務(wù)生命周期

之前提到,vintage的命名管理功能主要維護的是RPC服務(wù)的地址信息,這些信息是有生命周期的,生命周期狀態(tài)有三個:working、unreachable和removed,狀態(tài)變更圖如下:

其中,服務(wù)生命周期中的 working態(tài)和unreachable態(tài)的變化是通過RPC server和config service之間的心跳完成的,心跳時間戳也是存儲在redis中。每臺應用服務(wù)器中存在心跳接收器(heartbeat acceptor)異步寫入心跳時間戳,同時存在一個心跳處理器(heartbeat processor)定期的檢查心跳是否出現(xiàn)連續(xù)缺失。具體流程如下圖所示:

心跳服務(wù)對于命名服務(wù)來說至關(guān)重要,直接影響著服務(wù)的生命周期變化,在實際應用過程中,需要注意一下幾點:

  1. heartbeat acceptor和heartbeat processor所做操作均是異步的,需要實時的監(jiān)控線程池中的任務(wù)堆積情況,以免任務(wù)堆積后導致heartbeat寫入不實時造成服務(wù)狀態(tài)誤判。
  2. 微博平臺使用的RPC server可以在單個實例內(nèi)跑不同的服務(wù),heartbeat aggregator會把所有服務(wù)的心跳數(shù)據(jù)收集起來進行壓縮傳輸,減少了帶寬消耗。
  3. 優(yōu)化redis連接池,避免heartbeat acceptor對redis的集中寫入導致寫入失敗。

三.遇到的問題

vintage在設(shè)計上非常簡單,代碼量也不是很大,但是在實際使用中還是遇到各種各樣的問題,以下針對幾個典型問題和大家分享以下。

1.節(jié)點狀態(tài)誤判

vintage接受來自所管理的RPC服務(wù)的心跳信息,并且根據(jù)配置的策略判斷RPC服務(wù)是否存活。那么在不考慮心跳包在傳輸過程中被篡改的前提下(Byzantine Generals Problem),只會出現(xiàn)兩種情況:

  1. vintage正確判斷RPC服務(wù)節(jié)點狀態(tài)。
  2. RPC服務(wù)節(jié)點存活,但是由于傳輸信道的不可靠導致vintage沒有接收到心跳消息,從而導致vintage對于節(jié)點狀態(tài)的誤判(Two Generals Problem)。

如果第二種情況發(fā)生會產(chǎn)生非常嚴重的后果,極端情況下會vintage會摘除所有的RPC服務(wù)節(jié)點,導致服務(wù)整體不可用。負載中心類型的產(chǎn)品通常都會遇到這樣的問題,vintage是如何解決的呢?

首先,vintage不會摘除心跳檢測中標志死亡的節(jié)點,只是把它標記為不可達的狀態(tài)(unreachable);而對于不可達節(jié)點的使用,vintage client中提供多種策略,由應用方來選擇是否使用以及如何使用不可達節(jié)點。

其次,vintage會保護服務(wù)節(jié)點,控制心跳檢測中標示不可達節(jié)點的數(shù)量,避免某一個服務(wù)集群的所有節(jié)點被標志為不可達。

2.變更“風暴”

之前提到引用方使用的信息實際上時存儲在vintage client的本地緩存中,那么當應用方重啟(如進行上線)或者信息發(fā)生變更時,vintage client的本地緩存失效,大量的請求會穿透到vintage server以及redis中,造成系統(tǒng)瞬時負載和網(wǎng)卡流量的暴漲,我們稱之為變更“風暴”。變更風暴對于vintage來說是致命的,因為應用方只有在此時會和vintage server交互,如果vintage server crash,會造成對vintage強依賴的應用方永遠無法啟動。

我們的應對方案如下:

  1. vintage server增加hot local cache,降低風暴過程中大量的對于同一組配置信息的請求穿透到redis中。
  2. vintage client增加本地文件的緩存,在應用系統(tǒng)啟動時使用文件中存儲的信息預熱內(nèi)存緩存。
  3. 壓縮vintage中存儲的信息,降低風暴對于網(wǎng)卡的壓力。

四.結(jié)束語

vintage在微博系統(tǒng)架構(gòu)層面發(fā)揮的作用是不言而喻的,它增強了微博架構(gòu)的魯棒性,使各個業(yè)務(wù)系統(tǒng)可以進行快速地變更、降級、切換流量,它是微博架構(gòu)從稚嫩走向成熟的標示。


感謝崔康對本文的審校。

本站僅提供存儲服務(wù),所有內(nèi)容均由用戶發(fā)布,如發(fā)現(xiàn)有害或侵權(quán)內(nèi)容,請點擊舉報。
打開APP,閱讀全文并永久保存 查看更多類似文章
猜你喜歡
類似文章
Jboot 1.0
如何設(shè)計一個小而美的秒殺系統(tǒng)(搶紅包)?
如何在 Istio 中支持 Dubbo、Thrift、Redis 以及任何七層協(xié)議?
SpringBoot中引入Ehcache3.x
微服務(wù)架構(gòu)下的核心話題 (三):微服務(wù)架構(gòu)的技術(shù)選型
分布式鎖如何實現(xiàn)
更多類似文章 >>
生活服務(wù)
分享 收藏 導長圖 關(guān)注 下載文章
綁定賬號成功
后續(xù)可登錄賬號暢享VIP特權(quán)!
如果VIP功能使用有故障,
可點擊這里聯(lián)系客服!

聯(lián)系客服