1. 服務(wù)發(fā)現(xiàn)模式

第一個(gè)就是服務(wù)發(fā)現(xiàn)的模式，服務(wù)發(fā)現(xiàn)里面其實(shí)有兩種模式(邊車模式，Sidecar暫時(shí)范圍不是很廣)，這兩種模式對(duì)應(yīng)不同的適用場(chǎng)景會(huì)有不同的效果。

圖片

直聯(lián)模式，客戶端從注冊(cè)中心發(fā)現(xiàn)服務(wù)端的列表并緩存在本地，這種模式適合于語言統(tǒng)一的這種內(nèi)網(wǎng)通信，為什么呢？因?yàn)橹边B模式里面大部分 RPC 采用的這樣的模式，主要是比較簡(jiǎn)單、高效，而且在統(tǒng)一語言的內(nèi)網(wǎng)通信里面，這種服務(wù)端的實(shí)例的變更通知是比較簡(jiǎn)單的。

圖片

代理模式，服務(wù)端注冊(cè)到網(wǎng)關(guān)上，客戶端對(duì)一個(gè)服務(wù)端其實(shí)是無感知的，這種模式比較適合于外網(wǎng)服務(wù),因?yàn)楫?dāng)你的服務(wù)端變更的時(shí)候，客戶端其實(shí)是不需要去感知，也不需要對(duì)此進(jìn)行任何變更，這樣對(duì)外網(wǎng)來說，其實(shí)用戶側(cè)的設(shè)備是不需要去關(guān)注信息的，這樣通知起來就比較簡(jiǎn)單。但是它也會(huì)面臨一個(gè)問題，它會(huì)多一條的通信，從性能或者效率上來說，肯定是不如直連模式的。

2. 服務(wù)通信模式

服務(wù)通信模式里面主要有兩種，大家其實(shí)日常里面比較經(jīng)常會(huì)碰到就是同步的編程模式，這種模式比較簡(jiǎn)單易懂，非常符合人類的思考習(xí)慣，它比較適用于時(shí)間比較敏感的、吞吐量也比較小的這種場(chǎng)景。但是這種通信的方式在吞吐量比較大、QPS 比較高的場(chǎng)景里面就會(huì)有一系列的問題，比如說可能會(huì)把你的資源耗盡，但其實(shí)這些資源都處于等待中。比如我們?cè)?Java 里面可能會(huì)有線程池的資源，使用起來其實(shí)是比較低效的。然后在異步的這種場(chǎng)景里面，它其實(shí)比較適用于高吞吐、削峰填谷的作用。

其實(shí)這里面會(huì)有幾種，從我們的實(shí)踐上來看的話，比如說搜索系統(tǒng)它其實(shí)是一個(gè)非常高并發(fā)的場(chǎng)景，其實(shí)對(duì)于這種高吞吐的場(chǎng)景下是必須要用異步的，不然的話其實(shí)資源的損耗是非常高的，我們?cè)谀承┫到y(tǒng)上做過改造，由原來的同步改為異步的話，基本上可以節(jié)省掉 80% 左右的機(jī)器的資源。除此之外，交易系統(tǒng)的事件驅(qū)動(dòng)也是比較適合異步的一個(gè)場(chǎng)景，因?yàn)榻灰紫到y(tǒng)的事件其實(shí)是非常關(guān)鍵的，但是它又不能每個(gè)人都去通知，因?yàn)楹芏嗳硕夹枰P(guān)注這個(gè)事件，這個(gè)時(shí)候利用 MQ 等方式去做這種事件的驅(qū)動(dòng)是比較合適的。

圖片

3. 設(shè)計(jì)模式

從設(shè)計(jì)模式上來說的話，我們其實(shí)可以知道在互聯(lián)網(wǎng)的架構(gòu)里面，特別是在高并發(fā)的模式里面，我們有很多折中，這些折中里面其實(shí)會(huì)有不同的模式和它的沉淀。比如說像 BASE 這樣的模式，它其實(shí)不追求強(qiáng)一致性，它是有這種基本的可用和軟狀態(tài)這樣的優(yōu)點(diǎn)，進(jìn)而去避免因?yàn)閺?qiáng)一致導(dǎo)致的其他的不可用性。

圖片

