まず、サービスの発見は何ですか？
問題：
私たちは今、サービスの数を持っていますか？
サービスは、サービスのURLの構成管理は非常に厄介になり、上昇します
外国サービスアドレスは、他の人がサービスを利用しているすべてのアドレスを変更する必要があり、変更されました
私たちは、操作や保守作業を行う必要があるの増加サービス、増加したサービスインスタンス、
1.1サーバー発見モード
負荷またはルーティングサービスの終了により、ターゲットサービスへのクライアントアクセス。
サーバーの負荷と自身またはサードパーティ製のツールを使って、レジストリタイミング検出ハートビートのサービスとメンテナンスの新しいインスタンスを自動的に発見するために、要求を転送する責任があります。
長所：
サービスディスカバリ機能は、クライアントのに対して透過的である
短所：
前方の増加は、中心部への集中型のアプローチではありません
質問：
1.nignx / F5は、負荷分散サーバの発見はあなたに属している、ある、サービスアドレスリストを持っていますか？
「発見」機能、サービスインスタンスの主な欠点は、動的に増加または減少は、識別するためのイニシアチブを取ることはありません。
2.例として独自のサービスサーバに登録要求を送信し、それをすることはできませんか？
サービスインスタンスは、サービスプロバイダである、それはサービスコンシューマであってもよく、登録センターに登録要求を送信した場合、あなたはまた、レジストリからレジストリを引くことができますので、直接クライアントは良くない見つかりましたか？
1.2クライアントの検出モード
自分自身と使用負荷分散戦略上の使用可能なアドレスリストの例としては、サービスプロバイダのクライアントを決定することができます。
サービスプロバイダは、登録と登録センターにハートビートを送信します。
サーバーは、レジストリを維持するための唯一の責任がある、とサービスを提供しています。
長所：
クライアントが開発する、柔軟でインテリジェントな負荷分散戦略することができ
分権
欠点：
レジストリに結合されたクライアントを、中央の登録コードとの相互作用を達成するために必要
第二に、サービスは重要な役割エキスを見つけました
服务提供者：
向注册中心发送请求，发送信息
服务消费者：
向注册中心发送请求，获取信息
注册中心：
提供接口给服务发现客户端调用
维护服务实例信息集合
集群之间信息同步
三、关键角色要干些什么事情
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？
服务启动后会不会马上注册到注册中心？
服务提供者注册到注册中心后，服务消费者最快多久能够查询到该提供者？
为什么接收心跳后不入队，那么更新心跳后启不是增量查询查不到了？
集群同步的队列，为什么要经过一道中转才进行消费？
部分图片摘自如下文章：