小白也能懂的 Nacos 服務模型介紹

簡介： 理解了 Nacos 的服務模型，也有利於我們了解 Nacos 背后的工作原理，從而確保我們正確地使用 Nacos。

作者：島風

前言

 

按照目前市場上的主流使用場景，Nacos 被分成了兩塊功能：服務注冊發現（Naming）和配置中心（Config）。在之前的文章中我介紹了 Nacos 配置中心的實現原理，今天這篇文章所介紹的內容則是與 Nacos 服務注冊發現功能相關，來聊一聊 Nacos 的服務模型。

 

說到服務模型，其實需要區分視角，一是用戶視角，一個內核視角。即 Nacos 用戶視角看到的服務模型和 Nacos 開發者設計的內核模型可能是完全不一樣的，而今天的文章，是站在用戶視角觀察的，旨在探討 Nacos 服務發現的最佳實踐。

 

服務模型介紹

 

一般我在聊注冊中心時，都會以 Zookeeper 為引子，這也是很多人最熟悉的注冊中心。但如果你真的寫過或看過使用 Zookeeper 作為注冊中心的適配代碼，會發現並不是那么容易，再加上注冊中心涉及到的一致性原理，這就導致很多人對注冊中心的第一印象是：這個東西好難！ 但歸根到底是因為 Zookeeper 根本不是專門為注冊中心而設計的，其提供的 API 以及內核設計，並沒有預留出「服務模型」的概念，這就使得開發者需要自行設計一個模型，去填補 Zookeeper 和服務發現之間的鴻溝。

 

微服務架構逐漸深入人心后，Nacos、Consul、Eureka 等注冊中心組件進入大眾的視線。可以發現，這些”真正“的注冊中心都有各自的「服務模型」，在使用上也更加的方便。

 

為什么要有「服務模型」？理論上，一個基礎組件可以被塑造成任意的模樣，如果你願意，一個數據庫也可以被設計成注冊中心，這並不是”誇張“的修辭手法，在阿里還真有人這么干過。那么代價是什么呢？一定會在業務發展到一定體量后遇到瓶頸，一定會遇到某些極端 case 導致其無法正常工作，一定會導致其擴展性低下。正如剛學習數據結構時，同學們常見的一個疑問一樣：為什么棧只能先進后出。不是所有開發都是中間件專家，所以 Nacos 設計了自己的「服務模型」，這雖然限制了使用者的”想象力“，但保障了使用者在正確地使用 Nacos。

 

花了一定的篇幅介紹 Nacos 為什么需要設計「服務模型」，再來看看實際的 Nacos 模型是個啥，其實沒那么玄乎，一張圖就能表達清楚：

 

 

與 Consul、Eureka 設計有別，Nacos 服務發現使用的領域模型是命名空間-分組-服務-集群-實例這樣的多層結構。服務 Service 和實例 Instance 是核心模型，命名空間 Namespace 、分組 Group、集群 Cluster 則是在不同粒度實現了服務的隔離。

 

為了更好的理解兩個核心模型：Service 和 Instance，我們以 Dubbo 和 SpringCloud 這兩個已經適配了 Nacos 注冊中心的微服務框架為例，介紹下二者是如何映射對應模型的。

 

• Dubbo。將接口三元組（接口名+分組名+版本號）映射為 Service，將實例 IP 和端口號定義為 Instance。一個典型的注冊在 Nacos 中的 Dubbo 服務：providers:com.alibaba.mse.EchoService:1.0.0:DUBBO
• Spring Cloud。將應用名映射為 Service，將實例 IP 和端口號定義為 Instance。一個典型的注冊在 Nacos 中的 Spring Cloud 服務：helloApp

 

下面我們將會更加詳細地闡釋 Nacos 提供的 API 和服務模型之間的關系。

 

環境准備

 

需要部署一個 Nacos Server 用於測試，我這里選擇直接在 https://mse.console.aliyun.com/ 購買一個 MSE 托管的 Nacos，讀者們可以選擇購買 MSE Nacos 或者自行搭建一個 Nacos Server。

 

 

MSE Nacos 提供的可視化控制台，也可以幫助我們更好的理解 Nacos 的服務模型。下文的一些截圖，均來自 MSE Nacos 的商業化控制台。

 

快速開始

 

