微服務是什么?拋去教條性質(zhì)的解釋，從巨石應用到微服務應用，耦合度是其中最大的變化。

[[329434]]

 

圖片來自 Pexels

或是將多個模塊中重復的部分進行拆分，或是純粹為了拆分膨脹的單體應用，這些拆分出來的部分獨立成一個服務單獨部署與維護，便是微服務了。

拆分后自然而然會催生出一些必要的需求：

• 從本地方法調(diào)用的關(guān)系衍變成遠程過程調(diào)用的關(guān)系，那么可靠的通信功能是首要的。
• 隨著拆分工作的推進，資源調(diào)度關(guān)系會變得錯綜復雜，這時候需要完善的服務治理。
• 調(diào)用關(guān)系網(wǎng)的整體復雜化還會給我們帶來更大的風險，即鏈式反應導致服務雪崩的可能性，所以如何保障服務穩(wěn)定性也是微服務架構(gòu)中需要考慮的。
• 這點就不是內(nèi)需而算是自我演進了，服務化后，如果能結(jié)合容器化、Devops 技術(shù)實現(xiàn)服務運維一體化，將大大降低微服務維護的成本，不管是現(xiàn)在還是將來。

微服務是什么樣的

從目前常見網(wǎng)站架構(gòu)的宏觀角度看，微服務處在中間的層次。紅框圈出的部分都屬于微服務的范疇。

 

包括最基礎(chǔ)的 RPC 框架、注冊中心、配置中心，以及更廣義角度的監(jiān)控追蹤、治理中心、調(diào)度中心等。

從微服務自身角度來看，則大致會包含以下這些模塊:

 

• 服務注冊與發(fā)現(xiàn)
• RPC 遠程調(diào)用
• 路由與負載均衡
• 服務監(jiān)控
• 服務治理

服務化的前提

是不是只要套上微服務框架就算是一個微服務了呢?雖然這樣有了微服務的表，但卻沒有微服務的實質(zhì)，即“微”。

微服務化的前提是服務拆分到足夠”微“，足夠單一職責，當然拆分程度與服務邊界都需要結(jié)合業(yè)務自行把握。

廣義的服務拆分即包含了應用拆分，也包含了數(shù)據(jù)拆分。應用拆分后需要引入微服務框架來進行服務通信與服務治理，這也就是傳統(tǒng)定義上的微服務。

數(shù)據(jù)拆分后同樣需要引入一系列手段來進行保障，由于不是與微服務強相關(guān)的話題，在此只做簡單闡述：

• 分布式 ID
• 新表優(yōu)化
• 數(shù)據(jù)遷移與數(shù)據(jù)同步
• SQL 調(diào)用方案改造
• 切庫方案
• 數(shù)據(jù)一致性

具體的微服務請求背后

在我們對微服務架構(gòu)有了整體的認識，并且具備了服務化的前提后，一個完整的微服務請求需要涉及到哪些內(nèi)容呢?

這其中包括了微服務框架所具備的三個基本功能：

• 服務的發(fā)布與引用
• 服務的注冊與發(fā)現(xiàn)
• 服務的遠程通信

服務的發(fā)布與引用

首先我們面臨的第一個問題是，如何發(fā)布服務和引用服務。具體一點就是，這個服務的接口名是啥，有哪些參數(shù)，返回值是什么類型等等，通常也就是接口描述信息。

常見的發(fā)布和引用的方式包括：

• RESTful API/聲明式 Restful API
• XML
• IDL

一般來講，不管使用哪種方式，服務端定義接口與實現(xiàn)接口都是必要的，例如：

 

@exa(id = "xxx") 
public interface testApi { 
 
    @PostMapping(value = "/soatest/{id}") 
    String getResponse(@PathVariable(value = "id") final Integer index, @RequestParam(value = "str") final String Data); 
    } 

具體實現(xiàn)如下：

 

public class testApiImpl implements testApi{ 
 
        @Override 
        String getResponse(final Integer index, final String Data){ 
            return "ok"; 
        } 
} 

聲明式 Restful API：這種常使用 HTTP 或者 HTTPS 協(xié)議調(diào)用服務，相對來說，性能稍差。

首先服務端如上定義接口并實現(xiàn)接口，隨后服務提供者可以使用類似 restEasy 這樣的框架通過 Servlet 的方式發(fā)布服務，而服務消費者直接引用定義的接口調(diào)用。

