Eureka是基于REST（Representational State Transfer）服务，主要以AWS云服务为支撑，提供服务发现并实现负载均衡和故障转移。我们称此服务为Eureka服务。Eureka提供了Java客户端组件，Eureka Client，方便与服务端的交互。客户端内置了基于round-robin实现的简单负载均衡。在Netflix，为Eureka提供更为复杂的负载均衡方案进行封装，以实现高可用，它包括基于流量、资源利用率以及请求返回状态的加权负载均衡。
在AWS云，由于其天生的特性，服务器按需进行弹性伸缩。不像传统的负载均衡是基于固定的IP地址和host来实现，在AWS中，则需要提供更为复杂的负载均衡方案，以便对服务器进行注册和注销。由于AWS并未提供中间层负载均衡方案，Eureka的出世便填补了这个领域的巨大空白。
AWS ELB(Elastic Load Balancing)，即弹性负载均衡通过流量分发扩展应用系统对外的服务能力（类似阿里云SLB服务）。Eureka填补了中间层负载均衡的空缺。理论上你可以把中间层服务放在AWS ELB之后，但在EC2模型中，会将它们直接暴露到外网，从而失去了AWS安全组的所有好处。
AWS ELB亦是传统的基于代理实现的负载均衡解决方案而Eureka则与之不同，Eureka属于客户端发现模式，客户端负责决定相应服务实例的网络位置，并且对请求实现负载均衡。客户端从一个服务注册服务中查询所有可用服务实例的库，并缓存到本地。这样既有优点也有缺点，取决于你的关注点。如果你正寻找AWS提供的基于用户session粘滞的负载均衡，Eureka则没有开箱即用的方案。在Netflix，我们更乐意我们的服务是无状态的（非粘性）。这为更好的可伸缩性模型提供便利，Eureka也非常适合解决这个问题。
另一个重要方面，区分代理模式负载均衡和用Eureka实现负载均衡的不同，在于应用系统在负载均衡情况下宕机是否能够保证高可用，Eureka会将所有可用的服务信息缓存到客户端。这会消耗少量的内存，但能够提供更高的可用性。
Route 53是一种域名服务，类似与Eureka也可以提供中间层服务，但仅此而已。Route 53是一个DNS服务，它可以为非AWS数据中心提供DNS记录。Route 53也可以跨AWS区域通过路由进行延迟控制。Eureka类似于内部DNS，与世界各地的DNS服务器无关。Eureka也是一个区域隔离的服务，从某种意义上说，它不知道其他AWS区域的服务器。它的主要目的就是保持同一区域内信息的负载均衡。
虽然你可以在Route 53中注册你的中间层服务器，并依赖AWS安全组保护你的服务器不受外网访问，但你的中间层服务器身份仍然暴露于外网环境。它同样带有传统基于DNS的负载均衡方案的缺点，其中流量仍然会被路由到已经不健康或已经不存在的服务器上（在AWS云中，服务器随时可能消失）。
在Netflix，Eureka不仅是中间层负载均衡关键部分，还有以下功能：
与Netflix Asgard一起提供红/黑部署服务， Asgard是一个让云部署更方便的开源服务。Eureka会与Asgard搭配，让应用在新/老版本部署切换，让故障处理更快速和无缝，尤其是当启动100个实例部署时要花费很长时间的时候。
当我们的cassandra需要维护时，停止Cassandra实例。
为我们的memcached缓存服务提供识别环上实例列表功能。
为特定的应用提供因意外导致故障保存元信息的服务。
当你的服务运行在AWS云上并且你不希望使用AWS ELB注册或暴露给外网。你要么需要使用类似round-robin这种简单的负载均衡方案或者想要写一个基于Eureka包装过的符合要求的负载均衡器。你没有session粘性，没有session绑定机制和在外部缓存(例如 memcached)载入会话数据的需要。更重要的是，如果你的架构风格适合一个基于客户端的负载均衡模型，Eureka相当适合这个场景。
通信技术可以是任何你喜欢的。Eureka帮你找到你需要通信的服务信息但没有引入任何通信协议或方法的限制。比如，你可以用Eureka获取目标服务器地址并使用thrift,http(s)或其他RPC机制的协议。
Eureka架构
Eureka架构图
上面的架构图描述了Eureka是如何在Netflix部署的，这也是Eureka集群的运行方式。在每个区域（region）都有一个eureka集群，它只知道该区域内的实例信息。每个分区（zone）至少有一个eureka服务器来处理本分区故障。
服务注册在Eureka上并且每30秒发送心跳来续租。如果一个客户端在几次内没有刷新心跳，它将在大约90秒内被移出服务器注册表。注册信息和更新信息会在整个eureka集群的节点进行复制。任何分区的客户端都可查找注册中心信息（每30秒发生一次）来定位他们的服务（可能会在任何分区）并进行远程调用。
对于非Java的服务，你可以用其他语言实现eureka的客户端部分。基于REST的服务也暴露给了所有操作给Eureka客户端。非Java客户端也可以使用REST服务来查询其他服务的信息。
有了Eureka，你可以动态添加删除集群节点。你可以调整内部配置，从超时到线程池。Eureka使用archaius并且如果你有一个配置源的实现，那么很多配置可以动态调优。
在AWS云中，构建弹性伸缩必不可少。Eureka是我们经验的结晶，并且在客户端和服务端都内置了弹性能力。
Eureka客户端设计成可以处理一个或多个Eureka服务端的失败场景。由于Eureka客户端有注册表缓存信息，即使所有的eureka服务器都挂了，服务也能正常运行。
Eureka服务器对于其他eureka节点挂了也提供了足够的弹性。即使服务端和客户端之间产生了网络分区，服务器也由内置的弹性策略来防止大规模的停机。
在多个AWS区域部署Eureka是一个很简单的工作。不同区域之间Eureka集群并不通信。
Eureka使用servo来跟踪服务端和客户端的信息，包括性能，监控和报警。数据保存在JMX中并暴露给Amazon Cloud Watch。
PS：原文地址https://github.com/Netflix/eureka/wiki/Eureka-at-a-glance
网友评论