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

除此之外還有一種類似feign的方式，即服務端的發布依賴于 ，框架只基于客戶端模板化http請求調用。這種情況下需接口定義與服務端協商一致，這樣客戶端直接引用接口發起調用即可。

XML

使用私有rpc協議的都會選擇xml配置的方式來描述接口打印后臺程序服務沒有運行怎么辦，比較高效，例如dubbo、motan等。

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

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

IDL

IDL是接口描述語言，常用于跨語言之間的調用，最常用的IDL包括協議以及gRpc協議。例如gRpc協議使用來定義接口，寫好一個proto文件后，利用語言對應的插件生成對應端與端的代碼，便可直接使用。

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

一些tips

不管哪種方式，在接口變更的時候都需要通知服務消費者。消費者對api的強依賴性是很難避免的，接口變更引起的各種調用失敗也十分常見。所以如果有變更，盡量使用新增接口的方式，或者給每個接口定義好版本號吧。

在使用上，大多數人的選擇是對外，對內Xml，跨語言IDL。

一些問題

在實際的服務發布與引用的落地上，還會存在很多問題，大多和配置信息相關。例如一個簡單的接口調用超時時間配置，這個配置應該配在服務級別還是接口級別？是放在服務提供者這邊還是服務消費者這邊？

在實踐中，大多數服務消費者會忽略這些配置，所以服務提供者自身提供默認的配置模板是有必要的，相當于一個預定義的過程。每個服務消費者在繼承服務提供者預定義好的配置后，還需要能夠進行自定義的配置覆蓋。

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

服務的注冊與發現

假設你已經發布了服務，并在一臺機器上部署了服務，那么消費者該怎樣找到你的服務的地址呢？

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

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

使用注冊中心尋址并調用的過程如下:

注冊中心的實現主要需要考慮以下這些問題:

一致性與可用性

一個老舊的命題，即分布式系統中的CAP(一致性、可用性、分區容錯性)。我們知道同時滿足CAP是不可能的，那么便需要有取舍。常見的注冊中心大致分為CP注冊中心以及AP注冊中心。

CP注冊中心

比較典型的就是、etcd以及了，犧牲可用性來保證了一致性，通過zab協議或者raft協議來保證一致性。

AP注冊中心

犧牲一致性來保證可用性，感覺只能列出了。每個服務器單獨保存節點列表，可能會出現不一致的情況。

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

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

注冊方式

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

應用內

這應該就是最常見的方式了，客戶端與服務端都集成相關sdk與注冊中心進行交互。例如選擇作為注冊中心，那么就可以使用 sdk進行服務的注冊與發現。

應用外

提供了應用外注冊的解決方案， agent或者第三方可以監聽服務狀態，從而負責服務提供者的注冊或銷毀。而 則可以做到定時從注冊中心拉取節點列表，并刷新LB配置（例如通過Nginx的），這樣就相當于完成了服務消費者端的負載均衡。

存儲結構

注冊中心存儲相關信息一般采取目錄化的層次結構，一般分為服務-接口-節點信息。

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

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

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

服務健康監測

服務存活狀態監測也是注冊中心的一個必要功能。在中，每個客戶端都會與服務端保持一個長連接，并生成一個，在過期周期內，通過客戶端定時向服務端發送心跳包來檢測鏈路是否正常，服務端則重置下次的過期時間，如果過期周期內都沒有檢測到客戶端的心跳包，那么就會認為它已經不可用了，將其從節點列表中移除。

狀態變更通知

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

服務的遠程通信

在上面，服務消費者已經正確引用了服務，并發現了該服務的地址，那么如何向這個地址發起請求呢？要解決服務間的遠程通信問題，我們需要考慮一些問題：

網絡I/O的處理

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

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

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

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

傳輸協議

最常見的當然是直接使用Http協議，使用雙方無需關注和了解協議內容，方便直接，但自然性能上會有所折損。

還有就是目前比較火熱的http2協議，擁有二進制數據、頭部壓縮、多路復用等許多優良特性。但從自身的實踐上看，http2要走到生產仍有一段距離，一個最簡單的例子，升級到http2后所有的 names都變成小寫，同時不是case-了，這時候就會有兼容性問題。

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

序列化方式

在網絡傳輸的前后，往往都需要在發送端進行編碼，在服務端進行解碼，這樣主要是為了在網絡傳輸時候減少數據傳輸量。

