微服务重要的的一个概念：服务治理
服务治理实际上就是对服务的管理，主要的服务的注册，服务的发现，当有服务掉线宕机还要服务剔除。
为什么要有服务治理，可以看一下下面这个图
两个集群，一个提供服务一个使用服务，但是问题来了，中间怎么调用彼此成了问题，毕竟这么我不能写死，万一写死的部分不好用，直接就停了服务。
采取的方式就是通过一个VIP，VIP类似一个代理我把集群的服务代理成一个地址，你调用我这个代理地址就完了。
但是还会遇到一个问题，就是这个VIP维护起来也挺麻烦的，中间有不好的服务怎么检查出来踢掉，然后选择那些服务均摊压力，不能可着其中一两个猛用，那集群也没意思，还有就是扩容缩容。总之作为中间商，我必须赚差价，要不然真活不下去。
那么我们有没有一个方案，自己控制的更多一些，减少中间的维护，最好是一个中心，我们去注册，一个去中心找，也就是主要是服务注册和服务发现，这就是服务注册中心。
当然还会遇到一些问题，服务中心也不是一个纸板，他还要有一些自己的主管能动性，也就是我要知道那些服务发现，之前可以现在不可以，那些服务注册，现在注册了但是自己已经不能提供服务了。
这就是容错机制，我们不想从中心拿到的注册服务很多不能用了，这些服务就要下线。常用的方式是通过心跳来检查。
nacos架构
nacos数据模型
分别是 Namespace、Group 和 Service/DataId
- Namespace：即命名空间，它是最顶层的数据结构，我们可以用它来区分开发环境、生产环境等不同环境。默认情况下，所有服务都部署到一个叫做“public”的公共命名空间；
- Group：在命名空间之下有一个分组结构，默认情况下所有微服务都属于“DEFAULT_GROUP”这个分组，不同分组间的微服务是相互隔离的；
- Service/DataID：在 Group 分组之下，就是具体的微服务了，比如订单服务、商品服务等等。
通过 Namespace + Group + Service/DataID，我们就可以精准定位到一个具体的微服务。比如，我想调用生产环境下 A 分组的订单服务，那么对应的服务寻址的 Key 就是类似 Production.A.orderService 的组合。
Nacos 社区的基本架构图
Nacos Core 模块
这里有两大块nacos core和nacos naming service
Naming Service 提供了将对象和实体的“名字”映射到元数据的功能，这是服务发现的基础功能之一。例如，我想要调用 OrderService，我手里有这个服务的 Namespace 和 Group 信息，那么我就可以通过 Naming Service 定位到这个服务对应的实例列表。同理，如果我有一个 DNS 名称，同样可以借助 Naming Service 获取 DNS 背后配置的 IP 列表。以上两个场景就分别对应了服务发现和 DNS 功能，这两个场景都是 Naming Service 的核心场景
nacos core一致性协议，Nacos 内部支持两种一致性协议，一种是侧重一致性的 Raft 协议，基于集群中选举出来的 Leader 节点进行数据写入；另一种是针对临时节点的 Distro 协议，它是一个侧重可用性（或最终一致性）的分布式一致性协议。