注册中心规则
每一个微服务启动的时候，都需要去注册中心注册（eureka或zookeeper或其他）
同类服务注册的服务名必须相同，不同类服务注册的服务名一定不能相同
（订单服务部署5台服务器，那么这5台微服务在注册中心中注册的服务名必须一致，例如ORDER）
（商品服务部署4台服务器，那么这4台微服务在注册中心中注册的服务名必须一致，例如GOODS）
（订单服务和商品服务注册的服务名一定不能相同，不能同为ORDER,也不能同为GOODS）
eureka是什么
eureka作为分布式系统的注册中心，主要作用是用于服务治理
eureka分为eureka server和eureka client
eureka原理
每一个微服务中都有eureka client，用于服务的注册于发现
（服务的注册：把自己注册到eureka server）
（服务的发现：从eureka server获取自己需要的服务列表）
每一个微服务启动的时候，都需要去eureka server注册
当A服务需要调用B服务时，需要从eureka服务端获取B服务的服务列表，然后把列表缓存到本地，然后根据ribbon的客户端负载均衡规则，从服务列表中取到一个B服务，然后去调用此B服务
当A服务下次再此调用B服务时，如果发现本地已经存储了B的服务列表，就不需要再从eureka服务端获取B服务列表，直接根据ribbon的客户端负载均衡规则，从服务列表中取到一个B服务，然后去调用B服务
微服务，默认每30秒，就会从eureka服务端获取一次最新的服务列表
如果某台微服务down机，或者添加了几台机器，
此时eureka server会通知订阅他的客户端，并让客户端更新服务列表，
而且还会通知其他eureka server更新此信息
心跳检测，微服务每30秒向eureka server发送心跳，
eureka server若90s之内都没有收到某个客户端的心跳，则认为此服务出了问题，
会从注册的服务列表中将其删除，并通知订阅它的客户端更新服务列表，
而且还会通知其他eureka server更新此信息
eureka server保护机制，通过打卡开关，可以让eureka server处于保护状态，主要是用于某eureka server由于网络或其他原因，导致接收不到其他微服务的心跳，此时不能盲目的将其他微服务从服务列表中删除。
具体规则：如果一段时间内，85%的服务都没有发送心跳，则此server进入保护状态，此状态下，可以正常接受注册，可以正常提供查询服务，但是不与其他server同步信息，也不会通知订阅它的客户端，这样就不会误杀其他微服务
zookeeper原理
zookeeper也可以作为注册中心，用于服务治理（zookeeper还有其他用途，例如：分布式事务锁等）
每启动一个微服务，就会去zk中注册一个临时子节点，
例如：5台订单服务，4台商品服务
（5台订单服务在zk中的订单目录下创建的5个临时节点）
（4台商品服务在zk中的商品目录下创建的4个临时接点）
每当有一个服务down机，由于是临时接点，此节点会立即被删除，并通知订阅该服务的微服务更新服务列表
（zk上有watch，每当有节点更新，都会通知订阅该服务的微服务更新服务列表）
每当有一个新的微服务注册进来，就会在对应的目录下创建临时子节点，并通知订阅该服务的微服务更新服务列表
（zk上有watch，每当有节点更新，都会通知订阅该服务的微服务更新服务列表）
每个微服务30s向zk获取新的服务列表
CAP基本概念
分布式系统的三个指标
1、Consistency 一致性
2、Availability 可用性
3、Partition tolerance 分区容错性
eureka和zookeeper区别
eureka基于AP
zookeeper基于CP
由于作为注册中心可用性的需求要高于一致性，所以eureka貌似要比zookeeper更合理一些
