[[322354]]

問題緣由

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

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

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

服務發現

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

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

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

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

問題和解法

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

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

服務發現模式

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

客戶端發現模式 

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

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

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

優點

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

缺點

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

服務端發現模式

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

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

對比客戶端發現模式，使用服務端發現模式的客戶端本地不保存服務實例列表，客戶端不做負載均衡，這個負載均衡器既承擔了服務發現的角色，又承擔了網關的角色，所以經常叫API網關服務器。

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

Http服務器，Nginx、Nginx Plus就是此類服務端發現模式的負載均衡器。

優點

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

缺點

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

微服務和服務發現

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

Service Mesh服務網關解耦調用和通信，在非mesh下，對于協議的感知和服務發現方法的感知需要應用去做，用mesh之后，就只管調用，mesh通過控制面來控制應用的數據流。

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

服務注冊模式

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

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

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

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

其他

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