先來實現一個最簡單的服務注冊與發現 demo。Nacos 支持從客戶端注冊服務實例和訂閱服務，具體代碼如下：

 

Properties properties = new Properties(); properties.setProperty(PropertyKeyConst.SERVER_ADDR, "mse-xxxx-p.nacos-ans.mse.aliyuncs.com:8848");  String serviceName = "nacos.test.service.1"; String instanceIp = InetAddress.getLocalHost().getHostAddress(); int instancePort = 8080;  namingService.registerInstance(serviceName, instanceIp, instancePort);  System.out.println(namingService.getAllInstances(serviceName));

 

上述代碼定義了一個 service：nacos.test.service.1；定義了一個 instance，以本機 host 為 IP 和 8080 為端口號，觀察實際的注冊情況：

 

 

 

並且控制台也打印出了服務的詳情。至此一個最簡單的 Nacos 服務發現 demo 就已經完成了。對一些細節稍作解釋：

 

• 屬性 PropertyKeyConst.SERVER_ADDR 表示的是 Nacos 服務端的地址。
• 創建一個 NamingService 實例，客戶端將為該實例創建單獨的資源空間，包括緩存、線程池以及配置等。Nacos 客戶端沒有對該實例做單例的限制，請小心維護這個實例，以防新建多於預期的實例。
• 注冊服務 registerInstance 使用了最簡單的重載方法，只需要傳入服務名、IP、端口就可以。

 

上述的例子中，並沒有出現 Namespace、Group、Cluster 等前文提及的服務模型，我會在下面一節詳細介紹，這個例子主要是為了演示 Nacos 支持的一些缺省配置，其中 Service 和 Instance 是必不可少的，這也驗證了前文提到的服務和實例是 Nacos 的一等公民。

 

通過截圖我們可以發現缺省配置的默認值：

 

• Namespace：默認值是 public 或者空字符串，都可以代表默認命名空間。
• Group：默認值是 DEFAULT_GROUP。
• Cluster：默認值是 DEFAULT。

 

構建自定義實例

 

為了展現出 Nacos 服務模型的全貌，還需要介紹下實例相關的 API。例如我們希望注冊的實例中，有一些能夠被分配更多的流量；或者能夠傳入一些實例的元信息存儲到 Nacos 服務端，例如 IP 所屬的應用或者所在的機房，這樣在客戶端可以根據服務下掛載的實例元信息，來自定義負載均衡模式。Nacos 也提供了另外的注冊實例接口，使得用戶在注冊實例時可以指定實例的屬性：

 

/**  * register a instance to service with specified instance properties.  *  * @param serviceName name of service  * @param groupName group of service  * @param instance instance to register  * @throws NacosException nacos exception  */ void registerInstance(String serviceName, String groupName, Instance instance) throws NacosException;

 

這個方法在注冊實例時，可以傳入一個 Instance 實例，它的屬性如下：

 

public class Instance {   /**  * unique id of this instance.  */  private String instanceId;   /**  * instance ip.  */  private String ip;   /**  * instance port.  */  private int port;   /**  * instance weight.  */  private double weight = 1.0D;   /**  * instance health status.  */  private boolean healthy = true;   /**  * If instance is enabled to accept request.  */  private boolean enabled = true;   /**  * If instance is ephemeral.  *  * @since 1.0.0  */  private boolean ephemeral = true;   /**  * cluster information of instance.  */  private String clusterName;   /**  * Service information of instance.  */  private String serviceName;   /**  * user extended attributes.  */  private Map<String, String> metadata = new HashMap<String, String>(); }

 

有一些字段可以望文生義，有一些則需要花些功夫專門去了解 Nacos 的設計，我這里挑選幾個我認為重要的屬性重點介紹下：

 

• healthy 實例健康狀態。標識該實例是否健康，一般心跳健康檢查會自動更新該字段。
• enable 是否啟用。它跟 healthy 區別在於，healthy 一般是由內核健康檢查更新，而 enable 更多是業務語義偏多，可以完全根據業務場景操控。例如在 Dubbo 中，一般使用該字段標識某個實例 IP 的上下線狀態。
• ephemeral 臨時實例還是持久化實例。非常關鍵的一個字段，需要對 Nacos 有較為深入的了解才能夠理解該字段的含義。區別在於，心跳檢測失敗一定時間之后，實例是自動下線還是標記為不健康。一般在注冊中心場景下，會使用臨時實例。這樣心跳檢測失敗之后，可以讓消費者及時收到下線通知；而在 DNS 模式下，使用持久化實例較多。在《一文詳解 Nacos 高可用特性》中我也介紹過，該字段還會影響到 Nacos 的一致性協議。
• metadata 元數據。一個 map 結構，可以存儲實例的自定義擴展信息，例如機房信息，路由標簽，應用信息，權重信息等。

 

