-------------------------------------普通springcloud eureka
1 .eureka 注册中心：做了两个eureka服务，以此类推可以做多个，互相注册，高可用，集群部署
2. zipkin跟踪服务：分布式跟踪日志,基于内存存储记录
3 .zuul网关路由服务：分发请求，统一管理过滤，结合 ribbon 负载均衡、 hystrix断路器
4. springboot-admin 监控中心服务：统一界面管理，查看各个服务运行状态 actuator健康检查
---------------------------------spring cloud Alibaba nacos 注册中心 fhadmin.cn
1 .nacos 阿里注册中心：官方eureka停止更新，目前比较好的取代者就是nacos
2. zipkin 跟踪服务：分布式跟踪日志,基于内存存储记录
3 .gateway 网关路由服务：分发请求，统一管理过滤，结合 LoadBalancer负载均衡、 feign服务调用
4. springboot-admin 监控中心服务：统一界面管理，查看各个服务运行状态 actuator健康检查
5. sentinel 高可用流量管理框架： 以流量为切入点，限流、流量整形、熔断降级、系统负载保护、热点防护
nacos和eureka注册中心对比
1. CP 和 AP不可能同时满足
2.P代表分区容错, 在整个分布式系统中某个节点服务挂掉了,并不影响整个系统的运作和使用，
因为他可以在稍后或者通过切换可用节点立即恢复使用
3.C: 写操作之后的读操作，必须返回该值。
注册中心集群中: leader的作用, 所有的写操作都依赖于leader来完成,为了保证数据的一致性, leader只有一个
假如: 没有leader,首先加入我们新加入一台数据处理服务,就会向注册中心1进行注册,注册中心1写入数据处理服务的ip
等等基本信息,并且准备同步给其他注册中心节点, 结果这个在还没发生同步的过程中,注册中心1挂掉了,
然后客户端准备调用数据中心写入,这个时候就因为注册中心1挂掉了,就直接切到了注册中心2,但是注册中心2没有
收到数据处理服务的添加请求,所以没有这个服务,这个时候就对客户端显示不可用了.
4. A: 没有leader,可以很容易的切换到可用的注册中心,对于客户端的调用总是及时反应, 在上述C操作的例子中,
对于向服务注册,获取服务注册的基本信息,比如ip来说,基本不会存在,因为像Eureka来说,我们的服务可以
向所有的注册中心节点发起注册请求, 这样就不会存在注册中心节点服务列表不一致的情况
阿里的nacos : 性能最好 fhadmin.cn
他同时支持AP和CP模式,他根据服务注册选择临时和永久来决定走AP模式还是CP模式,
他这里支持CP模式对于我的理解来说,应该是为了配置中心集群,因为nacos可以同时作为注册中心和配置中心,
因为他的配置中心信息是保存在nacos里面的,假如因为nacos其中一台挂掉后,还没有同步配置信息,
就可能发生配置不一致的情况., 配置中心的配置变更是服务端有监听器,配置中心发生配置变化,
然后服务端会监听到配置发生变化,从而做出改变
