從 2018 年 Nacos 開源說起

2018 年夏天

國內微服務開源 領域，迎來了一位新成員。此後，在構建微服務註冊中心和配置中心的過程中，國內開發者多了一個可信賴的選項。

Nacos 是阿里巴巴開源的一個更易於構建雲原生應用的動態服務發現、配置管理和服務管理平臺(官方網站)，它凝聚了阿里巴巴十多年來在超大規模註冊和配置上的最佳實踐，可以用在微服務場景作為服務註冊中心、配置中心等核心場景中，和阿里的其他微服務開源項目一樣，Nacos 也是始於阿里，成長於社區的典型。

為什麼要開源 Nacos ？

在大規模服務發現和服務治理領域，現有的開源解決方案並非已經非常完美，阿里巴巴從 IOE 集中式應用架構升級為互聯網分佈式服務化架構的演進過程中，積累了大量有關服務註冊和服務配置的實踐經驗，而這些經驗是可以在各個行業大規模複用。除此之外，更重要的是，希望和社區開發者共同發展，讓 Nacos 可以幫助國內企業更自由的構建基於雲原生應用的動態服務發現、配置和服務管理。

相比其他服務註冊和配置中心開源方案，Nacos 的起步雖然晚了點，但除了註冊和配置中心的功能外，他還提供了動態服務發現、服務共享與管理的功能，在大規模場景下具備更優秀的性能，在易用性上更便捷，分佈式部署上更靈活。例如和 Consul / Eureka / Zookeeper 相比：（內容摘自《主流微服務註冊中心淺析和對比》）

	Nacos	Consul	Eureka	Zookeeper
一致性協議	CP+AP	CP	AP	CP
健康檢查	TCP/HTTP/MYSQL/Client Beat	TCP/HTTP/gRPC/Cmd	Client Beat	Keep Alive
負載均衡策略	權重/ metadata/Selector	Fabio	Ribbon	—
雪崩保護	有	無	有	無
自動註銷實例	支持	不支持	支持	支持
訪問協議	HTTP/DNS	HTTP/DNS	HTTP	TCP
監聽支持	支持	支持	支持	支持
多數據中心	支持	支持	支持	不支持
跨註冊中心同步	支持	支持	不支持	不支持
SpringCloud集成	支持	支持	支持	支持
Dubbo集成	支持	支持	不支持	支持
K8S集成	支持	支持	不支持	不支持

不想自己運維Nacos? 阿里雲微服務引擎MSE提供Nacos託管服務

阿里雲微服務引擎 ( MSE ) 是開源註冊、配置中心的全託管平臺，提供高可用、免運維的 ZooKeeper、Nacos 註冊中心 和 Eureka 等集群，完全兼容開源產品標準接口，無需修改代碼、開箱即用，併為客戶提供相應的監控和運維工具。產品官網：https://www.aliyun.com/product/mse

那麼，MSE託管的註冊中心，和開源自建註冊中心究竟有什麼區別？可以通過下面這張表來進行對比。

	對比項	自建註冊中心	MSE註冊中心
成本	資源成本	ECS費用	支持按時/包年包月，約等於同等配置ECS費用
	人力成本	需要專人維護運維	MSE提供易用自動化能力運維，門檻低
高可用	容災能力	無	支持多機房，多區域容災
	宕機處理	手動處理	自動探測，自動恢復
	活性探測	不支持	支持進程活性探測，失敗自動恢復
功能	數據管理	命令行	頁面可視化，支持增刪查改
	訪問方式	機器IP直連，代碼要變	域名，換機器，不需要變動
	業務報警	無	支持核心業務指標如鏈接數多維度報警配置
	網絡方式	本地網絡	VPC網絡，公網
	服務管理	不支持	服務提供者，訂閱者頁面管理
	集群權限管理	不支持	支持子賬號管理，可自定義子賬號訪問權限
	TPS/QPS統計	不支持	提供TPS，QPS監控視圖
運維	集群觀測	無	頁面可視化，查看節點健康狀態，角色
	監控圖表	無	提供多種指標如Znode，鏈接數圖形化視圖
	配置運維	手動修改，手動重啟	頁面修改，一鍵重啟生效
	節點伸縮	手動擴縮容，手動重啟	頁面選擇，一鍵擴縮容
	性能伸縮	不支持	頁面選擇，一鍵伸縮

