AWS ELB也是一种传统的基于代理的负载平衡解决方案，而Eureka则不同之处在于负载平衡发生在实例/服务器/主机级别。客户端实例知道他们需要与哪些服务器交互的所有信息。这样的好坏取决于你怎么看待它。如果你想要AWS现在提供的基于粘滞用户session的负载均衡，Eureka没有开箱即用的解决方案。在Netflix，我们更喜欢我们的服务是无状态的(非粘性)。这有利于提供更好的扩展性，Eureka非常适合解决这个问题。(感觉这段也是吹水，现在的web交互大都是无状态的，状态通过redis，message queue等第三方维护，ELB照样可以提供)。
使用Eureka区分基于代理的负载平衡和负载平衡的另一个重要方面是，您的应用程序可以灵活地处理负载平衡器的中断，因为有关可用服务器的信息会缓存在客户端上。这确实需要少量的内存，但换得更好的弹性。
Eureka和Route 53有什么不同Route 53是一个域名服务，就像Eureka可以为中层服务器提供相同的服务一样，但仅此而已。 Route 53是一项DNS服务，即使对于非AWS数据中心，也可以托管您的DNS记录。 Route 53还可以在AWS区域间执行基于延迟的路由。Eureka类似于内部DNS，与全世界的DNS服务器无关。Eureka也是区域隔离的，因为它不知道其他AWS区域中的服务器。保存信息的主要目的是在区域内进行负载平衡。
虽然你可以在Route 53中注册你的中间层服务器，并依赖AWS安全组保护你的服务器不受外网访问，但你的中间层服务器身份仍然暴露于外网环境。它同样带有传统基于DNS的负载均衡方案的缺点，其中流量仍然会被路由到已经不健康或已经不存在的服务器上（在AWS云中，服务器随时可能消失）。
Eureka如何使用？在Netflix，Eureka不仅是中间层负载均衡关键部分，还有以下功能：
与Netflix Asgard一起提供红/黑部署服务， Asgard是一个让云部署更方便的开源服务。Eureka会与Asgard搭配，让应用在新/老版本部署切换，让故障处理更快速和无缝，尤其是当启动100个实例部署时要花费很长时间的时候。
当我们的cassandra需要维护时，停止Cassandra实例。
为我们的memcached缓存服务提供识别环上实例列表功能。
为特定的应用提供因意外导致故障保存元信息的服务。
Eureka使用时机？当你的服务运行在AWS云上并且你不希望使用AWS ELB注册或暴露给外网。你要么需要使用类似round-robin这种简单的负载均衡方案或者想要写一个基于Eureka包装过的符合要求的负载均衡器。你没有session粘性，没有session绑定机制和在外部缓存(例如 memcached)载入会话数据的需要。更重要的是，如果你的架构风格适合一个基于客户端的负载均衡模型，Eureka相当适合这个场景。
应用客户端和应用服务端如何通信？
通信技术可以是任何你喜欢的。Eureka帮你找到你需要通信的服务信息但没有引入任何通信协议或方法的限制。比如，你可以用Eureka获取目标服务器地址并使用thrift,http(s)或其他RPC机制的协议。
Eureka架构
上面的架构图描述了Eureka是如何在Netflix部署的，这也是Eureka集群的运行方式。在每个区域（region）都有一个eureka集群，它只知道该区域内的实例信息。每个分区（zone）至少有一个eureka服务器来处理本分区故障。
服务注册在Eureka上并且每30秒发送心跳来续租。如果一个客户端在几次内没有刷新心跳，它将在大约90秒内被移出服务器注册表。注册信息和更新信息会在整个eureka集群的节点进行复制。任何分区的客户端都可查找注册中心信息（每30秒发生一次）来定位他们的服务（可能会在任何分区）并进行远程调用。
非Java服务和客户端对于非Java的服务，你可以用其他语言实现eureka的客户端部分。基于REST的服务也暴露给了所有操作给Eureka客户端。非Java客户端也可以使用REST服务来查询其他服务的信息。
可配置有了Eureka，你可以动态添加删除集群节点。你可以调整内部配置，从超时到线程池。Eureka使用archaius并且如果你有一个配置源的实现，那么很多配置可以动态调优。
弹性在AWS云中，构建弹性伸缩必不可少。Eureka是我们经验的结晶，并且在客户端和服务端都内置了弹性能力。
Eureka客户端设计成可以处理一个或多个Eureka服务端的失败场景。由于Eureka客户端有注册表缓存信息，即使所有的eureka服务器都挂了，服务也能正常运行。