[[322354]]

問題緣由

單機(jī)時(shí)代，傳統(tǒng)軟件大多是單體/巨石架構(gòu)(Monolithic)。大家往一個(gè)代碼倉(cāng)庫(kù)提交CODE，這會(huì)導(dǎo)致應(yīng)用膨脹，難以理解和修改，以及擴(kuò)展受限，無法按需伸縮等諸多問題。單體架構(gòu)怎么解決多人合作的問題?模塊化，對(duì)，按功能拆分，模塊之間定義編程接口(API)，彼此關(guān)心功能而不關(guān)心實(shí)現(xiàn)。

隨著時(shí)代發(fā)展，單機(jī)程序遇到了計(jì)算力和存儲(chǔ)的雙重瓶頸，分布式架構(gòu)應(yīng)運(yùn)而生。單體應(yīng)用通過函數(shù)名(標(biāo)識(shí))便可輕松完成本地函數(shù)調(diào)用，在分布式系統(tǒng)中，服務(wù)(RPC/RESTful API)承擔(dān)了類似的角色，但請(qǐng)求服務(wù)單靠服務(wù)名還不夠，服務(wù)名只是服務(wù)能力(服務(wù)類型)的標(biāo)識(shí)，還需要指示服務(wù)位于網(wǎng)絡(luò)何處，而部署在云中的服務(wù)實(shí)例IP是動(dòng)態(tài)分配的，擴(kuò)縮容、失敗和更新則讓問題變得更加復(fù)雜，靜態(tài)配置服務(wù)實(shí)例適應(yīng)不了新變化，需要更精細(xì)化的服務(wù)治理能力，為了解決或者說簡(jiǎn)化這個(gè)問題，服務(wù)發(fā)現(xiàn)作為一種基礎(chǔ)能力被抽象和提供，它試圖讓請(qǐng)求網(wǎng)絡(luò)服務(wù)像調(diào)用本地函數(shù)一樣簡(jiǎn)單透明。

服務(wù)即功能(函數(shù))。只是服務(wù)跟網(wǎng)絡(luò)緊密聯(lián)系在一起，所有才會(huì)出現(xiàn)網(wǎng)絡(luò)服務(wù)這個(gè)名詞，服務(wù)提供者通過網(wǎng)絡(luò)發(fā)布服務(wù)，服務(wù)使用者通過網(wǎng)絡(luò)請(qǐng)求服務(wù)，分布式系統(tǒng)突破了單機(jī)算力和存儲(chǔ)的限制，提升了系統(tǒng)穩(wěn)定性，使得高并發(fā)高可用的海量服務(wù)成為可能，但這也增加了軟件復(fù)雜度，引入軟件分層、負(fù)載均衡、微服務(wù)、服務(wù)發(fā)現(xiàn)/治理、分布式一致性等新的問題和挑戰(zhàn)。

服務(wù)發(fā)現(xiàn)

服務(wù)分服務(wù)提供者(Service Provider)和服務(wù)消費(fèi)者(Service Consumer)，如果要提供海量服務(wù)能力，單一的服務(wù)實(shí)例顯然是不夠的，如果要提供成千上萬種服務(wù)，則需要有一個(gè)地方記錄服務(wù)名到服務(wù)實(shí)例列表的映射，所以，有必要引入一個(gè)新的角色：服務(wù)中介，服務(wù)中介維護(hù)一個(gè)服務(wù)注冊(cè)表(Service Registry)，可以把注冊(cè)表理解為服務(wù)字典，key是服務(wù)名，value是服務(wù)提供實(shí)例列表;服務(wù)注冊(cè)表是聯(lián)系服務(wù)提供者和服務(wù)消費(fèi)者的橋梁，它維護(hù)服務(wù)提供者的最新網(wǎng)絡(luò)位置等信息，也是服務(wù)發(fā)現(xiàn)最核心的部分。

服務(wù)啟動(dòng)的時(shí)候，把服務(wù)信息注冊(cè)(put)到服務(wù)注冊(cè)表;服務(wù)終止的時(shí)候，從服務(wù)注冊(cè)表刪除(remove)自身的服務(wù)信息。

服務(wù)消費(fèi)者在請(qǐng)求服務(wù)的時(shí)候，先去服務(wù)注冊(cè)表按名查詢(get)服務(wù)提供者列表，然后從列表里挑選一個(gè)服務(wù)實(shí)例，向該實(shí)例請(qǐng)求服務(wù)。