從瞭解到實踐

Dubbo 應用如何保證業務不停機的情況下無縫遷移到MSE？

下面以基於 SpringBoot 構建的 Dubbo 應用為例介紹如何進行遷移

第一步：引入用於遷移的定製化註冊中心依賴

雖然 Dubbo 本身提供了配置多註冊中心的能力，但其存在比較大的侷限性，當消費者配置多註冊中心時，Dubbo 原有的策略為優先選取第一個註冊中心的地址，若其地址為空，再讀取第二個，依次類推選取地址。理想的模型應當是多個註冊中心的地址合併後隨機選取，為此，MSE 提供了專門的註冊中心擴展，解決該問題：

<dependency>
  <groupId>com.alibaba.edas</groupId>
  <artifactId>edas-dubbo-migration-bom</artifactId>
  <version>2.6.5.1</version>
  <type>pom</type>
</dependency>

其中 edas-dubbo-migration-bom 有 2.6.5.1 和 2.7.5 兩個版本，分別對應 Dubbo 2.6.x 和 Dubbo 2.7.x 兩個大版本。

第二步：購買 MSE Nacos 實例，並配置對應 nacos server address

在 MSE 控制檯購買相同 VPC 內的 Nacos 實例，並在應用的 application.properties 配置文件增加：

dubbo.registry.address = edas-migration://30.5.124.15:9999?service-registry=consul://${consulAddress}:8500,nacos://${nacosAddress}:8848&reference-registry=consul://${consulAddress}:8500,nacos://${nacosAddress}:8848

說明：

edas-migration://30.5.124.15:9999

多註冊中心的頭部信息。可以不做更改，ip 和 port 可以任意填寫，主要是為了兼容 Dubbo 對 ip 和 port 的校驗。啟動時，如果日誌級別是 WARN 及以下，可能會拋一個 WARN 的日誌，可以忽略。

service-registry

服務註冊的註冊中心地址。寫入多個註冊中心地址。每個註冊中心都是標準的 Dubbo 註冊中心格式；多個用 , 分隔。

reference-registry

服務訂閱的註冊中心地址。每個註冊中心都是標準的 Dubbo 註冊中心格式；多個用,分隔。

第三步：確認雙註冊方案成功

啟動應用，並觀察到 MSE 實例的服務管理頁面中註冊上了提供者和消費者的信息。

同時在 Consul 的控制檯中也能看相應的信息：

並且確認應用可以正常訪問，到目前為止我們第一個應用遷移完畢。

第四步：依照遷移第一個應用的遷移步驟，逐步遷移全量應用

第五步 清理遷移配置

遷移完成後，刪除原註冊中心的配置和遷移過程專用的依賴 edas-dubbo-migration-bom，在業務量較小的時間分批重啟應用。edas-dubbo-migration-bom 是一個遷移專用的 starter，雖然長期使用對您業務的穩定性沒有影響，但其並不會跟隨 Dubbo 的版本進行升級，為避免今後框架升級過程中出現兼容問題，推薦您在遷移完畢後清理掉，然後在業務量較小的時間分批重啟應用。

Spring Cloud 應用如何保證業務不停機的情況下無縫遷移到MSE？

Spring Cloud 默認只支持 1 個註冊中心，所以無法完成不停機的無縫遷移，這裡對此作了增強，支持了雙註冊雙訂閱的模式，確保業務不停機進行遷移。

遷移方案：選擇最先遷移的應用，建議是從最下層 Provider 開始遷移。但如果調用鏈路太複雜，比較難分析，也可以任意選一個應用進行遷移。選擇完成後，即可參考下面的遷移步驟遷移第一個應用。

第一步：購買 MSE Nacos 實例，並配置對應 nacos server address

在 MSE 控制檯購買相同 vpc 內的 Nacos 實例，並在應用的 application.properties 配置文件增加：

spring.cloud.nacos.discovery.server-addr={MSE對應Nacos實例的域名}:8848

第二步：在應用程序中添加依賴

