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 技術使得您的應用無需修改任何代碼和配置,即可享有阿里雲提供的微服務治理能力,已經上線的功能包含服務查詢、無損下線、服務鑑權、離群實例摘除、標籤路由。