這些信息在由服務提供者上報之后，由服務消費者獲取，從而完成信息的傳遞。以下是一個完整的實例注冊演示代碼：

 

Properties properties = new Properties(); // 指定 Nacos Server 地址 properties.setProperty(PropertyKeyConst.SERVER_ADDR, "mse-xxxx-p.nacos-ans.mse.aliyuncs.com:8848"); // 指定命名空間 properties.setProperty(PropertyKeyConst.NAMESPACE, "9125571e-bf50-4260-9be5-18a3b2e3605b");  NamingService namingService = NacosFactory.createNamingService(properties); String serviceName = "nacos.test.service.1"; String group = "DEFAULT_GROUP"; String clusterName = "cn-hangzhou"; String instanceIp = InetAddress.getLocalHost().getHostAddress(); int instancePort = 8080; Instance instance = new Instance(); // 指定集群名 instance.setClusterName(clusterName); instance.setIp(instanceIp); instance.setPort(instancePort); // 指定實例的元數據 Map<String, String> metadata = new HashMap<>(); metadata.put("app", "nacos-demo"); metadata.put("site", "cn-hangzhou"); metadata.put("protocol", "1.3.3"); instance.setMetadata(metadata); // 指定服務名、分組和實例 namingService.registerInstance(serviceName, group, instance);  System.out.println(namingService.getAllInstances(serviceName));

 

 

 

構建自定義服務

 

除了實例之外，服務也可以自定義配置，Nacos 的服務隨着實例的注冊而存在，並隨着所有實例的注銷而消亡。不過目前 Nacos 對於自定義服務的支持不是很友好，除使用 OpenApi 可以修改服務的屬性外，就只能使用注冊實例時傳入的服務屬性來進行自定義配置。所以在實際的 Dubbo 和 SpringCloud 中，自定義服務一般較少使用，而自定義實例信息則相對常用。

 

Nacos 的服務與 Consul、Eureka 的模型都不同，Consul 與 Eureka的服務等同於 Nacos 的實例，每個實例有一個服務名屬性，服務本身並不是一個單獨的模型。Nacos 的設計在我看來更為合理，其認為服務本身也是具有數據存儲需求的，例如作用於服務下所有實例的配置、權限控制等。實例的屬性應當繼承自服務的屬性，實例級別可以覆蓋服務級別。以下是服務的數據結構：

 

/**  * Service name  */  private String name;   /**  * Protect threshold  */  private float protectThreshold = 0.0F;   /**  * Application name of this service  */  private String app;   /**  * Service group which is meant to classify services into different sets.  */  private String group;   /**  * Health check mode.  */  private String healthCheckMode;   private Map<String, String> metadata = new HashMap<String, String>();

 

在實際使用過程中，可以像快速開始章節中介紹的那樣，僅僅使用 ServiceName 標記一個服務。

 

服務隔離：Namespace&Group&Cluster

 

出於篇幅考慮，這三個概念放到一起介紹。

 

襄王有意，神女無心。Nacos 提出了這幾種隔離策略，目前看來只有 Namespace 在實際應用中使用較多，而 Group 和 Cluster 並沒有被當回事。

 

Cluster 集群隔離在阿里巴巴內部使用的非常普遍。一個典型的場景是這個服務下的實例，需要配置多種健康檢查方式，有一些實例使用 TCP 的健康檢查方式，另外一些使用 HTTP 的健康檢查方式。另一個場景是，服務下掛載的機器分屬不同的環境，希望能夠在某些情況下將某個環境的流量全部切走，這樣可以通過集群隔離，來做到一次性切流。在 Nacos 2.0 中，也在有意的弱化集群的概念，畢竟開源還是要面向用戶的，有些東西適合阿里，但不一定適合開源，等再往后演進，集群這個概念又有可能重新回到大家的視線中了，history will repeat itself。

 