在 pom.xml 文件中添加 spring-cloud-starter-alibaba-nacos-discovery 依賴。

<dependency>
     <groupId>org.springframework.cloud</groupId>
     <artifactId>spring-cloud-starter-alibaba-nacos-discovery</artifactId>
     <version>{相應的版本}</version>
 </dependency>

默認情況下 Spring Cloud 只支持在依賴中引入一個註冊中心，當存在多個註冊中心時：啟動會報錯。所以這裡需要添加一個依賴 edas-sc-migration-starter，使 Spring Cloud 應用支持多註冊。

<dependency>
     <groupId>com.alibaba.edas</groupId>
     <artifactId>edas-sc-migration-starter</artifactId>
     <version>1.0.2</version>
 </dependency>

Ribbon 是實現負載均衡的組件，為了使應用可以支持從多個註冊中心訂閱服務，需要修改 Ribbon 配置。在應用啟動的主類中，將 RibbonClients 默認配置為 MigrationRibbonConfiguration 。假設原有的應用主類啟動代碼如下：

@SpringBootApplication
 public class ConsumerApplication {
     public static void main(String[] args) {
         SpringApplication.run(ConsumerApplication.class, args);
     }
 }

那麼修改後的應用主類啟動代碼如下：

@SpringBootApplication
 @RibbonClients(defaultConfiguration = MigrationRibbonConfiguration.class)
 public class ConsumerApplication {
     public static void main(String[] args) {
         SpringApplication.run(ConsumerApplication.class, args);
     }
 }

第三步：確認雙註冊方案成功

啟動應用，並觀察到 MSE 實例的服務管理中註冊上我們的服務。

同時在 Consul 的控制檯中也能看到我們的服務。

並且確認應用可以正常訪問，到目前為止我們第一個應用遷移完畢。

第四步：依照遷移第一個應用的遷移步驟，逐步遷移全量應用

第五步：清理遷移配置

遷移完成後，刪除原有的註冊中心的配置和遷移過程專用的依賴 edas-sc-migration-starter ，在業務量較小的時間分批重啟應用。edas-sc-migration-starter 是一個遷移專用的 starter，雖然長期使用對您業務的穩定性沒有影響，但在 Ribbon 負載均衡實現方面有一定的侷限性，推薦您在遷移完畢後清理掉，然後在業務量較小的時間分批重啟應用。

關於動態調整服務註冊和訂閱方式：
依賴 edas-sc-migration-starter 具備配合配置中心達到動態調整服務註冊和訂閱方式的效果，在完成遷移過程中，您可以通過修改您的配置動態變更服務註冊和訂閱方式。

動態調整服務訂閱默認的訂閱策略是從所有註冊中心訂閱，並對數據做一些簡單的聚合。

您可以通過在您的配置中心修改 spring.cloud.edas.migration.subscribes 屬性以便選擇從哪幾個註冊中心訂閱數據。

spring.cloud.edas.migration.subscribes=nacos,consul # 同時從 Consul 和 Nacos 訂閱服務
spring.cloud.edas.migration.subscribes=nacos        # 只從 Nacos 訂閱服務

動態變更服務註冊默認的註冊策略是註冊到所有註冊中心。您可以通過在您的配置中心的
spring.cloud.edas.migration.registry.excludes 屬性來選擇關閉指定的註冊中心。

spring.cloud.edas.migration.registry.excludes=   #默認值為空，註冊到所有的服務註冊中心
spring.cloud.edas.migration.registry.excludes=consul   #關閉 Consul 的註冊
spring.cloud.edas.migration.registry.excludes=nacos,consul   #關閉 Nacos 和 Consul 的註冊

阿里雲微服務引擎 MSE 重磅升級發佈會即將開啟

拋開擔憂，迎接確性。

從配置中心，到微服務全面治理，MSE 正在迎接他的第一個成人禮，在原有配置中心託管的基礎上，全面升級引入微服務治理能力，並通過 Java Agent 技術使得您的應用無需修改任何代碼和配置，即可享有阿里雲提供的微服務治理能力，已經上線的功能包含服務查詢、無損下線、服務鑑權、離群實例摘除、標籤路由。