大道至簡(jiǎn)，這便是最簡(jiǎn)單的服務(wù)發(fā)現(xiàn)模型，也是服務(wù)發(fā)現(xiàn)的基本原理，至此，似乎一切都OK，但其實(shí)尚有幾個(gè)問題沒有說清楚。

問題和解法

• 第一個(gè)問題，服務(wù)如果不是正常停止，而是被系統(tǒng)kill掉，它便沒有機(jī)會(huì)通知服務(wù)注冊(cè)表把自身服務(wù)信息刪除，這樣注冊(cè)表便多了一條指向無效服務(wù)實(shí)例的信息，而服務(wù)消費(fèi)者卻并不知情，怎么辦?解決的辦法很簡(jiǎn)單：?；?keepalive)，服務(wù)提供者定期(比如每隔10秒)給服務(wù)中介發(fā)送keepalive消息，服務(wù)中介收到keepalive消息后更新該服務(wù)實(shí)例的keepalive timestamp，服務(wù)中介定期檢查該timestamp，如果超期便把該服務(wù)實(shí)例從注冊(cè)表剔除。
• 第二個(gè)問題，服務(wù)實(shí)例列表變化如何通知服務(wù)消費(fèi)者?不外乎兩種方法，輪詢和pub-sub。輪詢是消費(fèi)者主動(dòng)詢問服務(wù)中介服務(wù)列表是否變化，如果有變化，則把新的服務(wù)列表發(fā)送給消費(fèi)者。如果消費(fèi)者過多，則服務(wù)中介處理輪詢的消息會(huì)有壓力，在服務(wù)類別很多，服務(wù)列表很大的時(shí)候，它甚至?xí)蔀槠款i。pub-sub是服務(wù)中介主動(dòng)通知服務(wù)消費(fèi)者，時(shí)效性相比輪詢更好，缺點(diǎn)是會(huì)占用單獨(dú)的線程或者連接資源。

• 第三個(gè)問題，服務(wù)中介如果掛了怎么辦?所以我們要解決單點(diǎn)的問題，通常會(huì)用集群來對(duì)抗這種脆弱性，有很多用于做服務(wù)注冊(cè)表的開源解決方案，比如etcd/zookeeper/consul，本質(zhì)上使用分布式一致性數(shù)據(jù)庫(kù)來保存注冊(cè)表信息，它既解決讀寫性能問題又提高了系統(tǒng)穩(wěn)定性可用性。
• 第四個(gè)問題，如果服務(wù)消費(fèi)者每次使用遠(yuǎn)程服務(wù)都需要先查詢服務(wù)中介獲取實(shí)例列表，再請(qǐng)求服務(wù)，這樣效率太低效?對(duì)服務(wù)中介的壓力也不小?通常，客戶端會(huì)緩存服務(wù)實(shí)例列表，這樣對(duì)同名服務(wù)的多次請(qǐng)求，便不用重復(fù)查詢，既減少了延遲又減輕了對(duì)服務(wù)中介的訪問壓力。
• 第五個(gè)問題，前述的keepalive有間隔，如果在這個(gè)間隔內(nèi)服務(wù)實(shí)例不可用，那么服務(wù)消費(fèi)者還是不能感知的，所以還是有可能把請(qǐng)求發(fā)送到一個(gè)無法提供服務(wù)的網(wǎng)絡(luò)遠(yuǎn)端機(jī)器上去，這樣自然是沒法work。我們無法從根本上杜絕這種情況，系統(tǒng)需要容忍這種錯(cuò)誤，但也可以做一些改進(jìn)，比如向某實(shí)例請(qǐng)求服務(wù)失敗后便拉黑，避免向同一無效服務(wù)實(shí)例多次派發(fā)請(qǐng)求。
• 第六個(gè)問題，服務(wù)消費(fèi)者怎么從多個(gè)服務(wù)實(shí)例里選擇一個(gè)?如何確保同一服務(wù)消費(fèi)者的多次服務(wù)請(qǐng)求被分配到固定的服務(wù)實(shí)例(有時(shí)候需要這樣)?這其實(shí)就是負(fù)載均衡的問題，有多種策略，比如rr、優(yōu)先級(jí)、比如加權(quán)隨機(jī)、一致性哈希。

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

