来源：
《微服务架构实战160讲》
https://www.cnblogs.com/xingzc/p/7543764.html
服务发现
1 常见模式
- 传统集中式代理（常见）
消费者通过dns，找到域名对应的proxy，由proxy发起请求
nginx建议使用集群，以免单点故障
- 服务注册中心+客户端嵌入式代理（常见）
- 主机独立进程代理（ServiceMesh）
不同的proxy可以进行通信，形成一个服务网格
服务端也可以加上Proxy，形成istio：
-
传统集中式代理+服务注册中心+客户端嵌入式代理
这样可以解决传统集中式代理中非自动化的问题 -
传统集中式代理+服务注册中心+客户端嵌入式代理变体
这样可以解决服务故障的问题
2 架构设计
-
Eureka
不同的Eureka位于不同的机房，之间进行复制，达到最终一致性，保证AP -
EurekaServer内存概念模型
每一个ApplicationServer对应多个实例 -
Ribbon(客户端负载均衡)
主要有6个组件，如图右侧
左侧为架构，Ribbon会定期向Eureka同步服务列表，Ping则检测服务是否健康（重点/易故障服务才需要，因为SyncServerList这一步就会进行检查，一般不会出问题）
Ribbon可以通过GET方式获取应用的信息：
四个层面会产生延迟：服务注册到EurekaServer，如报心跳后才成为up的耗时等；Eureka客户端每隔30s才去EurekaServer拉服务列表；EurekaServer收到拉请求后，30s后才处理完毕，进行响应；Eureka客户端收到响应后，隔了30s进行处理，才把服务列表更新完毕；最多可能需要2分钟才能得到最新的服务列表
3 高级功能
- 自保护模式
自我保护模式是一种应对网络异常的安全保护措施。
它的架构哲学是宁可同时保留所有微服务（健康的微服务和不健康的微服务都会保留），也不盲目注销任何健康的微服务。
使用自我保护模式，可以让Eureka集群更加的健壮和稳定。
- 健康检查
Eureka采用报心跳式检查，服务主动定期向EurekaServer报心跳，减少Eureka服务器的压力（PUT方式）
而报心跳上来，检查是否健康，可以通过HealthCheckHandler来定制检查健康逻辑
- Eureka+健康检查实现蓝绿发布
使用Asgard进行发布，使用putAPI将老实例，即instance2变为outofservice，这样就不会使用了
- 通过health端点检查快速发布
instance1需要经过心跳，即30s过后才能变为up，而使用Asgard，从EurekaServer拿到健康检查端点进行检查，如果通过了，就可以发布下一个，而不用等到instance1变为up才发布下一个，加快发布速度
4 持续交付架构
实现金丝雀和蓝绿部署， 如上2和4，如果新功能测试没问题，则由第7步全量切换，稳定之后发现新服务没问题，则删除老服务，否则切回老服务：