除此之外還有一種類似 Feign 的方式，即服務端的發(fā)布依賴于 SpringMVC Controller，框架只基于客戶端模板化 HTTP 請求調(diào)用。

這種情況下需接口定義與服務端 Controller 協(xié)商一致，這樣客戶端直接引用接口發(fā)起調(diào)用即可。

XML：使用私有 RPC 協(xié)議的都會選擇 XML 配置的方式來描述接口，比較高效，例如 Dubbo、Motan 等。

同樣服務端如上定義接口并實現(xiàn)接口，服務端通過 server.xml 將文件接口暴露出去。服務消費者則通過 client.xml 引用需要調(diào)用的接口。

但這種方式對業(yè)務代碼入侵較高，XML 配置有變更時候，服務消費者和服務提供者都需要更新。

IDL：是接口描述語言，常用于跨語言之間的調(diào)用，最常用的 IDL 包括 Thrift 協(xié)議以及 gRpc 協(xié)議。

例如 gRpc 協(xié)議使用 Protobuf 來定義接口，寫好一個 proto 文件后，利用語言對應的 protoc 插件生成對應 server 端與 client 端的代碼，便可直接使用。

但是如果參數(shù)字段非常多，proto 文件會顯得非常大難以維護。并且如果字段經(jīng)常需要變更，例如刪除字段，PB 就無法做到向前兼容。

一些 Tips：不管哪種方式，在接口變更的時候都需要通知服務消費者。消費者對api的強依賴性是很難避免的，接口變更引起的各種調(diào)用失敗也十分常見。

所以如果有變更，盡量使用新增接口的方式，或者給每個接口定義好版本號吧。在使用上，大多數(shù)人的選擇是對外 Restful，對內(nèi) XML，跨語言 IDL。

一些問題：在實際的服務發(fā)布與引用的落地上，還會存在很多問題，大多和配置信息相關(guān)。

例如一個簡單的接口調(diào)用超時時間配置，這個配置應該配在服務級別還是接口級別?是放在服務提供者這邊還是服務消費者這邊?

在實踐中，大多數(shù)服務消費者會忽略這些配置，所以服務提供者自身提供默認的配置模板是有必要的，相當于一個預定義的過程。

每個服務消費者在繼承服務提供者預定義好的配置后，還需要能夠進行自定義的配置覆蓋。

但是，比方說一個服務有 100 個接口，每個接口都有自身的超時配置，而這個服務又有 100 個消費者，當服務節(jié)點發(fā)生變更的時候，就會發(fā)生 100*100 次注冊中心的消息通知，這是比較可怕的，就有可能引起網(wǎng)絡風暴。

服務的注冊與發(fā)現(xiàn)

假設你已經(jīng)發(fā)布了服務，并在一臺機器上部署了服務，那么消費者該怎樣找到你的服務的地址呢?

也許有人會說是 DNS，但 DNS 有許多缺陷：

• 維護麻煩，更新延遲
• 無法在客戶端做負載均衡
• 不能做到端口級別的服務發(fā)現(xiàn)

其實在分布式系統(tǒng)中，有個很重要的角色，叫注冊中心，便是用于解決該問題。

 

使用注冊中心尋址并調(diào)用的過程如下：

• 服務啟動時，向注冊中心注冊自身，并定期發(fā)送心跳匯報存活狀態(tài)。
• 客戶端調(diào)用服務時，向注冊中心訂閱服務，并將節(jié)點列表緩存至本地，再與服務端建立連接(當然這兒可以 lazy load)。發(fā)起調(diào)用時，在本地緩存節(jié)點列表中，基于負載均衡算法選取一臺服務端發(fā)起調(diào)用。
• 當服務端節(jié)點發(fā)生變更，注冊中心能感知到后通知到客戶端。

注冊中心的實現(xiàn)主要需要考慮以下這些問題：

• 自身一致性與可用性
• 注冊方式
• 存儲結(jié)構(gòu)
• 服務健康監(jiān)測
• 狀態(tài)變更通知

①一致性與可用性

一個老舊的命題，即分布式系統(tǒng)中的 CAP(一致性、可用性、分區(qū)容錯性)。

我們知道同時滿足 CAP 是不可能的，那么便需要有取舍。常見的注冊中心大致分為 CP 注冊中心以及 AP 注冊中心。