服務(wù)發(fā)現(xiàn)主要有兩種模式：客戶端發(fā)現(xiàn)模式(client-side discovery)和服務(wù)端發(fā)現(xiàn)模式(server-side discovery)。

客戶端發(fā)現(xiàn)模式 

客戶端負(fù)責(zé)查詢服務(wù)實(shí)例列表并決定向哪個(gè)實(shí)例請(qǐng)求服務(wù)，也就是負(fù)載均衡策略在客戶端實(shí)現(xiàn)。該模式包括注冊(cè)和發(fā)現(xiàn)兩個(gè)部分。

服務(wù)實(shí)例調(diào)用服務(wù)中介的注冊(cè)接口進(jìn)行實(shí)例注冊(cè)，服務(wù)實(shí)例通過keepalive做服務(wù)續(xù)期，服務(wù)中介通過健康檢查剔除不可用的服務(wù)實(shí)例。

服務(wù)消費(fèi)者請(qǐng)求服務(wù)的時(shí)候，先向服務(wù)注冊(cè)表查詢服務(wù)實(shí)例列表，注冊(cè)表是一個(gè)服務(wù)數(shù)據(jù)庫(kù)，為了提升性能和可靠性，客戶端通常會(huì)緩存服務(wù)列表(緩存用來確保注冊(cè)表掛了之后還能繼續(xù)工作)，拿到實(shí)例列表后客戶端基于負(fù)載均衡策略挑選一個(gè)實(shí)例發(fā)送服務(wù)請(qǐng)求。

優(yōu)點(diǎn)

• 直接，客戶端可以靈活的執(zhí)行負(fù)載均衡策略。
• 去中心化，非網(wǎng)關(guān)式，有效避開單點(diǎn)瓶頸和可靠性下降。
• 服務(wù)發(fā)現(xiàn)直接SDK集成進(jìn)客戶端，這種語(yǔ)言整合程度很好，程序執(zhí)行性能也很好，排錯(cuò)方便。

缺點(diǎn)

• 客戶端與服務(wù)注冊(cè)表耦合，需要為服務(wù)客戶端使用的每種語(yǔ)言每種框架開發(fā)服務(wù)發(fā)現(xiàn)邏輯。
• 這種侵入式的集成會(huì)導(dǎo)致任何服務(wù)發(fā)現(xiàn)的變化都需要客戶端應(yīng)用程序重新編譯和部署，強(qiáng)綁定違背了獨(dú)立性原則。
• 服務(wù)上下線會(huì)對(duì)調(diào)用方有影響，導(dǎo)致服務(wù)短暫不可用。

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

發(fā)現(xiàn)：服務(wù)消費(fèi)者通過負(fù)載均衡器發(fā)送服務(wù)請(qǐng)求，負(fù)載均衡器會(huì)查詢服務(wù)注冊(cè)表，挑選一個(gè)服務(wù)實(shí)例，并將請(qǐng)求轉(zhuǎn)發(fā)到服務(wù)實(shí)例。

注冊(cè)：服務(wù)注冊(cè)/注銷可以跟上述客戶端發(fā)現(xiàn)模式一致，也可以通過部署平臺(tái)的內(nèi)置服務(wù)注冊(cè)和發(fā)現(xiàn)機(jī)制完成，即容器化部署平臺(tái)(docker/k8s)能主動(dòng)發(fā)現(xiàn)服務(wù)實(shí)例并幫助服務(wù)實(shí)例完成注冊(cè)注銷。

對(duì)比客戶端發(fā)現(xiàn)模式，使用服務(wù)端發(fā)現(xiàn)模式的客戶端本地不保存服務(wù)實(shí)例列表，客戶端不做負(fù)載均衡，這個(gè)負(fù)載均衡器既承擔(dān)了服務(wù)發(fā)現(xiàn)的角色，又承擔(dān)了網(wǎng)關(guān)的角色，所以經(jīng)常叫API網(wǎng)關(guān)服務(wù)器。

因?yàn)樨?fù)載均衡器是中心式的，所以它也必須是一個(gè)集群，單個(gè)實(shí)例不足以支撐高并發(fā)訪問，針對(duì)負(fù)載均衡器本身的服務(wù)發(fā)現(xiàn)和負(fù)載均衡通常借助DNS。

Http服務(wù)器，Nginx、Nginx Plus就是此類服務(wù)端發(fā)現(xiàn)模式的負(fù)載均衡器。

優(yōu)點(diǎn)