第二個(gè)就是 CQRS，這個(gè)模式其實(shí)非常有用，至少我發(fā)現(xiàn)很多場(chǎng)景是能夠用上它的，換句話說其實(shí)只要是數(shù)據(jù)異構(gòu)的這種場(chǎng)景，都是比較適合去使用它的，當(dāng)然這取決于你的查詢模式。大家都知道查詢模式其實(shí)有很多種的，比如說像 KV 的查詢模式、復(fù)雜條件的 Query，除此之外，還有 Scan 這種掃描形式，不同的查詢形式會(huì)對(duì)應(yīng)著不同的存儲(chǔ)結(jié)構(gòu)是比較合適的。但是我們?cè)趯?duì)這些數(shù)據(jù)進(jìn)行操作的時(shí)候，其實(shí)它的數(shù)據(jù)載體是唯一的，那這個(gè)數(shù)據(jù)載體怎么樣才能支持多種的查詢模式呢？其實(shí)這里面就需要對(duì)這些數(shù)據(jù)進(jìn)行異構(gòu)，比如說像我們的訂單、配置等等這些方式都需要去進(jìn)行一定的異構(gòu)。

服務(wù)治理實(shí)踐

常見的服務(wù)治理的四板斧是:

1. 常規(guī)四板斧

圖片

不可避免地，第一，我們一定要設(shè)置超時(shí)；第二，要在一些場(chǎng)景里面去考慮重試的邏輯；第三，考慮熔斷的邏輯，不要被下游拖死；第四，一定要有限流的邏輯，不要被上游打死。

2. 最終目標(biāo)

圖片

穩(wěn)定可用指的就是我們通過各類的防控手段去達(dá)到在可用的容量場(chǎng)景下，提供有效的服務(wù)，這樣才能叫穩(wěn)定可用。第二個(gè)可觀測(cè)，就是我們從多個(gè)維度，比如說像關(guān)系、性能、異常、資源等維度對(duì)它進(jìn)行度量并且分析。第三個(gè)防腐化，我們的代碼和架構(gòu)其實(shí)不可避免地都是在腐化的一個(gè)過程之中，我們不停地往里面去添加?xùn)|西的過程中，其實(shí)也會(huì)缺乏一定的治理。我們服務(wù)治理的目標(biāo)，其中一點(diǎn)就是要做到如何去對(duì)它進(jìn)行防腐，這個(gè)里面有一些考慮的維度，比如服務(wù)的層級(jí)，你的服務(wù)并不是越微越好，也不是層級(jí)越多越好，所以服務(wù)的層級(jí)一定要有所控制。

3. 保護(hù)機(jī)制

第二就是鏈路的分析，鏈路里面上下游的超時(shí)、串行、并行的調(diào)用等等之類的這些東西在編碼的過程中可能會(huì)被忽略掉的，這些我們其實(shí)可以通過偏后置一點(diǎn)的方式對(duì)它進(jìn)行一個(gè)分析和預(yù)警，這里面提一下我們?cè)诒Ｗo(hù)機(jī)制上做的一些工作，我們都知道在 RPC 的框架里面，其實(shí)特別是在直連的模式下，調(diào)用端 Consumer 端和 Provider 端其實(shí)是直連通信的。

對(duì)于注冊(cè)中心來說，它只負(fù)責(zé)一個(gè)注冊(cè)和變更通知的作用，但是在有一些特定的場(chǎng)景里面并不是這樣子的。舉個(gè)例子來說，當(dāng)一個(gè)注冊(cè)中心因?yàn)樽陨淼脑蛱幱谝粋€(gè)半死不活的狀態(tài)，它一會(huì)兒能服務(wù)、一會(huì)兒不能服務(wù)的時(shí)候，就會(huì)發(fā)生一個(gè)比較恐怖的事情，Provider 端因?yàn)樗?cè)中心去保持心跳判活的狀態(tài)，所以需要和注冊(cè)中心保持長(zhǎng)期有效的連接。如果是失效的情況，作業(yè)中心就會(huì)判斷這個(gè) Provider 是不存活了。不存活的時(shí)候，注冊(cè)中心就會(huì)把這個(gè)消息通知給 Consumer 端，Consumer 端只要接收過一次下線通知，Consumer 就會(huì)從它的列表里面把這個(gè) Provider 從本地的緩存里面去移除掉。

圖片