CP 注冊中心：比較典型的就是 Zookeeper、etcd 以及 Consul 了，犧牲可用性來保證了一致性，通過 Zab 協(xié)議或者 Raft 協(xié)議來保證一致性。

AP 注冊中心：犧牲一致性來保證可用性，感覺只能列出 Eureka 了。Eureka 每個服務器單獨保存節(jié)點列表，可能會出現(xiàn)不一致的情況。

從理論上來說，僅用于注冊中心，AP 型是遠比 CP 型合適的。可用性的需求遠遠高于一致性，一致性只要保證最終一致即可，而不一致的時候還可以使用各種容錯策略進行彌補。

保障高可用性其實還有很多辦法，例如集群部署或者多 IDC 部署等。Consul 就是多 IDC 部署保障可用性的典型例子，它使用了 wan gossip 來保持跨機房狀態(tài)同步。

②注冊方式

有兩種與注冊中心交互的方式，一種是通過應用內(nèi)集成 SDK，另一種則是通過其他方式在應用外間接與注冊中心交互。

應用內(nèi)：這應該就是最常見的方式了，客戶端與服務端都集成相關(guān)sdk與注冊中心進行交互。

例如選擇 Zookeeper 作為注冊中心，那么就可以使用 Curator SDK 進行服務的注冊與發(fā)現(xiàn)。

應用外：Consul 提供了應用外注冊的解決方案，Consul Agent 或者第三方 Registrator 可以監(jiān)聽服務狀態(tài)，從而負責服務提供者的注冊或銷毀。

而 Consul Template 則可以做到定時從注冊中心拉取節(jié)點列表，并刷新 LB 配置(例如通過 Nginx 的 upstream)，這樣就相當于完成了服務消費者端的負載均衡。

③存儲結(jié)構(gòu)

注冊中心存儲相關(guān)信息一般采取目錄化的層次結(jié)構(gòu)，一般分為服務-接口-節(jié)點信息。

同時注冊中心一般還會進行分組，分組的概念很廣，可以是根據(jù)機房劃分也可以根據(jù)環(huán)境劃分。

節(jié)點信息主要會包括節(jié)點的地址(ip 和端口號)，還有一些節(jié)點的其他信息，比如請求失敗的重試次數(shù)、超時時間的設置等等。

當然很多時候，其實可能會把接口這一層給去掉，因為考慮到接口數(shù)量很多的情況下，過多的節(jié)點會造成很多問題，比如之前說的網(wǎng)絡風暴。

④服務健康監(jiān)測

服務存活狀態(tài)監(jiān)測也是注冊中心的一個必要功能。在 Zookeeper 中，每個客戶端都會與服務端保持一個長連接，并生成一個 Session。

在 Session 過期周期內(nèi)，通過客戶端定時向服務端發(fā)送心跳包來檢測鏈路是否正常，服務端則重置下次 Session 的過期時間。

如果 Session 過期周期內(nèi)都沒有檢測到客戶端的心跳包，那么就會認為它已經(jīng)不可用了，將其從節(jié)點列表中移除。

⑤狀態(tài)變更通知

在注冊中心具備服務健康檢測能力后，還需要將狀態(tài)變更通知到客戶端。在 Zookeeper 中，可以通過監(jiān)聽器 Watcher 的 Process 方法來獲取服務變更。

服務的遠程通信

在上面，服務消費者已經(jīng)正確引用了服務，并發(fā)現(xiàn)了該服務的地址，那么如何向這個地址發(fā)起請求呢?

要解決服務間的遠程通信問題，我們需要考慮一些問題：

• 網(wǎng)絡 I/O 的處理
• 傳輸協(xié)議
• 序列化方式

①網(wǎng)絡 I/O 的處理

簡單來說，就是客戶端是怎么處理請求?服務端又是怎么處理請求的?

先從客戶端來說，我們創(chuàng)建連接的時機可以是從注冊中心獲取到節(jié)點信息的時候，但更多時候，我們會選擇在第一次請求發(fā)起調(diào)用的時候去創(chuàng)建連接。此外，我們往往會為該節(jié)點維護一個連接池，進行連接復用。

如果是異步的情況下，我們還需要為每一個請求編號，并維護一個請求池，從而在響應返回時找到對應的請求。當然這并不是必須的，很多框架會幫我們干好這些事情，比如 rxNetty。