• 服務(wù)發(fā)現(xiàn)對(duì)于服務(wù)消費(fèi)者是透明的，服務(wù)消費(fèi)者與注冊(cè)表解耦，服務(wù)發(fā)現(xiàn)功能的更新對(duì)客戶端無感知。
• 服務(wù)消費(fèi)者只需要向負(fù)載均衡器發(fā)送請(qǐng)求，不需要為每種服務(wù)消費(fèi)者的編程語(yǔ)言和框架，開發(fā)服務(wù)發(fā)現(xiàn)邏輯SDK。

缺點(diǎn)

• 由于所有請(qǐng)求都要經(jīng)負(fù)載均衡器轉(zhuǎn)發(fā)，所以負(fù)載均衡器有可能成為新的性能瓶頸。
• 負(fù)載均衡器(服務(wù)網(wǎng)關(guān))是中心式的，而中心式的架構(gòu)會(huì)有穩(wěn)定性的隱憂。
• 因?yàn)樨?fù)載均衡器轉(zhuǎn)發(fā)請(qǐng)求，所以RT會(huì)比客戶端直連模式高。

微服務(wù)和服務(wù)發(fā)現(xiàn)

Service Mesh服務(wù)網(wǎng)格是服務(wù)于微服務(wù)應(yīng)用程序的可配置基礎(chǔ)設(shè)施層，旨在處理服務(wù)之間的大量基于網(wǎng)絡(luò)的進(jìn)程間通信。

Service Mesh服務(wù)網(wǎng)關(guān)解耦調(diào)用和通信，在非mesh下，對(duì)于協(xié)議的感知和服務(wù)發(fā)現(xiàn)方法的感知需要應(yīng)用去做，用mesh之后，就只管調(diào)用，mesh通過控制面來控制應(yīng)用的數(shù)據(jù)流。

Mesh做服務(wù)發(fā)現(xiàn)其實(shí)是客戶端發(fā)現(xiàn)模式的升級(jí)版，基于sidecar和pilot實(shí)現(xiàn)，Sidecars，即數(shù)據(jù)面板(Data Plane)，負(fù)責(zé)發(fā)現(xiàn)目標(biāo)服務(wù)實(shí)例地址列表并轉(zhuǎn)發(fā)請(qǐng)求。Pilots，即控制面板(Control Plane)，負(fù)責(zé)管理服務(wù)注冊(cè)表的所有服務(wù)注冊(cè)信息。

服務(wù)注冊(cè)模式

一個(gè)選擇是服務(wù)實(shí)例自注冊(cè)，即self-registration模式。另一種選擇是其它的系統(tǒng)組件來管理服務(wù)實(shí)例的注冊(cè)，即third-party registration模式。

自注冊(cè)模式如前面所述，它足夠簡(jiǎn)單，不需要第三方組件，缺點(diǎn)是必須為服務(wù)中用到的每種編程語(yǔ)言與框架實(shí)現(xiàn)注冊(cè)代碼。

第三方注冊(cè)服務(wù)實(shí)例不會(huì)自己完成注冊(cè)注銷，它由另一個(gè)叫做Service Registrar的系統(tǒng)組件負(fù)責(zé)，該組件會(huì)輪詢部署環(huán)境或者跟蹤訂閱事件去感知服務(wù)實(shí)例的變化，幫助服務(wù)實(shí)例完成自動(dòng)化注冊(cè)注銷。

Third-party registration模式主要的優(yōu)勢(shì)在于解耦了服務(wù)和服務(wù)注冊(cè)表。不需要為每個(gè)語(yǔ)言和框架都實(shí)現(xiàn)服務(wù)注冊(cè)邏輯。服務(wù)實(shí)例注冊(cè)由一個(gè)專用的服務(wù)集中實(shí)現(xiàn)。缺點(diǎn)是除了被內(nèi)置到部署環(huán)境中，它本身也是一個(gè)高可用的系統(tǒng)組件，需要被啟動(dòng)和管理。

其他

如果某個(gè)服務(wù)對(duì)于的服務(wù)實(shí)例特別多，比如在一些頭部公司，一個(gè)服務(wù)名可能對(duì)應(yīng)幾千幾萬個(gè)服務(wù)實(shí)例，這樣，服務(wù)變更的查詢和對(duì)比會(huì)很慢，IO的量會(huì)大得超過想象，通常，會(huì)用version num去解決這個(gè)問題。