Group 分組隔離的概念可以參考 Dubbo 的服務隔離策略，其也有一個分組。支持分組的擴展，用意當然是好的，實際使用上，也的確有一些公司會習慣使用分組來進行隔離。需要注意的一點是：Dubbo 注冊三元組（接口名+分組+版本）時，其中 Dubbo 的分組是包含在 Nacos 的服務名中的，並不是映射成了 Nacos 的分組，一般 Nacos 注冊的服務是默認注冊到 DEFAULT_GROUP 分組的。

 

Namespace 命名空間隔離，我認為是 Nacos 一個比較好的設計。在實際場景中使用也比較普遍，一般用於多個環境的隔離，例如 daily，dev，test，uat，prod 等環境的隔離。特別是當環境非常多時，使用命名空間做邏輯隔離是一個比較節約成本的策略。但強烈建議大家僅僅在非線上環境使用 Namespace 進行隔離，例如多套測試環境可以共享一套 Nacos，而線上環境單獨搭建另一套 Nacos 集群，以免線下測試流量干擾到線上環境。

 

服務發現：推拉模型

 

上面介紹完了 Nacos 服務發現的 5 大領域模型，最后一節，介紹下如何獲取服務模型。

 

Nacos 的服務發現，有主動拉取和推送兩種模式，這與一般的服務發現架構相同。以下是拉模型的相關接口：

 

/**  * Get all instances of a service  *  * @param serviceName name of service  * @return A list of instance  * @throws NacosException  */ List<Instance> getAllInstances(String serviceName) throws NacosException;  /**  * Get qualified instances of service  *  * @param serviceName name of service  * @param healthy a flag to indicate returning healthy or unhealthy instances  * @return A qualified list of instance  * @throws NacosException  */ List<Instance> selectInstances(String serviceName, boolean healthy) throws NacosException;  /**  * Select one healthy instance of service using predefined load balance strategy  *  * @param serviceName name of service  * @return qualified instance  * @throws NacosException  */ Instance selectOneHealthyInstance(String serviceName) throws NacosException;

 

Nacos 提供了三個同步拉取服務的方法，一個是查詢所有注冊的實例，一個是只查詢健康且上線的實例，還有一個是獲取一個健康且上線的實例。一般情況下，訂閱端並不關心不健康的實例或者權重設為 0 的實例，但是也不排除一些場景下，有一些運維或者管理的場景需要拿到所有的實例。細心的讀者會注意到上述 Nacos 實例中有一個 weight 字段，便是作用在此處的selectOneHealthyInstance接口上，按照權重返回一個健康的實例。個人認為這個功能相對雞肋，一般的 RPC 框架都有自身配套的負載均衡策略，很少會由注冊中心 cover，事實上 Dubbo 和 Spring Cloud 都沒有用到 Nacos 的這個接口。

 

除了主動查詢實例列表，Nacos還提供訂閱模式來感知服務下實例列表的變化，包括服務配置或者實例配置的變化。可以使用下面的接口來進行訂閱或者取消訂閱：

 

/**  * Subscribe service to receive events of instances alteration  *  * @param serviceName name of service  * @param listener event listener  * @throws NacosException  */ void subscribe(String serviceName, EventListener listener) throws NacosException; /**  * Unsubscribe event listener of service  *  * @param serviceName name of service  * @param listener event listener  * @throws NacosException  */ void unsubscribe(String serviceName, EventListener listener) throws NacosException;

 

在實際的服務發現中，訂閱接口尤為重要。消費者啟動時，一般會同步獲取一次服務信息用於初始化，緊接着訂閱服務，這樣當服務發生上下線時，就可以感知變化了，從而實現服務發現。

 

總結

 

Nacos 為了更好的實現服務發現，提供一套成熟的服務模型，其中重點需要關注的是 Namespace、Service 和 Instance，得益於這一套服務模型的抽象，以及對推拉模型的支持，Nacos 可以快速被微服務框架集成。

 

理解了 Nacos 的服務模型，也有利於我們了解 Nacos 背后的工作原理，從而確保我們正確地使用 Nacos。但 Nacos 提供的這些模型也不一定所有都需要用上，例如集群、分組、權重等概念，被實踐證明是相對雞肋的設計，在使用時，也需要根據自身業務特點去評估特性用量，不要盲目地為了使用技術而去用。

原文鏈接

本文為阿里雲原創內容，未經允許不得轉載。