如果注冊(cè)中心處于一個(gè)半死不活的狀態(tài)，最后會(huì)處于一個(gè)什么狀態(tài)呢？Consumer 端慢慢地會(huì)把所有的 Provider 都移除掉，這樣就會(huì)導(dǎo)致我們的 Consumer 端到 Provider 端其實(shí)是不可通信的。對(duì)于這個(gè)問題，我們其實(shí)基于 Dubbo 做了一定的改造，做了一個(gè)保護(hù)機(jī)制。這個(gè)保護(hù)機(jī)制就是當(dāng) Provider，特別是注冊(cè)中心上的 Provider 數(shù)少于一定的閾值的時(shí)候，我們的保護(hù)機(jī)制就會(huì)自動(dòng)地啟用，它的生效是在 Consumer 端的，也就意味著 Consumer 端需要緩存這段時(shí)間內(nèi)所有歷史的 Provider 的列表。

大家可能在這里會(huì)有一點(diǎn)擔(dān)心，你緩存的 Provider 如果失效了怎么辦？它是真的失效了，比如說它被下線了，或者是它本身經(jīng)過遷移，像我們?cè)谌萜鲌?chǎng)景里面，經(jīng)過了一定的發(fā)布，其實(shí)它對(duì)應(yīng)的信息都變化了，這個(gè)時(shí)候你再去通信不就有問題嗎？其實(shí)我們?cè)诒Ｗo(hù)機(jī)制里面也考慮了這個(gè)問題，我們?cè)谕ㄐ胖斑€是會(huì)做一個(gè)直連的檢查，Consumer 到 Provider 的連接存活是否是真正存在，如果不存在，我們會(huì)把這一個(gè)連接給扔掉，保證通信的時(shí)候使用的是一個(gè)可用的連接。

當(dāng)這個(gè)信息機(jī)制啟用了之后，注冊(cè)中心恢復(fù)到一定的狀態(tài)的，這個(gè) Provider 又能重新注冊(cè)到注冊(cè)中心里面了，接著我們又會(huì)把保護(hù)機(jī)制自動(dòng)關(guān)閉掉，這樣的話 Consumer 就只會(huì)調(diào)用注冊(cè)中心上存活的這些 Provider，就可以避免掉因?yàn)樽?cè)中心半死不活，導(dǎo)致所有的這些分布式的應(yīng)用里面的 RPC 調(diào)用是不可用的。

這其實(shí)是一個(gè)比較有效的方式，因?yàn)槿绻霈F(xiàn)了這種場(chǎng)景，其實(shí)你內(nèi)網(wǎng)里面的大部分應(yīng)用通信其實(shí)是處于一個(gè)不可用的狀態(tài)，甚至你想讓它恢復(fù)都是非常困難的事情。比如你想啟動(dòng)的時(shí)候，其實(shí) Consumer 發(fā)現(xiàn) Provider 都不存活了，這也會(huì)導(dǎo)致啟動(dòng)失敗等等各方面的問題。

4. 動(dòng)態(tài)限流

接著我來介紹一下限流里面我們做的一些工作，這里面我們做的模式我把它叫做動(dòng)態(tài)限流。普通的一個(gè)限流里面，通常來說是這樣的一個(gè)方式，我們有 A、B、C 的服務(wù)都對(duì) X 這個(gè)服務(wù)進(jìn)行了調(diào)用，它的來源可能是不一樣的，X 為了保護(hù)自身的狀態(tài)是可用的，它不可避免就要對(duì)上游 A、B、C 的這些訪問分配固定的一些配額，誰超過了配額就不可用了。

圖片

比如說像 A 分配了 100、B 也分配 100、C 分配給了 50。當(dāng) A 超過了 100 的時(shí)候，其實(shí)它的一些請(qǐng)求是會(huì)被拒絕掉的，這個(gè)是基于容量的考慮，X 不可能具備無限的容量，這時(shí)它需要一定的保護(hù)措施。但是這地方就會(huì)有一個(gè)問題，假如 A、B、C 里面，比如說 B 服務(wù)，它其實(shí)是從 App 過來的，它的價(jià)值不可避免來說的話，要更高一點(diǎn)。比如說第三個(gè)服務(wù) C，它是從 Web 里面來，它的價(jià)值相對(duì)來說比較低一點(diǎn)。這個(gè)價(jià)值是基于你的業(yè)務(wù)形態(tài)來的，比如說你的 App 的成單、轉(zhuǎn)化更高，那就意味著它的請(qǐng)求更珍貴。