從服務端來說，處理請求的方式就可以追溯到 Unix 的 5 種 IO 模型了。我們可以直接使用 Netty、MINA 等網(wǎng)絡框架來處理服務端請求，或者如果你有十分的興趣，可以自己實現(xiàn)一個通信框架。

②傳輸協(xié)議

最常見的當然是直接使用 HTTP 協(xié)議，使用雙方無需關(guān)注和了解協(xié)議內(nèi)容，方便直接，但自然性能上會有所折損。

還有就是目前比較火熱的 HTTP2 協(xié)議，擁有二進制數(shù)據(jù)、頭部壓縮、多路復用等許多優(yōu)良特性。

但從自身的實踐上看，HTTP2 要走到生產(chǎn)仍有一段距離，一個最簡單的例子，升級到 HTTP2 后所有的 header names 都變成小寫，同時不是 case-insenstive 了，這時候就會有兼容性問題。

當然如果追求更高效與可控的傳輸，可以定制私有協(xié)議并基于 TCP 進行傳輸。私有協(xié)議的定制需要通信雙方都了解其特性，設計上還需要注意預留好擴展字段，以及處理好粘包分包等問題。

③序列化方式

在網(wǎng)絡傳輸?shù)那昂螅夹枰诎l(fā)送端進行編碼，在服務端進行解碼，這樣主要是為了在網(wǎng)絡傳輸時候減少數(shù)據(jù)傳輸量。

常用的序列化方式包括文本類的，例如 XML/JSON，還有二進制類型的，例如 Protobuf/Thrift 等。

在選擇序列化的考慮上：

一是性能，Protobuf 的壓縮大小和壓縮速度都會比 JSON 快很多，性能也更好。

二是兼容性上，相對來說，JSON 的前后兼容性會強一些，可以用于接口經(jīng)常變化的場景。

在此還是需要強調(diào)，使用每一種序列化都需要了解過其特性，并在接口變更的時候拿捏好邊界。

例如 jackson 的 FAIL_ON_UNKNOW_PROPERTIES 屬性、kryo 的 CompatibleFieldSerializer、jdk 序列化會嚴格比較 serialVersionUID 等等。

微服務的穩(wěn)定性

當一個單體應用改造成多個微服務之后，在請求調(diào)用過程中往往會出現(xiàn)更多的問題，通信過程中的每一個環(huán)節(jié)都可能出現(xiàn)問題。

而在出現(xiàn)問題之后，如果不加處理，還會出現(xiàn)鏈式反應導致服務雪崩。服務治理功能就是用來處理此類問題的。

我們將從微服務的三個角色：注冊中心、服務消費者以及服務提供者一一說起。

注冊中心如何保障穩(wěn)定性

注冊中心主要是負責節(jié)點狀態(tài)的維護，以及相應的變更探測與通知操作。

一方面，注冊中心自身的穩(wěn)定性是十分重要的。另一方面，我們也不能完全依賴注冊中心，需要時常進行類似注冊中心完全宕機后微服務如何正常運行的故障演練。

這一節(jié)，我們著重講的并不是注冊中心自身可用性保證，而更多的是與節(jié)點狀態(tài)相關(guān)的部分。

①節(jié)點信息的保障

我們說過，當注冊中心完全宕機后，微服務框架仍然需要有正常工作的能力。這得益于框架內(nèi)處理節(jié)點狀態(tài)的一些機制。

本機內(nèi)存：首先服務消費者會將節(jié)點狀態(tài)保持在本機內(nèi)存中。

一方面由于節(jié)點狀態(tài)不會變更得那么頻繁，放在內(nèi)存中可以減少網(wǎng)絡開銷。另一方面，當注冊中心宕機后，服務消費者仍能從本機內(nèi)存中找到服務節(jié)點列表從而發(fā)起調(diào)用。

本地快照：我們說，注冊中心宕機后，服務消費者仍能從本機內(nèi)存中找到服務節(jié)點列表。那么如果服務消費者重啟了呢?

這時候我們就需要一份本地快照了，即我們保存一份節(jié)點狀態(tài)到本地文件，每次重啟之后會恢復到本機內(nèi)存中。

②服務節(jié)點的摘除

現(xiàn)在無論注冊中心工作與否，我們都能順利拿到服務節(jié)點了。但是不是所有的服務節(jié)點都是正確可用的呢?

在實際應用中，這是需要打問號的。如果我們不校驗服務節(jié)點的正確性，很有可能就調(diào)用到了一個不正常的節(jié)點上。所以我們需要進行必要的節(jié)點管理。

