一、扯点概念
1. 服务注册中心
服务注册中心主要分为三个部分，一个部分是服务的提供者，一个部分是服务注册中心，一个部分则是服务的消费者。
随着业务的发展，应用越来越多，每个应用之间的交互也越来越多，从而为了解决应用之间的依赖关系，从而需要使用服务注册中心。 注册中心解偶了服务提供者和服务消费者之间的关系，并且支持弹性的扩容和缩容，当你扩容的时候，只要将你的服务再次扩展一个，也就会自动注册到注册中心了。
2. Nacos 是啥
Nacos是阿里巴巴开源的服务注册中心以及配置中心，致力于给开发者提供一款便捷、简单上手的开源框架，帮助开发者快速实现动态服务发现、服务配置、服务元数据及流量管理。
3. 为什么用 Nacos ？
（1）当前主流的组件
Eureka、Consul、ZooKeeper和Nacos等。
（2）如何技术选型
选型前 ,先了解一下CAP：
一致性(Consistency) (所有节点在同一时间具有相同的数据) 可用性(Availability)(保证每个请求不管成功或者失败都有响应) 分区容错(Partition tolerance) (系统中任意信息的丢失或失败不会影响系统的继续运作)
- Zookeeper -> CP：Zookeeper 不能保证每次服务请求都是可达的，从 Zookeeper 的实际应用情况来看，在使用 Zookeeper 获取服务列表时，如果此时的 Zookeeper 集群中的 Leader 宕机了，该集群就要进行 Leader 的选举，又或者 Zookeeper 集群中半数以上服务器节点不可用，那么将无法处理该请求。所以说，Zookeeper 不能保证服务可用性。
- Consul -> CP：服务注册相比Eureka会稍慢一些。因为Consul的raft协议要求必须过半数的节点都写入成功才认为注册成功；Leader挂掉时，重新选举期间整个consul不可用。保证了强一致性但牺牲了可用性。
在微服务开发中，大家应该主要的选型是Eureka、Nacos、Consul 。
由于没接触过 Consul，下面选型主要从Eureka、Nacos考虑：
采用Eureka方案的主要考虑
- 计划用Spring Cloud原生全家桶
- 计划本地文件和Git作为配置管理的，将配置与服务分开管理
- 考虑短期的稳定性，Eureka2.0已停止开发
采用Nacos方案的主要考虑
- 在线对服务的上下线和流量管理
- 不想采用MQ实现配置中心的动态刷新
- 不想新增配置中心集群
- 考虑引用Spring Cloud Alibaba 生态
Nacos 与 Eureka 对比
一张图了解一下Nacos的地位，也看得出阿里巴巴的目的
从上图可以了解到，Nacos在注册中心、服务配置和服务总线都有应用，把Eureka、Config和Bus给替换了。
注册中心＋配置中心的组合 -> Nacos = Eureka+Config+Bus
Nacos 可以与 Spring, Spring Boot, Spring Cloud 集成，并能代替 Spring Cloud Eureka, Spring Cloud Config。
通过 Nacos Server 和 spring-cloud-starter-alibaba-nacos-config 实现配置的动态变更。 通过 Nacos Server 和 spring-cloud-starter-alibaba-nacos-discovery 实现服务的注册与发现。
所以，对于其它注册中心，Nacos对于初学的开发者来说，十分友好，门槛低，上手快，启动后，直接可用。
4. Nacos 在微服务中的地位
5. Nacos 的使用企业
二、小试牛刀
以windows安装单机模式为例。
