[[322354]]

問題緣由

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

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

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

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

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

服務啟動的時候，把服務信息注冊(put)到服務注冊表;服務終止的時候，從服務注冊表刪除(remove)自身的服務信息。

服務消費者在請求服務的時候，先去服務注冊表按名查詢(get)服務提供者列表，然后從列表里挑選一個服務實例，向該實例請求服務。

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

問題和解法

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

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

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

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

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

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

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

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

優(yōu)點

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

缺點

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

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

發(fā)現(xiàn)：服務消費者通過負載均衡器發(fā)送服務請求，負載均衡器會查詢服務注冊表，挑選一個服務實例，并將請求轉(zhuǎn)發(fā)到服務實例。

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

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

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

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

優(yōu)點

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

缺點

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

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

Service Mesh服務網(wǎng)格是服務于微服務應用程序的可配置基礎設施層，旨在處理服務之間的大量基于網(wǎng)絡的進程間通信。

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

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

服務注冊模式

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

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

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

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

其他

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