對于節(jié)點管理來說，我們有兩種手段，主要是去摘除不正確的服務節(jié)點。

注冊中心摘除機制：一是通過注冊中心來進行摘除節(jié)點。服務提供者會與注冊中心保持心跳，而一旦超出一定時間收不到心跳包，注冊中心就認為該節(jié)點出現(xiàn)了問題，會把節(jié)點從服務列表中摘除，并通知到服務消費者，這樣服務消費者就不會調(diào)用到有問題的節(jié)點上。

服務消費者摘除機制：二是在服務消費者這邊拆除節(jié)點。因為服務消費者自身是最知道節(jié)點是否可用的角色，所以在服務消費者這邊做判斷更合理，如果服務消費者調(diào)用出現(xiàn)網(wǎng)絡異常，就將該節(jié)點從內(nèi)存緩存列表中摘除。

當然調(diào)用失敗多少次之后才進行摘除，以及摘除恢復的時間等等細節(jié)，其實都和客戶端熔斷類似，可以結(jié)合起來做。

一般來說，對于大流量應用，服務消費者摘除的敏感度會高于注冊中心摘除，兩者之間也不用刻意做同步判斷，因為過一段時間后注冊中心摘除會自動覆蓋服務消費者摘除。

③服務節(jié)點是可以隨便摘除/變更的么

上一節(jié)我們講可以摘除問題節(jié)點，從而避免流量調(diào)用到該節(jié)點上。但節(jié)點是可以隨便摘除的么?同時，這也包含"節(jié)點是可以隨便更新的么?"疑問。

頻繁變動：當網(wǎng)絡抖動的時候，注冊中心的節(jié)點就會不斷變動。這導致的后果就是變更消息會不斷通知到服務消費者，服務消費者不斷刷新本地緩存。

如果一個服務提供者有 100 個節(jié)點，同時有 100 個服務消費者，那么頻繁變動的效果可能就是 100*100，引起帶寬打滿。

這時候，我們可以在注冊中心這邊做一些控制，例如經(jīng)過一段時間間隔后才能進行變更消息通知，或者打開開關(guān)后直接屏蔽不進行通知，或者通過一個概率計算來判斷需要向哪些服務消費者通知。

增量更新：同樣是由于頻繁變動可能引起的網(wǎng)絡風暴問題，一個可行的方案是進行增量更新，注冊中心只會推送那些變化的節(jié)點信息而不是全部，從而在頻繁變動的時候避免網(wǎng)絡風暴。

可用節(jié)點過少：當網(wǎng)絡抖動，并進行節(jié)點摘除過后，很可能出現(xiàn)可用節(jié)點過少的情況。

這時候過大的流量分配給過少的節(jié)點，導致剩下的節(jié)點難堪重負，罷工不干，引起惡化。

而實際上，可能節(jié)點大多數(shù)是可用的，只不過由于網(wǎng)絡問題與注冊中心未能及時保持心跳而已。

這時候，就需要在服務消費者這邊設置一個開關(guān)比例閾值，當注冊中心通知節(jié)點摘除，但緩存列表中剩下的節(jié)點數(shù)低于一定比例后(與之前一段時間相比)，不再進行摘除，從而保證有足夠的節(jié)點提供正常服務。

這個值其實可以設置的高一些，例如百分之 70，因為正常情況下不會有頻繁的網(wǎng)絡抖動。當然，如果開發(fā)者確實需要下線多數(shù)節(jié)點，可以關(guān)閉該開關(guān)。

服務消費者如何保障穩(wěn)定性

一個請求失敗了，最直接影響到的是服務消費者，那么在服務消費者這邊，有什么可以做的呢?

①超時

如果調(diào)用一個接口，但遲遲沒有返回響應的時候，我們往往需要設置一個超時時間，以防自己被遠程調(diào)用拖死。

超時時間的設置也是有講究的，設置的太長起的作用就小，自己被拖垮的風險就大，設置的太短又有可能誤判一些正常請求，大幅提升錯誤率。

在實際使用中，我們可以取該應用一段時間內(nèi)的 P999 的值，或者取 p95 的值*2，具體情況需要自行定奪。

在超時設置的時候，對于同步與異步的接口也是有區(qū)分的。對于同步接口，超時設置的值不僅需要考慮到下游接口，還需要考慮上游接口。

