前言
按照目前市場上的主流使用場景，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 提供的這些模型也不一定所有都需要用上，例如集羣、分組、權重等概念，被實踐證明是相對雞肋的設計，在使用時，也需要根據自身業務特點去評估特性用量，不要盲目地爲了使用技術而去用。
- END -
「技術分享」某種程度上，是讓作者和讀者，不那麼孤獨的東西。歡迎關注我的微信公衆號：「Kirito的技術分享」
文章有幫助的話記得一鍵三連哦！
關注，在看，轉發。
謝謝支持喲 (*^__^*）
本文分享自微信公衆號 - Kirito的技術分享（cnkirito）。
如有侵權，請聯繫 [email protected] 刪除。
本文參與“OSC源創計劃”，歡迎正在閱讀的你也加入，一起分享。