http://blog.csdn.net/defonds/article/details/38067867
亚马逊提供了一个负载均衡工具 Elastic Load Balancer，但针对的是终端用户 Web 流量服务器，而 Eureka 针对的是中间层服务器的负载均衡。AWS 固有的环境，对 IP 地址、主机名等传统的负载均衡支持并不好，并且需要更加复杂的注册/退出机制。Eureka 填补了这一空白。本文在前边几篇博客的基础上，较为系统地介绍一下 Eureka。
Eureka 是什么
官方给出的具体定义是"Eureka is a REST (Representational State Transfer) based service that is primarily used in the AWS cloud for locating services for the purpose of load balancing and failover of middle-tier servers."，翻译过来就是："Eureka 是一个基于 REST 的服务，它主要是用于定位服务，以实现 AWS 云端的负载均衡和中间层服务器的故障转移"。
Eureka VS ELB
亚马逊 ELB 针对的是终端用户 Web 流量服务器，Eureka 针对的是中间层服务器。
Why Eureka？
AWS 对 IP 地址、主机名等传统的负载均衡支持并不好，并且需要更加复杂的注册/退出机制。AWS 并没有提供一个中间层负载均衡器，Eureka 填补了这一空白。
Eureka 的适用场景
Eureka 的架构图如下所示
从图中我们可以看出，Eureka 组件分为两部分：Eureka 服务器和 Eureka 客户端。而客户端又分为 Application Service 客户端和 Application Client 客户端两种。
Eureka 的工作机制
每个 region 都有自己的 Eureka 服务器集群，每个 zone 至少要有一个 Eureka 服务器以应对 zone 瘫痪。
Application Service 在启动时注册到 Eureka 服务器，之后每 30 秒钟发送心跳以更新自身状态。如果该客户端没能发送心跳更新，它将在 90 秒之后被其注册的 Eureka 服务器剔除。来自任意 zone 的 Application Client 可以查看这些注册信息(每隔 30 秒查看一次)并依此定位自己的侍服 Application Service 实例，进而进行远程调用。
Q：我的 Application Service 和 Application Client 之间通信会不会受到 Eureka 限制
A：不会。Eureka 只是帮你找到该次侍服主机实例，并不对你的 Application Service 和 Client 之间的通信协议和方法进行约束。
Q：看了这些感觉好抽象，有没有可以开始的 demo
可以查看 Eureka 的 github 以寻求 demo。有些 feature(比如 Eureka 和 Ribbon 的集成)并没有提供 demo，但我们可以从 Eureka 的 github 提供的单元测试代码中获得一些启示。
另外，笔者也整理了很多 demo，都是自己动手验证通过的，读者可以放心参考：
Eureka 部署的测试
你可以自己写脚本，然后手工将集群节点宕机，以验证 Eureka 部署的弹性效果 - Eureka 使用 servo 来跟踪客户端和服务器端的性能，并进行监控和报警，这些数据可用于 JMX 注册也可以输出给亚马逊的云监控。当然你也可以使用 Netflix 的另一个开源工具 - SimianArmy，这只调皮的小猴子会故意将你的服务节点搞下线以验证你的 Eureka 部署对随机的 Application Service 宕机的处理的弹性。
Q：有没有一个真实的应用案例
接下来以一个真实生产环境下的场景，来看一下 Eureka 在实际当中的应用。
以下是流媒体服务器 Wowza 直播的部署架构图：
Wowza 服务器侍服外部网络直播流量，但它需要去 CAS 服务器验证用户，还需要去 Relay 服务器读取直播流。CAS 和 Relay 就是两个中间层服务，不需要直接暴露给外界。以下是它们之间的时序交互图：
参考资料
Eureka 是什么
官方给出的具体定义是"Eureka is a REST (Representational State Transfer) based service that is primarily used in the AWS cloud for locating services for the purpose of load balancing and failover of middle-tier servers."，翻译过来就是："Eureka 是一个基于 REST 的服务，它主要是用于定位服务，以实现 AWS 云端的负载均衡和中间层服务器的故障转移"。
Eureka VS ELB
亚马逊 ELB 针对的是终端用户 Web 流量服务器，Eureka 针对的是中间层服务器。
Why Eureka？
AWS 对 IP 地址、主机名等传统的负载均衡支持并不好，并且需要更加复杂的注册/退出机制。AWS 并没有提供一个中间层负载均衡器，Eureka 填补了这一空白。
Eureka 的适用场景
- AWS 的环境下有一个中间层服务，但不想将其注册到 ELB，或者不想将其暴露给外部世界
- 不需要 session 绑定机制，没有粘性会话和在外部缓存(例如 memcached)载入会话数据的需要
- 自己实现 LB 算法
Eureka 的架构图如下所示
从图中我们可以看出，Eureka 组件分为两部分：Eureka 服务器和 Eureka 客户端。而客户端又分为 Application Service 客户端和 Application Client 客户端两种。
Eureka 的工作机制
每个 region 都有自己的 Eureka 服务器集群，每个 zone 至少要有一个 Eureka 服务器以应对 zone 瘫痪。
Application Service 在启动时注册到 Eureka 服务器，之后每 30 秒钟发送心跳以更新自身状态。如果该客户端没能发送心跳更新，它将在 90 秒之后被其注册的 Eureka 服务器剔除。来自任意 zone 的 Application Client 可以查看这些注册信息(每隔 30 秒查看一次)并依此定位自己的侍服 Application Service 实例，进而进行远程调用。
Q：我的 Application Service 和 Application Client 之间通信会不会受到 Eureka 限制
A：不会。Eureka 只是帮你找到该次侍服主机实例，并不对你的 Application Service 和 Client 之间的通信协议和方法进行约束。
Q：看了这些感觉好抽象，有没有可以开始的 demo
可以查看 Eureka 的 github 以寻求 demo。有些 feature(比如 Eureka 和 Ribbon 的集成)并没有提供 demo，但我们可以从 Eureka 的 github 提供的单元测试代码中获得一些启示。
另外，笔者也整理了很多 demo，都是自己动手验证通过的，读者可以放心参考：
- 《Linux 下 Eureka 服务器的部署》
- 《Eureka 的 Application Service 客户端的注册以及运行示例》
- 《Eureka 的 Application Client 客户端的运行示例》
- 《云中间层服务 - 区域感知负载均衡器 Ribbon》
- 《Ribbon 和 wowza 的集成开发》
- 《Ribbon 和 Eureka 的集成》
Eureka 部署的测试
你可以自己写脚本，然后手工将集群节点宕机，以验证 Eureka 部署的弹性效果 - Eureka 使用 servo 来跟踪客户端和服务器端的性能，并进行监控和报警，这些数据可用于 JMX 注册也可以输出给亚马逊的云监控。当然你也可以使用 Netflix 的另一个开源工具 - SimianArmy，这只调皮的小猴子会故意将你的服务节点搞下线以验证你的 Eureka 部署对随机的 Application Service 宕机的处理的弹性。
Q：有没有一个真实的应用案例
接下来以一个真实生产环境下的场景，来看一下 Eureka 在实际当中的应用。
以下是流媒体服务器 Wowza 直播的部署架构图：
Wowza 服务器侍服外部网络直播流量，但它需要去 CAS 服务器验证用户，还需要去 Relay 服务器读取直播流。CAS 和 Relay 就是两个中间层服务，不需要直接暴露给外界。以下是它们之间的时序交互图：
参考资料
京公网安备 11010502036488号