之前一直在用eureka，后来阿里推出naocs，两者均提供服务注册中心&服务治理功能，通过对两者进行差异分析以及对比，系统架构中将eureka切换为nacos，以下为两者差异和选型方案
一、为何用它？
1、功能差异
2、稳定剂扩展性
3、选型的建议
采用Eureka方案的考虑
想用Spring Cloud原生全家桶
想用本地文件和Git作为配置管理的,将配置与服务分开管理
考虑短期的稳定性
采用Nacos方案的考虑
想在线对服务进行上下线和流量管理
不想采用MQ实现配置中心动态刷新
不想新增配置中心生产集群
考虑引入Spring Cloud Alibaba生态
二、窥探其原理
1、服务注册
先问两个问题，服务在什么时机注册的？又是怎么注册的？带着这两个问题我们往下看。
我们知道springcloud是一个规范，里面的组件，只要按照这个规范去实现就可以集成进去，在spring-cloud-commons包下有META-INF/spring.factories这么一个文件，如果熟悉springboot自动装配原理想必大家肯定不会陌生这个文件的作用，我们看下这个文件的内容
里面有个一个很重要的自动装配类AutoServiceRegistrationAutoConfiguration，先来看一下这个类长什么样
AutoServiceRegistrationAutoConfiguration里有个属性成员AutoServiceRegistration，它是一个空接口。
从类关系图可知它有一个AbstractAutoServiceRegistration抽象类实现了这个接口，而AbstractAutoServiceRegistration是由springcloud提供的，即springcloud提供的规范，Nacos的NacosAutoServiceRegistration类继承了它，仔细看，AbstractAutoServiceRegistration还实现了 ApplicationListener接口，监听容器初始化事件，当容器初始化完成触发onApplicationEvent调用bind方法。
再进一步跟到start方法
看来服务注册就是从这里开始的，此处通过serviceRegistry调用register方法进行服务的注册，到此回答了上面第一个问题。
补充说明一下，这里serviceRegistry实际上是NacosAutoServiceRegistration持有的。
那服务具体是怎么注册的呢？前面提到的NacosAutoServiceRegistration又是在哪里初始化的呢？所持有的serviceRegistry对象又在哪里注入的呢。首先我们要接入nacos，先在pom文件添加依赖如下
这个类就在其中，如下所示
在这个包下同样也能找到一个spring.factories文件，打开如下
很快我们就能发现和NacosAutoServiceRegistration相关的NacosServiceRegistryAutoConfiguration配置类，猜想就是在这个配置类中初始化的，进去看看，很快便证实我们的猜想，对，它就在这
看到这里红框框很清楚的解答了上面的问题，下面我们再着重分析下NacosServiceRegistry这个类的regiester方法实现
从代码中可以发现最终使调用namingService.registerInstance方法完成服务的注册工作的，进一步跟进NacosNamingServiceshi实现了NamingService接口
方法里主要两步，
第一：创建心跳信息实现健康检测 ；
第二：调用Nacos的REST 接口实现服务注册。
将请求委托给serverProxy去处理，最后调用Nacos服务端的REST接口实现服务注册。
nacos服务端有兴趣的同学可以在github上下载源码进行阅读，在这里不再展开了。
（https://github.com/alibaba/nacos）
上面对nacos是在什么时候完成服务注册，又是怎么完成服务注册的进行了解析，那么服务注册之后，又是怎么相互发现的呢？敬请关注，服务注册&发现之nacos服务发现篇。