常用的序列化方式包括文本類的，例如XML/JSON，還有二進制類型的，例如/等。在選擇序列化的考慮上，一是性能，的壓縮大小和壓縮速度都會比JSON快很多，性能也更好。二是兼容性上，相對來說，JSON的前后兼容性會強一些，可以用于接口經常變化的場景。

在此還是需要強調，使用每一種序列化都需要了解過其特性，并在接口變更的時候拿捏好邊界。例如的RTIES屬性、kryo的lizer、jdk序列化會嚴格比較等等。

當一個單體應用改造成多個微服務之后，在請求調用過程中往往會出現更多的問題，通信過程中的每一個環節都可能出現問題。而在出現問題之后，如果不加處理，還會出現鏈式反應導致服務雪崩。服務治理功能就是用來處理此類問題的。我們將從微服務的三個角色:注冊中心、服務消費者以及服務提供者一一說起。

注冊中心如何保障穩定性

注冊中心主要是負責節點狀態的維護，以及相應的變更探測與通知操作。一方面，注冊中心自身的穩定性是十分重要的。另一方面，我們也不能完全依賴注冊中心，需要時常進行類似注冊中心完全宕機后微服務如何正常運行的故障演練。

這一節，我們著重講的并不是注冊中心自身可用性保證，而更多的是與節點狀態相關的部分。

節點信息的保障

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

本機內存

首先服務消費者會將節點狀態保持在本機內存中。一方面由于節點狀態不會變更得那么頻繁，放在內存中可以減少網絡開銷。另一方面，當注冊中心宕機后，服務消費者仍能從本機內存中找到服務節點列表從而發起調用。

本地快照

我們說，注冊中心宕機后，服務消費者仍能從本機內存中找到服務節點列表。那么如果服務消費者重啟了呢？這時候我們就需要一份本地快照了，即我們保存一份節點狀態到本地文件，每次重啟之后會恢復到本機內存中。

服務節點的摘除

現在無論注冊中心工作與否，我們都能順利拿到服務節點了。但是不是所有的服務節點都是正確可用的呢？在實際應用中，這是需要打問號的。如果我們不校驗服務節點的正確性，很有可能就調用到了一個不正常的節點上。所以我們需要進行必要的節點管理。

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

注冊中心摘除機制

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

服務消費者摘除機制

二是在服務消費者這邊拆除節點。因為服務消費者自身是最知道節點是否可用的角色，所以在服務消費者這邊做判斷更合理，如果服務消費者調用出現網絡異常，就將該節點從內存緩存列表中摘除。當然調用失敗多少次之后才進行摘除，以及摘除恢復的時間等等細節，其實都和客戶端熔斷類似，可以結合起來做。

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

服務節點是可以隨便摘除/變更的么

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

頻繁變動

當網絡抖動的時候，注冊中心的節點就會不斷變動。這導致的后果就是變更消息會不斷通知到服務消費者，服務消費者不斷刷新本地緩存。如果一個服務提供者有100個節點，同時有100個服務消費者，那么頻繁變動的效果可能就是100*100，引起帶寬打滿。

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

增量更新

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

可用節點過少

當網絡抖動，并進行節點摘除過后，很可能出現可用節點過少的情況。這時候過大的流量分配給過少的節點，導致剩下的節點難堪重負，罷工不干，引起惡化。而實際上，可能節點大多數是可用的，只不過由于網絡問題與注冊中心未能及時保持心跳而已。

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

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

服務消費者如何保障穩定性

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

超時

如果調用一個接口，但遲遲沒有返回響應的時候，我們往往需要設置一個超時時間，以防自己被遠程調用拖死。超時時間的設置也是有講究的，設置的太長起的作用就小，自己被拖垮的風險就大，設置的太短又有可能誤判一些正常請求，大幅提升錯誤率。

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

在超時設置的時候，對于同步與異步的接口也是有區分的。對于同步接口，超時設置的值不僅需要考慮到下游接口，還需要考慮上游接口。而對于異步來說，由于接口已經快速返回，可以不用考慮上游接口，只需考慮自身在異步線程里的阻塞時長，所以超時時間也放得更寬一些。

容錯機制

請求調用永遠不能保證成功，那么當請求失敗時候，服務消費者可以如何進行容錯呢？通常容錯機制分為以下這些:

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

第三方框架也都會內置默認的容錯機制，例如的容錯機制就是由retry以及retry next組成，即重試當前實例與重試下一個實例。這里要多說一句，的重試次數與重試下一個實例次數是以笛卡爾乘積的方式提供的噢！

熔斷

