注册中心的访问过程+CAP理论+负载均衡+高可用+自我保护机制

• 把一个庞大的系统拆封成若干个服务，通过http的RESTful 的api进行通信。在springCould中RestTemplate是一个基于Http协议的一个工具对象。（可以通过这个对象以http协议发送请求到具体的模个web服务器中），微服务是基于http服务的json格式进行调用的所以不同的服务可以使用不同的语言进行编写。

• ---

  注册中心

注册中心是一个把provicer和consumer的模块注册到上面的工具

1，provider拥有服务名称和ip地址+端口号

2，provider把服务名称和ip地址+端口号注册到注册中心。

3，consumer通过服务名称访问注册中心，得到provider的ip地址加上端口号。

4，consumer通过ip地址+端口号，对provider进行访问。

---

• CAP理论

Consistency（一致性） 2. Availability（可用性） 3. Partition tolerance（分区容忍性）

Eureka 是（ap） zookeeper（cp）

在微服务中必须保证分区容错性（一个微服务不可以访问后，其他服务依然可以继续访问）

高可用：多个微服务没有主从关系，通过负载均衡，来轮寻算法来访问注册中心。（每一个注册中心都有可能被访问到）

当你发送一个微服务到注册中心的时候，其他注册中心也会再复制这个微服务。但是这个是有时间的，如果在这个期间，consumer访问这个最新发布的微服务，有可能还没有来得及同步（这个）。所以会访问失败，然后重新访问。（对于更新微服务，和删除微服务是同样的道理）。

一致性：拥有主从关系，有一个主注册中心，其他都是从注册中心。在主进行注册微服务的时候，其他的从服务器是不能使用的。追求的是数据的一致性，这个时候进行访问数据，可能会失败。如果master宕机了，其他的slave需要进行选举，这个过程是缓慢的（10s~30s），这个整个服务器集群是不可以使用的。

zookeeper采用的是cp            eureka采用的是ap

在springCloud中推荐使用eureka

---

• 负载均衡

在consumer通过服务名称在注册中心拿到多个provider的ip地址+端口号（有多个provoder注册到注册中心，是同一个微服务），这时候就有一个问题？consumer不知道需要访问那个ip地址+端口号，这是就需要Ribbon来实现负载均衡，通过选择策略来决定访问那个ip地址+端口号。（比如轮寻访问，每个ip地址+端口号轮流访问）

---

• Eureka的高可用

把Eureka注册中心互相注册到对方的中，这样子就实现了数据共享

---

• Eureka的service和client

Eureke的serivice就是注册中心

Eureka的client就是consumer和provider

---

• 细节

在EurekaClient端中往EurekaService端注册微服务时候，需要指定全部的EurekaService的地址，这样可以防止在其中一个Service端宕机的时候，刚好是在client端指定的地址，这样就不可以成功注册到service端了。（指定全部service端的地址就可以避免这样的问题）

---

• Eureka的自我保护机制

前提：每个一段时间client会向service发送心跳，证明client还存活着。

自我保护机制：如果client没有往service发送心跳的时候，service不会删除client注册的微服务。

没有发送心跳存在两种情况。1、client宕机了  2、可能是client发送的网络断掉了，但是client还可以使用。

对于2的情况，自我保护机制不会删除微服务，这时候还是可以成功访问到微服务的，好像有句名言（想不起来了自己编）宁可放过一千也不愿错杀一个。后面还会有什么重连的机制。有点忘了

对于自我保护机制是默认打开的（注册中心的页面的醒目红字）

非自我保护机制就是，没心跳就杀掉。

---

• Eureka的配置

provider的配置

发送心跳的间隔

多久没有发送心跳就是嗝屁了

告诉service，provider提供服务的名称

连接service的ip地址

service的配置

端口号

注册中心的名字

指定自己的名字