08 | 服務發現：到底是要CP還是AP？
我們為什么需要“服務發現”？
從高可用的角度出發，在生產環境中，服務提供方通常會以集群的方式對外提供服務，集群中的IP地址隨時可能發生變化，因此我們需要一本“通訊錄”來及時獲取對應的服務節點資訊，維護“通訊錄”以及或者節點資訊的程序，我們稱之為“服務發現”，
服務發現包括2個核心模塊：
- 服務注冊：在服務提供方啟動的時候，將對外暴露的介面注冊到注冊中心中，注冊中心將這個服務節點的IP和介面保存下來，
- 服務訂閱：在服務呼叫方啟動的時候，去注冊中心查找并訂閱服務提供方的IP，然后快取到本地，并用于后續遠程呼叫，
我們為什么不采用基于DNS的服務發現機制？
我們來看一下DNS查詢流程，
它存在的兩個主要問題：
- 如果服務節點的IP埠下線了，服務呼叫者能否及時摘除服務節點？
- 如果之前已經上線了一部分服務節點，這時突然對這個服務進行擴容，那么新上線的服務節點能否及時接收到流程呢？
為什么VIP方案也不能用于服務發現？
VIP方案如下所示，
它主要有以下幾個問題：
- 搭建負載均衡設備或者TCP/IP四層代理，需要額外成本，
- 請求流程都經過負載均衡設備，多經過一次網路傳輸，會額外浪費性能，
- 負載均衡添加節點和摘除節點，一般都需要手動添加，當大批量擴容和下線時，會有大量的人工操作和生效延遲，
- 不能支持更靈活的負載均衡策略，
基于ZooKeeper的服務發現機制的作業流程是怎樣的？
基于ZooKeeper的服務發現結構圖如下，
它的作業流程如下：
- 服務平臺管理端現在ZooKeeper中創建一個服務根路徑，在這個路徑下面再創建服務提供方目錄和服務呼叫方目錄，
- 當服務提供方發起注冊時，會在服務提供方目錄中創建一個臨時節點，節點中存盤該服務提供方的注冊資訊，
- 當服務呼叫方發起注冊時，會在服務提供方目錄中創建一個臨時節點，節點中存盤該服務提供方的注冊資訊，
- 當服務提供方目錄下有節點資料發生變更時，ZooKeeper就會通知給發起訂閱的服務呼叫方，
基于ZooKeeper的服務發現有什么問題？
當有超大批量的服務節點在同時發起注冊操作，ZooKeeper集群的CPU使用率會飆升，導致ZooKeeper集群無法作業，
這本身就是ZooKeeper的性能問題，當連接到ZooKeeper的節點數量特別多，對ZooKeeper的讀寫操作會特別頻繁，而且當ZooKeeper存盤的目錄達到一定數量時，ZooKeeper就會變得不穩定，CPU使用率持續升高，直到宕機，
ZooKeeper的一大特點就是強一致性，集群中的每個節點的資料每次發生變更操作時，都會通知其他節點同時執行跟新，這樣它就要求每個節點的資料能夠實時的完全一致，從而導致了ZooKeeper集群性能的下降，
基于訊息總線的服務發現機制的作業流程是怎樣的？
基于訊息總線的服務發現流程圖如下：
它的作業流程如下：
- 當有服務上線，注冊中心節點收到注冊請求，服務串列資料發生變化，會生成一個訊息，推送給訊息總線，每個訊息都有一個整體遞增版本，
- 訊息總線會主動推送訊息到各個注冊中心，同時注冊中心也會定期拉取訊息，對于獲取到訊息的在訊息回放模塊里面回放只接受大于本地版本號的訊息，小于本地版本號的訊息直接丟棄，從而實作最終一致性，
- 消費者定于可以從注冊中心記憶體拿到指定介面的全部服務實體，并快取到消費者的記憶體中，
- 采取推拉模式，消費者可以及時地拿到服務實體增量變化情況，并和記憶體中的混存資料進行合并，
通過訊息總線的方式，我們就可以完成注冊中心集群間資料變更的通知，保證資料的最終一致性，并能及時地觸發注冊中心的服務下發操作，
服務發現的特性是允許我們在設計超大規模集群服務發現系統的時候，舍棄一致性，更多的考慮系統的健壯性，因此，在實際作業中，最終一致性是更為常用的策略，
作者：李潘 出處：http://wing011203.cnblogs.com/ 本文著作權歸作者和博客園共有，歡迎轉載，但未經作者同意必須保留此段宣告，且在文章頁面明顯位置給出原文連接，否則保留追究法律責任的權利，轉載請註明出處，本文鏈接：https://www.uj5u.com/houduan/542378.html
標籤：其他