一、基本介紹
Eureka
Eureka 是 Netflix 公司開發的一款基于 REST 風格的服務注冊與發現組件，專為分布式系統設計。它遵循?AP 原則（可用性、分區容錯性優先），強調在網絡分區等異常情況下的服務可用性，是 Spring Cloud Netflix 生態中的核心組件之一。
Nacos
Nacos（Dynamic Naming and Configuration Service）是阿里巴巴開源的一站式服務發現、配置管理和服務管理平臺。它融合了服務注冊發現與配置管理功能，支持?AP/CP 模式切換，能適配不同場景下的一致性需求，是 Spring Cloud Alibaba 生態的核心組件，廣泛應用于大規模微服務架構。
二、核心作用
Eureka 的作用
- 服務注冊：服務實例啟動時，將自身信息（IP、端口、服務名等）注冊到 Eureka Server。
- 服務發現：客戶端通過 Eureka Server 獲取服務實例列表，實現服務間的動態通信。
- 高可用保障：通過集群部署和自我保護機制，確保在部分節點故障時仍能提供服務。
Nacos 的作用
- 服務注冊與發現：支持多種服務發現模式（DNS、RPC），適配不同框架（Spring Cloud、Dubbo 等）。
- 動態配置管理：集中管理服務配置，支持配置實時推送、版本控制和灰度發布。
- 服務治理：提供服務健康檢查、元數據管理、流量控制等高級功能，簡化微服務運維。
三、核心功能
Eureka 的核心功能
服務注冊機制
- 服務實例定期向 Eureka Server 發送心跳（默認 30 秒），證明自身存活。
- 若 Server 連續 90 秒未收到心跳，會將該實例從注冊表中移除。
集群與同步
- Eureka Server 集群中，節點間通過復制機制同步注冊表信息。
- 無主從之分，每個節點均可接收注冊請求并同步至其他節點。
自我保護機制
- 當網絡分區導致 Server 短時間內丟失大量心跳時，會觸發自我保護，暫時不刪除過期實例。
- 避免因網絡波動誤刪健康實例，保障服務可用性。
客戶端緩存
- 客戶端會緩存服務列表，即使 Eureka Server 不可用，仍可基于緩存調用服務。
Nacos 的核心功能
服務注冊發現
- 支持?DNS 式服務發現（基于域名解析）和?RPC 式服務發現（基于客戶端調用）。
- 提供實時服務健康檢查（TCP、HTTP、自定義腳本等方式），快速剔除異常實例。
配置管理
- 集中管理多環境、多服務的配置，支持 YAML、Properties 等格式。
- 配置變更實時推送（基于長連接），無需重啟服務即可生效。
- 支持配置版本回滾、灰度發布和權限控制。
AP/CP 模式切換
- AP 模式：類似 Eureka，優先保證可用性，適用于服務發現場景。
- CP 模式：基于 Raft 協議保證數據一致性，適用于配置管理等強一致性場景。
高級特性
- 服務元數據管理：支持自定義服務標簽（如環境、版本），便于服務篩選。
- 流量控制集成：與 Sentinel 無縫對接，實現基于服務名的流量管控。
- 集群動態擴展：支持節點自動發現，新增節點無需手動配置。
四、發展歷史
Eureka 的歷史
起源（2012-2013 年）
隨著 Netflix 從單體架構轉向微服務，服務數量激增，傳統硬編碼地址方式失效，Eureka 應運而生，解決服務地址動態管理問題。開源與普及（2014-2016 年）
2014 年開源后被納入 Spring Cloud 生態，憑借簡單易用和高可用性，成為微服務注冊中心的 “標配”。穩定與生態綁定（2017-2018 年）
功能趨于穩定，版本迭代至 1.x 和 2.x，與 Feign、Ribbon 等組件深度集成，形成完整調用鏈路。停止維護（2019 年后）
Netflix 宣布 Eureka 2.x 停止開發，僅保留 1.x 有限維護。原因包括內部轉向 Kubernetes 生態，以及功能單一（僅支持注冊發現）的局限性。此后逐漸淡出主流視野。
Nacos 的歷史
內部孵化（2016-2018 年）
阿里巴巴內部服務規模突破百萬級，原有基于 ZooKeeper 的方案面臨性能瓶頸，遂開發 “ConfigServer”（配置）和 “NamingService”（注冊），后合并為 Nacos 雛形。開源與社區化（2018 年底）
2018 年 11 月正式開源，納入 Spring Cloud Alibaba 生態，支持多框架兼容，迅速吸引社區關注。快速迭代（2019-2021 年）
- 2019 年發布 1.0 正式版，完善 AP/CP 切換和集群功能，支持千萬級實例。
- 2020 年集成 Sentinel、Seata 等組件，形成完整微服務治理生態。
- 2021 年適配 Kubernetes，擴展云原生場景。
持續演進（2022 年后）
迭代至 2.x 版本，優化元數據管理和健康檢測，支持多語言客戶端（Java、Go 等），成為服務治理領域的主流方案。
五、核心區別
| 維度 | Eureka | Nacos |
|---|---|---|
| 功能范圍 | 僅支持服務注冊與發現 | 服務注冊發現 + 配置管理 + 服務治理 |
| 一致性模型 | 固定 AP 模式（可用性優先） | 支持 AP/CP 模式切換 |
| 性能 | 適用于中小規模服務（萬級實例） | 支持百萬級服務實例，性能更優 |
| 生態兼容性 | 僅深度集成 Spring Cloud Netflix | 兼容 Spring Cloud、Dubbo、Kubernetes 等 |
| 配置管理 | 無 | 原生支持動態配置管理 |
| 維護狀態 | 停止維護（1.x 僅有限支持） | 持續更新，社區活躍 |
| 部署復雜度 | 需配合其他組件（如 Config Server） | 單組件即可滿足服務治理需求 |
六、適用場景
Eureka 適用場景
- 小型微服務項目，僅需基礎注冊發現功能。
- 基于 Spring Cloud Netflix 生態的 legacy 系統。
- 對可用性要求高、一致性要求較低的場景。
Nacos 適用場景
- 中大型微服務架構，需同時解決注冊發現和配置管理問題。
- 需在 AP/CP 模式間靈活切換的復雜場景（如金融、電商）。
- 基于 Spring Cloud Alibaba 或 Dubbo 生態的項目。
- 需服務元數據管理、灰度發布等高級功能的場景。
總結
Eureka 代表了早期微服務注冊發現的經典方案，但其功能單一且已停止維護，逐漸被替代；Nacos 則是新一代服務治理平臺，憑借功能全面、性能優異和持續演進，成為當前微服務架構的首選組件。選擇時需根據項目規模、生態依賴和功能需求綜合考量。
問題詳解)