這個(gè)里面就會(huì)出現(xiàn)一個(gè)問題，服務(wù) B 和服務(wù) C 自己都得到了一定數(shù)量的配額，但是假如 App 的流量上漲了，Web 的流量沒有上漲，這時(shí)就會(huì)面臨一個(gè)問題，服務(wù) C 的配額沒用完，但是服務(wù) B 的配額又不夠用，這個(gè)場(chǎng)景下怎么解決呢？就需要靠人工來不停地去調(diào)整它，而且這個(gè)調(diào)整需要相當(dāng)實(shí)時(shí)才可以，我們有沒有辦法能夠相對(duì)統(tǒng)一地解決這個(gè)問題呢，其實(shí)我們做了一個(gè)探索，這個(gè)探索從實(shí)踐結(jié)果來看的話是比較有效的。

圖片

我們對(duì)這些服務(wù)進(jìn)行配額分配的時(shí)候，其實(shí)不是一個(gè)固定的配額，而是一個(gè)動(dòng)態(tài)的分配。動(dòng)態(tài)的分配意思就是，我只有一個(gè)總的容量，并不給每一個(gè)服務(wù)進(jìn)行分配，總的容量我分配給所有人。但是我要對(duì)所有的調(diào)用方進(jìn)行一個(gè)排序，也就是說誰的價(jià)值高誰就排在前面，這樣的話就能得到一個(gè)比較有效的結(jié)果。你的限流模型是基于你的業(yè)務(wù)邏輯來的，也是基于你的業(yè)務(wù)價(jià)值來的，當(dāng)你發(fā)生限流的時(shí)候，優(yōu)先丟掉的一定是最沒有價(jià)值的那部分的業(yè)務(wù)請(qǐng)求。

當(dāng)然這里面也會(huì)有一個(gè)前提，你的請(qǐng)求來源是需要有差異化的。還有第二個(gè)點(diǎn)，你的這些 trace 連通性一定要高，也就意味著，你的這些標(biāo)志要能夠一路暢通地?cái)y帶下去，如果只是基于某一層去做限流邏輯，其實(shí)是沒有意義的。

5. 防腐化

接著就是防腐化，這里面其實(shí)我們需要對(duì)架構(gòu)、應(yīng)用的分布、應(yīng)用的關(guān)系去做大量的分析，得出改進(jìn)的措施，我們?cè)谶@上面改進(jìn)的措施其實(shí)有很多。比如我們會(huì)分析哪些應(yīng)用是頻繁修改的，這些頻繁修改的意思是不是所有的需求，這些應(yīng)用都相關(guān)地需要去做修改，那就意味著說它的業(yè)務(wù)域是一樣的。如果這些業(yè)務(wù)域一樣的情況下，你把它的微服務(wù)劃分得很細(xì)，實(shí)際上它是一一綁定的話，其實(shí)并不符合微服務(wù)化的原則。

第二個(gè)是否存在重復(fù)的調(diào)用，這條鏈路里面，這些重復(fù)的調(diào)用是否能夠去緩存化，或者是避免它重復(fù)調(diào)用。

第三個(gè)大量的串行調(diào)用是不是能夠把它異步化，比如常見的，從數(shù)據(jù)庫(kù)里面拿出一批記錄，這一批記錄通過循環(huán)的方式，挨個(gè)去對(duì)它發(fā)起遠(yuǎn)程調(diào)用，這些過程里面其實(shí)比較有效的方式就是通過異步化、并行化的方式去把速度給提上來。

第四個(gè)異步的整個(gè)鏈路的這些超時(shí)配置里面，其實(shí)會(huì)有一定的相關(guān)的關(guān)系。比如上游的超時(shí)是不應(yīng)該比下游短的，如果下游的超時(shí)比上游的還長(zhǎng)，那意味著說下游還在計(jì)算，上游可能已經(jīng)超時(shí)了，這個(gè)計(jì)算的結(jié)果其實(shí)有可能返回不了上游，這些就是無用的配置。除了這之外其實(shí)整個(gè)鏈路里面大量的超時(shí)可能是不合理的，比如剛才提到的大量重復(fù)的調(diào)用，這些重復(fù)的調(diào)用或者循環(huán)的調(diào)用，再乘以同樣的超時(shí)時(shí)間，可能就會(huì)比整個(gè)終端的操作時(shí)間要長(zhǎng)很多，這些都需要去做一定的分析和考慮，才能達(dá)到它防腐化的目的。