Nacos的引入
假如商品微服务被调用较多，为了应对更高的并发，我们进行了多实例部署，如图：
此时，每个
item-service的实例其IP或端口不同，问题来了：
- item-service这么多实例，cart-service如何知道每一个实例的地址？
- http请求要写url地址，
cart-service服务到底该调用哪个实例呢？ - 如果在运行过程中，某一个
item-service实例宕机，cart-service依然在调用该怎么办？ - 如果并发太高，
item-service临时多部署了N台实例，cart-service如何知道新实例的地址？
为了解决上述问题，就必须引入注册中心的概念了。
Nacos的本质
服务注册中心本质上是为了解耦服务提供者和服务消费者。对于任何一个微服务，原则上都应存在或者支持多个提供者，这是由微服务的分布式属性决定的。更进一步，为了支持弹性扩缩容特性，一个微服务的提供者的数量和分布往往是动态变化的，也是无法预先确定的。因此，原本在单体应用阶段常用的静态LB机制就不再适用了，需要引入额外的组件来管理微服务提供者的注册与发现，而这个组件就是服务注册中心。
Nacos的实现原理
在微服务远程调用的过程中，包括两个角色：
- 服务提供者：提供接口供其它微服务访问，比如
item-service - 服务消费者：调用其它微服务提供的接口，比如
cart-service
在大型微服务项目中，服务提供者的数量会非常多，为了管理这些服务就引入了注册中心的概念。
注册中心、服务提供者、服务消费者三者间关系如下：
简单流程：服务提供者启动服务的时候就会注册自己的服务信息（服务名、IP、端口）到注册中心（即告诉服务中心自己的地址以及自己是干什么的），服务调用者会从服务中心去订阅自己需要的服务。
详细流程如下：
- 服务启动时就会注册自己的服务信息（服务名、IP、端口）到注册中心
- 调用者可以从注册中心订阅想要的服务，获取服务对应的实例列表（1个服务可能多实例部署）
- 调用者自己对实例列表负载均衡，挑选一个实例
- 调用者向该实例发起远程调用
当服务提供者的实例宕机或者启动新实例时，调用者如何得知呢？
-
服务提供者会定期向注册中心发送请求，报告自己的健康状态（心跳请求）
-
当注册中心长时间收不到提供者的心跳时，会认为该实例宕机，将其从服务的实例列表中剔除
-
当服务有新实例启动时，会发送注册服务请求，其信息会被记录在注册中心的服务实例列表
-
当注册中心服务列表变更时，会主动通知微服务，更新本地服务列表
