First, what is the service discovery?
problem:
We now have the number of service?
Services rises, service URL configuration management becomes very messy
Foreign service address has changed, all others have to use the service must be changed address
Increased service, increased service instance, we have to do the operation and maintenance work
1.1 server discovery mode
Client access to the target service by the end of the load or routing services.
Server load and is responsible for forwarding the request, itself or through third-party tools to automatically discover new instance of the service and maintenance of the registry timing detection heartbeat.
Pros:
service discovery function is transparent to the client's
shortcomings:
an increase of a forward, there is no centralized approach to the center
Question:
1.nignx / F5 has a service address list, there are load balancing, server discovery belongs to you?
Main disadvantage of the "discovery" feature, service instances dynamically increase or decrease does not take the initiative to identify
2. Examples own service sends a registration request to the server can not it?
Service instance is a service provider, it may be the service consumer; if sending a registration request to the registration center, you can also pull the registry from the registry, so direct client found not do better?
1.2 client discovery mode
Examples of available address lists on their own and use load balancing strategy can determine the service provider clients.
Service provider to send a heartbeat to the registration and registration center.
The server is only responsible for maintaining the registry, and provide services.
Advantages:
The client can be flexible, intelligent load balancing strategy to develop
decentralized
drawback:
the client coupled with the registry, the need to achieve interaction with the central registration code
Second, the service found the key role extract
服务提供者：
向注册中心发送请求，发送信息
服务消费者：
向注册中心发送请求，获取信息
注册中心：
提供接口给服务发现客户端调用
维护服务实例信息集合
集群之间信息同步
三、关键角色要干些什么事情
3.1服务提供者
服务提供者：向注册中心发送请求，发送信息
1.发送请求问题：
发送请求的工具用什么，okhttp、resttemplate？
请求失败怎么办，要重试吗？重试的策略是什么？
2.注册中心地址问题：
发送信息给所有注册中心还是发送一个成功就行了？
注册中心有多个的话，优先访问哪个呢，访问失败的要记录起来下次不访问了吗？
地址写在配置里，如果有增加或调整，所有客户端都要改？
3.发送注册/心跳问题：
注册和心跳调同一个接口还是分开两个接口比较好?
注册后，除了要定时发送心跳，实例信息有改变的情况下，要发给注册中心吗？
3.1.1服务提供者-发送请求问题
作为一个中间件如何提高可扩展性？
eureka的答案是装饰器模式
JeseryClient：
执行rest请求的工具，eureka有RestTemplate的替换实现方案
统计信息：
根据请求类型进行统计，请求时间总计、请求失败次数总计等
重定向：
返回的http code是302则表示要重定向（注册中心迁移？）更换重定向的url再次发起请求，最多重定向10次
失败重试机制：
已经请求失败的server url记录下来下次不再请求；
如果失败的url过多（比如全部都失败的情况，可能是客户端网络有问题），超过阀值，则清空失败的url记录，把他们重新当成可用的url ，这里要获取注册中心地址列表，用于重试
会话：
请求失败的url记录多久，永久记录吗？使用session机制如果20分钟没请求过，则重置上面的所有机制
session有效时长20分钟左右（有随机增减）
3.1.2服务提供者-注册中心地址问题
1.发送信息给所有注册中心还是一个？
不管是AP还是CP，服务提供者只需与一个注册中心交互成功就行，服务提供者不关心注册中心之间的数据同步
2.客户端如何保证发送到任意一个注册中心成功呢？
配置多个注册中心地址，失败了就换下一个再试
3.注册中心地址变更问题
配置了多个注册中心地址后，如果注册地址有增删改怎么解决
将注册中心地址放到配置中心 或 DNS txt记录，客户端定时去刷新获取
（就算是存在本地配置文件，eureka也会开启定时任务定时去取）
3.1.3服务提供者-发送心跳/注册问题
注册后，除了要定时发送心跳，实例信息有改变的情况下，要发给注册中心吗？
eureka的答案是需要：
1.实例状态变更
2.配置信息变更
LeaseExpirationDurationInSeconds 心跳有效期
LeaseRenewalIntervalInSeconds 心跳频率
3.健康检查处理器的增减（用于获取实例状态）
3.2服务消费者
服务消费者：向注册中心发送请求，获取注册表信息
1.发送请求问题（同服务提供者）
2.注册中心地址变更问题（同服务提供者）
3.全量还是增量获取应用实例信息
如果消费者本地实例信息为空，则全量获取，否则增量获取，关键逻辑在注册中心，这里较简单
将上面结论进行汇总
3.3注册中心
注册中心：
提供接口给服务发现客户端调用
维护服务实例信息集合
集群之间数据同步
3.3.1注册中心-接口
如何做增量更新？
查询是否需要缓存？
如何做增量更新？
eureka的答案是维护一个队列 recentlyChangedQueue
细心的观众会发现，为什么接收到心跳，不会增加到recentlyChangedQueue？
队列里存的是引用类型，和应用实例列表是同一个地址，接收到心跳进行实例更新，定时维护最近变动实例队列时查到实例信息变动，然后继续将其保留在队列里，这样增量查询下次一样能查到该实例的信息
为什么要自我保护？
如果失效的实例过多，有没有可能是注册中心出了问题？
上一分钟接收到心跳总数<= 实例总数*2(默认30s一次心跳) * RenewalPercentThreshold()(默认0.85)进入自我保护则不会剔除任何实例
3.3.2注册中心-集群同步
如何做集群同步？
eureka的答案还是维护队列，这里注册、心跳、下线都会入队，批量进行同步，失败的加到失败重试队列
接收到的所有请求，都要同步吗？
要经过过滤， 每种类型只取最新一条去同步即可
注册中心地址变更
同服务发现客户端一样，定时刷新注册中心地址，然后更新集群节点
3.4架构图
（右键新标签打开可查看大图）
四、结合Region和AZ(Available Zone)
区域（Region）：
从设计而言，每个 Amazon EC2 区域都与其他 Amazon EC2 区域完全隔离。这可实现最大程度的容错能力和稳定性。在区域之间传输数据需要收费。
可用区（Availability Zone ,AZ）:
如果您的实例分布在多个可用区且其中的某个实例发生故障，则您可对您的应用程序进行相应设计，以使另一可用区中的实例可代为处理相关请求。可用区由区域代码后跟一个字母标识符表示；例如，us-east-1a。
地域（Region）：
不同地域的云服务器 ECS、关系型数据库 RDS、对象存储服务 OSS 内网不互通。
不同地域之间的云服务器 ECS 不能跨地域部署负载均衡，即在不同的地域购买的 ECS 实例不支持跨地域部署在同一负载均衡实例下。
可用区（Zone）：
可用区是指在同一地域内，电力和网络互相独立的物理区域。同一可用区内实例之间的网络延时更小。
理解region和az的概念后，我们需要做什么是不是就简单多了？
1.服务发现客户端，优先与相同的AZ进行通讯
2.服务发现客户端，查询注册中心地址列表时，只取相同region下所有AZ的注册中心地址
2.注册中心，也只需要将数据同步给相同region的所有AZ即可
不过属于哪个区，好像没有特殊的配置吧？
eureka.client.availability-zones.us-east-1=zone2,zone1
eureka中取上面配置的第一个可用区为优先使用的可用区
注：虽然region之间是数据隔离的，但是eureka也支持从其他region同步信息（通过http请求）
常见问题探讨
连连看，将如下类图与我们架构图里对象进行对应（右键新标签打开可查看大图）
eureka server 是ap还是cp？
服务启动后会不会马上注册到注册中心？
服务提供者注册到注册中心后，服务消费者最快多久能够查询到该提供者？
为什么接收心跳后不入队，那么更新心跳后启不是增量查询查不到了？
集群同步的队列，为什么要经过一道中转才进行消费？
部分图片摘自如下文章：