而對于異步來說，由于接口已經(jīng)快速返回，可以不用考慮上游接口，只需考慮自身在異步線程里的阻塞時長，所以超時時間也放得更寬一些。

②容錯機制

請求調(diào)用永遠不能保證成功，那么當請求失敗時候，服務消費者可以如何進行容錯呢?

通常容錯機制分為以下這些：

• FailTry：失敗重試。就是指最常見的重試機制，當請求失敗后視圖再次發(fā)起請求進行重試。

這樣從概率上講，失敗率會呈指數(shù)下降。對于重試次數(shù)來說，也需要選擇一個恰當?shù)闹担绻卦嚧螖?shù)太多，就有可能引起服務惡化。

另外，結(jié)合超時時間來說，對于性能有要求的服務，可以在超時時間到達前的一段提前量就發(fā)起重試，從而在概率上優(yōu)化請求調(diào)用。當然，重試的前提是冪等操作。

• FailOver：失敗切換。和上面的策略類似，只不過 FailTry 會在當前實例上重試。而 FailOver 會重新在可用節(jié)點列表中根據(jù)負載均衡算法選擇一個節(jié)點進行重試。
• FailFast：快速失敗。請求失敗了就直接報一個錯，或者記錄在錯誤日志中，這沒什么好說的。

另外，還有很多形形色色的容錯機制，大多是基于自己的業(yè)務特性定制的，主要是在重試上做文章，例如每次重試等待時間都呈指數(shù)增長等。

第三方框架也都會內(nèi)置默認的容錯機制，例如 Ribbon 的容錯機制就是由 retry 以及 retry next 組成，即重試當前實例與重試下一個實例。

這里要多說一句，Ribbon 的重試次數(shù)與重試下一個實例次數(shù)是以笛卡爾乘積的方式提供的噢!

③熔斷

上一節(jié)將的容錯機制，主要是一些重試機制，對于偶然因素導致的錯誤比較有效，例如網(wǎng)絡原因。

但如果錯誤的原因是服務提供者自身的故障，那么重試機制反而會引起服務惡化。

這時候我們需要引入一種熔斷的機制，即在一定時間內(nèi)不再發(fā)起調(diào)用，給予服務提供者一定的恢復時間，等服務提供者恢復正常后再發(fā)起調(diào)用。這種保護機制大大降低了鏈式異常引起的服務雪崩的可能性。

在實際應用中，熔斷器往往分為三種狀態(tài)，打開、半開以及關(guān)閉。引用一張 MartinFowler 畫的原理圖：

 

在普通情況下，斷路器處于關(guān)閉狀態(tài)，請求可以正常調(diào)用。當請求失敗達到一定閾值條件時，則打開斷路器，禁止向服務提供者發(fā)起調(diào)用。

當斷路器打開后一段時間，會進入一個半開的狀態(tài)，此狀態(tài)下的請求如果調(diào)用成功了則關(guān)閉斷路器，如果沒有成功則重新打開斷路器，等待下一次半開狀態(tài)周期。

斷路器的實現(xiàn)中比較重要的一點是失敗閾值的設置。可以根據(jù)業(yè)務需求設置失敗的條件為連續(xù)失敗的調(diào)用次數(shù)，也可以是時間窗口內(nèi)的失敗比率，失敗比率通過一定的滑動窗口算法進行計算。

另外，針對斷路器的半開狀態(tài)周期也可以做一些花樣，一種常見的計算方法是周期長度隨著失敗次數(shù)呈指數(shù)增長。

具體的實現(xiàn)方式可以根據(jù)具體業(yè)務指定，也可以選擇第三方框架例如 Hystrix。

④隔離

隔離往往和熔斷結(jié)合在一起使用，還是以 Hystrix 為例，它提供了兩種隔離方式：

信號量隔離：使用信號量來控制隔離線程，你可以為不同的資源設置不同的信號量以控制并發(fā)，并相互隔離。當然實際上，使用原子計數(shù)器也沒什么不一樣。

線程池隔離：通過提供相互隔離的線程池的方式來隔離資源，相對來說消耗資源更多，但可以更好地應對突發(fā)流量。

⑤降級

降級同樣大多和熔斷結(jié)合在一起使用，當服務調(diào)用者這方斷路器打開后，無法再對服務提供者發(fā)起調(diào)用了，這時候可以通過返回降級數(shù)據(jù)來避免熔斷造成的影響。

