统一Apollo和应用项目的Eureka

Posted 2023-04-13

参考技术A

Apollo默认自带了Eureka作为内部的注册中心实现，该Eureka-server就Config Service上，在一般情况下不需要考虑为Apollo单独部署注册中心。

不过有些公司自己已经有了一套Eureka，如果希望把Apollo的Config Service和Admin Service也注册过去实现统一管理的话，可以按照如下步骤操作：
本人用的Apollo是：1.5.0版本的。

修改打包好的 apollo-configservice 和 apollo-adminservice 安装包下的 application-github.properties 文件

修改 ApolloConfigDB.ServerConfig 表中的 eureka.service.url ，指向自己的Eureka地址。

比如自己的Eureka服务地址是 192.168.10.126:8001 和 192.168.10.126:8002 ，那么就将 ApolloConfigDB.ServerConfig 表中设置 eureka.service.url 为：

启动 apollo-configservice 和 apollo-adminservice 以及 Eureka-Server 后，访问eureka：

apollo-configservice 和 apollo-adminservice 都注册到了我们的Eureka，还需要验证 apollo-configservice 是否启动了自己的Eureka-server：

访问： 192.168.10.126:8080 ，不会显示eureka管理页面。

nacos简介以及作为注册/配置中心与Eureka、apollo的选型比较

参考技术A

Nacos是以服务为主要服务对象的中间件，Nacos支持所有主流的服务发现、配置和管理。

Nacos主要提供以下四大功能：

Nacos支持加权路由，使您可以更轻松地在数据中心的生产环境中实施中间层负载平衡，灵活的路由策略，流量控制和简单的DNS解析服务。它可以帮助您轻松实现基于DNS的服务发现，并防止应用程序耦合到特定于供应商的服务发现API。

Nacos提供易于使用的服务仪表板，可帮助您管理服务元数据，配置，kubernetes DNS，服务运行状况和指标统计。

nacos具有Apollo大部分功能，最重要的是配置中心与注册中心打通，可以省去我们在微服务治理方面 的一些投入（比如通过动态配置来启停线程池等操作）。

初步结论为：使用Nacos代替Eureka和apollo，主要理由为：
相比与Eureka：
(1)Nacos具备服务优雅上下线和流量管理（API+后台管理页面），而Eureka的后台页面仅供展示，需要使用api操作上下线且不具备流量管理功能。
(2)从部署来看，Nacos整合了注册中心、配置中心功能，把原来两套集群整合成一套，简化了部署维护
(3)从长远来看，Eureka开源工作已停止，后续不再有更新和维护，而Nacos在以后的版本会支持SpringCLoud+Kubernetes的组合，填补 2 者的鸿沟，在两套体系下可以采用同一套服务发现和配置管理的解决方案，这将大大的简化使用和维护的成本。同时来说,Nacos 计划实现 Service Mesh，是未来微服务的趋势
(4)从伸缩性和扩展性来看Nacos支持跨注册中心同步，而Eureka不支持，且在伸缩扩容方面，Nacos比Eureka更优（nacos支持大数量级的集群）。
(5)Nacos具有分组隔离功能，一套Nacos集群可以支撑多项目、多环境。

相比于apollo
(1) Nacos部署简化，Nacos整合了注册中心、配置中心功能，且部署相比apollo简单，方便管理和监控。
(2) apollo容器化较困难，Nacos有官网的镜像可以直接部署，总体来说，Nacos比apollo更符合KISS原则
(3)性能方面，Nacos读写tps比apollo稍强一些

结论：使用Nacos代替Eureka和apollo

系统模块架构

Nacos提供DNS-F功能
DNS-F落地的技术价值

阿里巴巴、虎牙直播、中国工商银行、爱奇艺、中国平安、平安科技、浙江农信、贝壳、丰巢、百世快递、汽车之家等

完整列表： https://github.com/alibaba/nacos/issues/273