上一節將的容錯機制，主要是一些重試機制，對于偶然因素導致的錯誤比較有效，例如網絡原因。但如果錯誤的原因是服務提供者自身的故障，那么重試機制反而會引起服務惡化。這時候我們需要引入一種熔斷的機制，即在一定時間內不再發起調用，給予服務提供者一定的恢復時間，等服務提供者恢復正常后再發起調用。這種保護機制大大降低了鏈式異常引起的服務雪崩的可能性。

在實際應用中，熔斷器往往分為三種狀態，打開、半開以及關閉。引用一張畫的原理圖:

在普通情況下，斷路器處于關閉狀態，請求可以正常調用。當請求失敗達到一定閾值條件時，則打開斷路器，禁止向服務提供者發起調用。當斷路器打開后一段時間，會進入一個半開的狀態，此狀態下的請求如果調用成功了則關閉斷路器，如果沒有成功則重新打開斷路器，等待下一次半開狀態周期。

斷路器的實現中比較重要的一點是失敗閾值的設置。可以根據業務需求設置失敗的條件為連續失敗的調用次數，也可以是時間窗口內的失敗比率，失敗比率通過一定的滑動窗口算法進行計算。另外，針對斷路器的半開狀態周期也可以做一些花樣，一種常見的計算方法是周期長度隨著失敗次數呈指數增長。

具體的實現方式可以根據具體業務指定，也可以選擇第三方框架例如。

隔離

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

降級

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

降級往往用于那些錯誤容忍度較高的業務。同時降級的數據如何設置也是一門學問。一種方法是為每個接口預先設置好可接受的降級數據，但這種靜態降級的方法適用性較窄。還有一種方法，是去線上日志系統/流量錄制系統中撈取上一次正確的返回數據作為本次降級數據，但這種方法的關鍵是提供可供穩定抓取請求的日志系統或者流量采樣錄制系統。

參考：面試官：什么是熔斷？什么是服務降級？

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

服務提供者如何保障穩定性

限流

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

閾值的設置可以針對兩個方面考慮，一是QPS即每秒請求數，二是并發線程數。從實踐來看，我們往往會選擇后者，因為QPS高往往是由于處理能力高，并不能反映出系統"不堪重負"。

除此之外，我們還有許多針對限流的算法。例如令牌桶算法以及漏桶算法，主要針對突發流量的狀況做了優化。第三方的實現中例如guava 就實現了令牌桶算法。在此就不就細節展開了。

重啟與回滾

限流更多的起到一種保障的作用，但如果服務提供者已經出現問題了，這時候該怎么辦呢？

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

更多的時候，我們可能僅僅碰到了與代碼無強關聯的單機故障，一個簡單粗暴的辦法就是自動重啟。例如觀察到某個接口的平均耗時超出了正常范圍一定程度，就將該實例進行自動重啟。當然自動重啟需要有很多注意事項，例如重啟時間是否放在晚上，以及自動重啟引起的與上述節點摘除一樣的問題，都需要考慮和處理。

在事后復盤的時候，如果當時沒有保護現場，就很難定位到問題原因。所以往往在一鍵回滾或者自動重啟之前，我們往往需要進行現場保護。現場保護可以是自動的，例如一開始就給jvm加上打印gc日志的參數-XX:+，或者輸出oom文件-XX:+，也可以配合自動腳本完成，當然手動也可以。一般來說我們會如下操作:

調度流量

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

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

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

而當機房炸了、光纜被偷了等IDC故障時，我們又部署了多IDC，也可以通過一些方式將流量切換到正常的IDC，以供服務繼續正常運行。切換流量同樣可以通過微服務的路由實現，但這時候一個IDC對應一個微服務分組了。除此之外打印后臺程序服務沒有運行怎么辦，使用DNS解析進行流量切換也是可以的，將對外域名的VIP從一個IDC切換到另一個IDC。

原文：.xin/-msa--msa

關注公眾號 回復【小抄】【算法】獲取字節跳動2022最新算法資料~，
【開源】【77】獲取大廠面試資料以及上百開源項目資源。


往日文章：
開源推薦， 一個牛逼的后臺管理系統，可直接使用（附源碼）！
開源推薦，一個完整后臺管理系統，熟悉就能掙錢（附源碼）！
開源的 Spring Boot 即時通訊 IM 聊天系統（附源碼）！
看看人家那公眾號管理系統，那叫一個優雅（附源碼）
開源推薦，既能接私活，又能節約企業開發成本，這項目也太香了吧！
最受 IT 公司歡迎的 30 款開源軟件，我竟然都用過！