降級往往用于那些錯誤容忍度較高的業(yè)務。同時降級的數(shù)據(jù)如何設置也是一門學問。

一種方法是為每個接口預先設置好可接受的降級數(shù)據(jù)，但這種靜態(tài)降級的方法適用性較窄。

還有一種方法，是去線上日志系統(tǒng)/流量錄制系統(tǒng)中撈取上一次正確的返回數(shù)據(jù)作為本次降級數(shù)據(jù)，但這種方法的關(guān)鍵是提供可供穩(wěn)定抓取請求的日志系統(tǒng)或者流量采樣錄制系統(tǒng)。

另外，針對降級我們往往還會設置操作開關(guān)，對于一些影響不大的采取自動降級，而對于一些影響較大的則需進行人為干預降級。

服務提供者如何保障穩(wěn)定性

①限流

限流就是限制服務請求流量，服務提供者可以根據(jù)自身情況(容量)給請求設置一個閾值，當超過這個閾值后就丟棄請求，這樣就保證了自身服務的正常運行。

閾值的設置可以針對兩個方面考慮：

• QPS，即每秒請求數(shù)
• 并發(fā)線程數(shù)

從實踐來看，我們往往會選擇后者，因為 QPS 高往往是由于處理能力高，并不能反映出系統(tǒng)"不堪重負"。

除此之外，我們還有許多針對限流的算法。例如令牌桶算法以及漏桶算法，主要針對突發(fā)流量的狀況做了優(yōu)化。

第三方的實現(xiàn)中例如 guava rateLimiter 就實現(xiàn)了令牌桶算法。在此就不就細節(jié)展開了。

②重啟與回滾

限流更多的起到一種保障的作用，但如果服務提供者已經(jīng)出現(xiàn)問題了，這時候該怎么辦呢?

這時候就會出現(xiàn)兩種狀況：一是本身代碼有 Bug，這時候一方面需要服務消費者做好熔斷降級等操作，一方面服務提供者這邊結(jié)合 DevOps 需要有快速回滾到上一個正確版本的能力。

更多的時候，我們可能僅僅碰到了與代碼無強關(guān)聯(lián)的單機故障，一個簡單粗暴的辦法就是自動重啟。

例如觀察到某個接口的平均耗時超出了正常范圍一定程度，就將該實例進行自動重啟。

當然自動重啟需要有很多注意事項，例如重啟時間是否放在晚上，以及自動重啟引起的與上述節(jié)點摘除一樣的問題，都需要考慮和處理。

在事后復盤的時候，如果當時沒有保護現(xiàn)場，就很難定位到問題原因。所以往往在一鍵回滾或者自動重啟之前，我們往往需要進行現(xiàn)場保護。

現(xiàn)場保護可以是自動的，例如：

• 一開始就給 jvm 加上打印 gc 日志的參數(shù) -XX:+PrintGCDetails
• 或者輸出 oom 文件 -XX:+HeapDumpOnOutOfMemoryError
• 也可以配合 DevOps 自動腳本完成，當然手動也可以

一般來說我們會如下操作：

• 打印堆棧信息，jstak -l 'java進程PID'
• 打印內(nèi)存鏡像，jmap -dump:format=b,file=hprof 'java進程PID'
• 保留 gc 日志，保留業(yè)務日志

③調(diào)度流量

除了以上這些措施，通過調(diào)度流量來避免調(diào)用到問題節(jié)點上也是非常常用的手段。

當服務提供者中的一臺機器出現(xiàn)問題，而其他機器正常時，我們可以結(jié)合負載均衡算法迅速調(diào)整該機器的權(quán)重至 0，避免流量流入，再去機器上進行慢慢排查，而不用著急第一時間重啟。

如果服務提供者分了不同集群/分組，當其中一個集群出現(xiàn)問題時，我們也可以通過路由算法將流量路由到正常的集群中。這時候一個集群就是一個微服務分組。

而當機房炸了、光纜被偷了等 IDC 故障時，我們又部署了多 IDC，也可以通過一些方式將流量切換到正常的 IDC，以供服務繼續(xù)正常運行。

切換流量同樣可以通過微服務的路由實現(xiàn)，但這時候一個 IDC 對應一個微服務分組了。

除此之外，使用 DNS 解析進行流量切換也是可以的，將對外域名的 VIP 從一個 IDC 切換到另一個 IDC。

作者：fredalxin

編輯：陶家龍

出處：https://fredal.xin/