要什么是Eureka，它与AWS又有什么关系？
Eureka是一个基于REST的服务，主要用在AWS云环境作为服务发现，负载均衡和失败转移。我们叫这个服务，Eureka服务。 Eureka也有一个JAVA客户端组件， Eureka Client，帮助与服务端更简单的交互。 客户端也有一个内置的负载均衡做简单的round-robin均衡。 在Netflix, 很多更高级的负载均衡器包装了Eureka来提供基于很多其他因子，如流量，资源利用率，错误情况等权重的负载均衡。
为什么需要Eureka？
在AWS云，由于其天生的属性，服务器来来去去。不像传统的负载均衡是与已知的IP地址和机器名工作，在AWS,负载均衡需要更多更复杂的注册，解注册服务。由于AWS还没有提供一个中间层负载均衡，Eureka填补了这个中间层负载均衡的巨大空缺。
Eureka与AWS ELB有什么不同？
AWS Elastic Load Banancer是一个暴露给终端用户网络流量的服务边缘负载均衡方案。Eureka是作为中间层负载均衡的补充。理论上你可以把中间层服务放在AWS ELB之后， 如果在EC2模型中你把他们直接暴露给外部世界但失去了所有AWS安全组的好处。
AWS ELB也是一个传统的代理类型的负载均衡方案然而Erueka是不同的，负载均衡发生在实例/服务器/主机级别。客户端实例知道所有关于他们需要与哪台服务器通信的信息。基于你看的角度这可能会是好处也是坏处。如果你寻找的是AWS提供的基于用户session粘滞的负载均衡，Eureka没有一个开箱即用的方案。在Netflix，我们更需要我们的服务是无状态的（无粘滞）。这是一个更好的扩展模型并且Eureka很适合做这个。
另一个与代理模式负载均衡和用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的云服务里任何时候服务器都可能消失）。
Netflix是怎么使用Eureka的？
在Netflix，Eureka除了作为一个中间层负载均衡的关键部分，还作为以下的原因。
作为与Netflix Asgard一起的红黑部署 - Asgard一个让云部署更方便的开源服务。Eureka会与Asgard交互，让应用在新/老版本部署切换，让故障处理更快速和无缝 - 尤其是当启动100个实例部署时要花费很长时间的时候。
当我们的cassandra需要维护时摘掉实例。
为我们的memcached缓存服务提供识别环上实例列表功能。
由于各种各样的原因提供保存其他应用特有原信息的服务。
什么时候使用Eureka？
你运行在AWS云上并且你有很多不像注册在AWS ELB上或暴露给外部的中间层服务。你想找一个简单的round-robin的负载均衡方案或者想要写一个基于Eureka包装过的符合你要求的负载均衡器。你不需要session粘滞和将session数据保存在一个像memcache的外部缓存。更重要的是，如果你的架构风格适合一个基于客户端的负载均衡模型，Eureka相当适合这个场景。
应用客户端和应用服务端怎么通信？
通信技术可以试试任何你喜欢的。Eureka帮你找到你需要通信的服务信息但没有引入任何通信协议或方法的限制。比如，你可以用Eureka获得目标机器地址并使用thrift,http(s)或其他RPC机制的协议。
高层架构
以上架构解释了Eureka是怎样在Netflix部署的并也是你会运行的状态。在每个区域（region）都会有一个eureka集群，它只知道关于这个区域内的实例信息。每个zone都至少也有一个eureka服务器来处理zone级别容灾。
服务注册在Eureka上并且每30秒发送心跳来续命。如果一个客户端在几次内没有刷新心跳，它会在90秒后被移出服务器注册信息。注册信息和刷新信息会在整个eureka集群的节点进行复制。任何zone的客户端都可看到注册信息（每30秒发生）去定位他们的服务（可能会在任何zone）并做远程调用。
非Java服务和客户端
对于非Java的服务，你可以用其他语言实现eureka的客户端部分。基于REST的服务也暴露给了所有操作给Eureka客户端。非Java客户端也可以使用REST服务来查询其他服务的信息。
可配置
使用Eureka你可以在集群中随意添加删除节点。你可以调各种内部配置，从超时到线程池。Eureka使用archaius并且如果你又一个配置源的实现那么可以动态调整很多东西。
弹性
在AWS云，很难不去思考构建弹性伸缩。Eureka使我们经验的结晶，在客户端和服务端都内置了弹性能力。
Eureka客户端设计成可以处理一个或多个Eureka服务端的失败场景。由于Eureka客户端有注册信息的缓存，他们可以很从容的处理失败，就算是所有的eureka服务器都挂了也可以。
Eureka服务器对于其他eureka节点挂了也有足够的弹性。就算是服务端和客户端产生了网络分区，服务器也有内置的弹性策略来防止大面积的停机。
多区域（Region）
在多个AWS区域部署Eureka是一个很简单的工作。多个区域的Eureka集群之间并不通信。
监控
Eureka用servo来追踪服务端和客户端的信息，包括性能，监控和报警。数据保存在JMX中并暴露给Amazon Cloud Watch。
What is Eureka and what is its relationship with AWS?
Eureka is a REST-based service primarily used in the AWS cloud environment for service discovery, load balancing, and failover. We call this service the Eureka service. Eureka also has a Java client component, the Eureka Client, which helps simplify interaction with the server. The client also has a built-in load balancer for simple round-robin balancing. At Netflix, many advanced load balancers wrap Eureka to provide load balancing based on many other factors, such as traffic, resource utilization, error conditions, and other weights.
Why Do We Need Eureka?
In the AWS cloud, due to its inherent nature, servers come and go. Unlike traditional load balancers that work with known IP addresses and machine names, in AWS, load balancers need more complex service registration and deregistration. Since AWS does not yet provide a middle-tier load balancer, Eureka fills this significant gap for middle-tier load balancing.
How is Eureka Different from AWS ELB?
AWS Elastic Load Balancer is a service-edge load balancing solution exposed to end-user network traffic. Eureka serves as a complement for middle-tier load balancing. Theoretically, you can put middle-tier services behind AWS ELB, but if you expose them directly to the outside world in the EC2 model, you lose all the benefits of AWS security groups.
AWS ELB is also a traditional proxy-based load balancing solution, whereas Eureka is different - load balancing happens at the instance/server/host level. Client instances know all the information about which servers they need to communicate with. Depending on your perspective, this can be both an advantage and a disadvantage. If you're looking for session sticky load balancing provided by AWS, Eureka doesn't have an out-of-the-box solution. At Netflix, we prefer our services to be stateless (non-sticky). This is a better scaling model and Eureka fits well for this.
Another difference between proxy-based load balancing and Eureka-based load balancing is that your application is more resilient when the load balancer goes down, because all information about available servers is cached on the client. This does require some memory, but buys better resilience.
How is Eureka Different from Route 53?
Route 53 is a domain name service. Similarly, Eureka can provide the same middle-tier service, but the similarities end there. Route 53 is a DNS service that can even provide your DNS records in non-AWS data centers. Route 53 can also perform latency-based routing between AWS regions. Eureka is synonymous with internal DNS and has nothing to do with external DNS services. Broadly speaking, Eureka is also a region-isolated service that doesn't know about servers in other AWS regions. Its main purpose is to hold information within a region for load balancing purposes.
You can register your middle-tier services on Route 53 and use AWS security groups to protect your public servers, but this way your middle-tier servers are still exposed externally. It also has the same drawbacks as traditional DNS-based load balancing solutions - traffic may still be routed to servers that are unhealthy or no longer exist (in AWS cloud services, servers can disappear at any time).
How Does Netflix Use Eureka?
At Netflix, in addition to being a key part of middle-tier load balancing, Eureka serves the following purposes.
Red-black deployment with Netflix Asgard - Asgard is an open source service that makes cloud deployment easier. Eureka interacts with Asgard to switch applications between new/old version deployments, making failure handling faster and seamless - especially when deploying 100 instances takes a long time.
Removing instances when our cassandra needs maintenance.
Providing instance list identification on the ring for our memcached caching service.
Providing services to store other application-specific metadata for various reasons.
When to Use Eureka?
You run on the AWS cloud and have many middle-tier services that you don't want to register on AWS ELB or expose to the outside. You want a simple round-robin load balancing solution or want to write a load balancer wrapped around Eureka that meets your requirements. You don't need session stickiness and store session data in an external cache like memcache. More importantly, if your architectural style fits a client-based load balancing model, Eureka is quite suitable for this scenario.
How Do Application Clients and Application Servers Communicate?
Communication technology can be anything you like. Eureka helps you find the service information you need to communicate with but doesn't impose any restrictions on communication protocols or methods. For example, you can use Eureka to get the target machine address and use protocols like thrift, http(s), or other RPC mechanisms.
High-Level Architecture
The above architecture explains how Eureka is deployed at Netflix and how you would run it. There is a Eureka cluster in each region, which only knows about instance information within that region. Each zone also has at least one Eureka server to handle zone-level disaster recovery.
Services register with Eureka and send heartbeats every 30 seconds to renew. If a client doesn't refresh the heartbeat within a few attempts, it will be removed from the server registry after 90 seconds. Registration information and refresh information are replicated across all nodes in the Eureka cluster. Clients in any zone can see the registration information (happens every 30 seconds) to locate their services (potentially in any zone) and make remote calls.
Non-Java Services and Clients
For non-Java services, you can implement the Eureka client part in other languages. REST-based services are also exposed for all operations to Eureka clients. Non-Java clients can also use REST services to query information about other services.
Configurable
Using Eureka, you can add or remove nodes in the cluster at will. You can tune various internal configurations, from timeouts to thread pools. Eureka uses archaius and if you have a configuration source implementation, you can dynamically adjust many things.
Resilience
In the AWS cloud, it's hard not to think about building elastic scaling. Eureka is the crystallization of our experience, with built-in resilience capabilities on both client and server sides.
Eureka clients are designed to handle failure scenarios of one or more Eureka servers. Since Eureka clients have a cache of registration information, they can handle failures gracefully, even if all Eureka servers go down.
Eureka servers are also sufficiently resilient to other Eureka node failures. Even if there's a network partition between the server and client, the server has built-in resilience strategies to prevent large-scale outages.
Multi-Region
Deploying Eureka across multiple AWS regions is a simple task. Eureka clusters in multiple regions do not communicate with each other.
Monitoring
Eureka uses servo to track server and client information, including performance, monitoring, and alerting. Data is saved in JMX and exposed to Amazon Cloud Watch.