目录
Netflix Eureka 简介
1、Eureka 是 Netflix 公司开发的服务发现框架，Spring Cloud 对它提供了支持，将它集成在了自己的 spring-cloud-netflix 子项目中。
2、Netflix 公司在 Github 上开源了很多项目，Eureka 只是其中一个，Netflix 开源主页：https://github.com/Netflix
3、Netflix Eureka GitHub 开源地址：https://github.com/Netflix/eureka。
AWS Service registry for resilient mid-tier load balancing and failover.（Eureka 是用于弹性中间层负载平衡和故障转移的AWS服务注册中心）
4、Eureka 是一种基于 REST（表现层状态转换） 的服务，主要用于 AWS（Amazon Web Services-亚马逊web服务） 云中定位服务，以实现中间层服务器的负载平衡和故障转移。
5、The build requires java8 because of some required libraries that are java8 (servo), but the source and target compatibility are still set to 1.7.（构建 Eureka 项目需要 Java JDK 1.8以上版本，因为其中一些必须的库使用了 Java8）
6、Netflix Eureka 官方文档：https://github.com/Netflix/eureka/wiki，目前最新版是 2019年1月11更新的 V1.9.9。
7、Netflix Eureka 官网原来是 2.X 版本的，后面因为某些原因停止了 2.X 版本的维护，但是 1.X 版本仍然活跃，仍在积极开发、维护、和使用，WIKI 中公示如下：
Eureka 2.0 (Discontinued)（Eureka2.0 已经停止）
The existing open source work on eureka 2.0 is discontinued. The code base and artifacts that were released as part of the existing repository of work on the 2.x branch is considered use at your own risk.Eureka 1.x is a core part of Netflix's service discovery system and is still an active project.
（现有的 Eureka 2.0开源工作已经停止。继续使用 2.x 分支上的代码将由您自己承担风险。Eureka 1.x 是 Netflix 服务发现系统的核心部分，仍然是一个活跃的项目。）
spring-cloud-netflix 简介
1、Spring Cloud 将 Netflix Eureka 集成在其子项目 spring-cloud-netflix 中，以实现 Spring Cloud 的服务发现功能。
2、spring-cloud-netflix 子项目包含的不仅仅只有 Eureka，使用 Netflix 组件构建大型分布式系统，提供的模式包括服务发现(Eureka)、断路器(Hystrix)、智能路由(Zuul)、以及客户端负载平衡(Ribbon)。
3、Spring Cloud Netflix features（特性）：
| 编号 | 特性 | 描述 |
| 1 | Service Discovery（服务发现） | 可以注册 Eureka 实例，客户端可以使用 spring 管理的 bean 发现实例 |
| 2 | Service Discovery（服务发现） | 可以使用声明性 Java 配置创建嵌入式 Eureka 服务器 |
| 3 | Circuit Breaker（断路器） | Hystrix 客户端可以用一个简单的注解驱动的方法装饰器来构建 |
| 4 | Circuit Breaker（断路器） | 带有声明性 Java 配置的嵌入式 Hystrix 仪表板 |
| 5 | Declarative REST Client（声明性REST客户端） | Feign创建了一个用JAX-RS或Spring MVC注释装饰的接口的动态实现 客户端负载均衡器:Ribbon |
| 6 | Client Side Load Balancer（客户端负载均衡器） | Ribbon |
| 7 | External Configuration（外部配置） | 从Spring环境到Archaius的桥梁(使用Spring引导约定支持Netflix组件的本地配置) |
| 8 | Router and Filter（路由器和过滤器） | zuul过滤器的自动重新定位，以及反向创建代理的配置方法的简单约定 |
Eureka 原理
1、官网介绍地址：https://github.com/Netflix/eureka/wiki/Eureka-at-a-glance。
2、Eureka 官方的“区域”概念来自 AWS（Amazon Web Services-亚马逊web服务），亚马逊为全球提供云服务，所以在全球范围内划分了不同的区域，如下是其中的8个区域，另外还有中国区，以及专门为美国政府使用的一个区。
3、一个区域可以包含多个可用区。
3、Eureka 高层体系结构图就是针对单个区域中的多个可用区进行说明的，us-eat-1c、us-eat-1d、us-eat-1e 表示为同一个区域（ us-eat-1）中的 3 个可用区。
4、上图来自 Eureka 官方架构图，描述了 Eureka 集群的工作过程。每个区域都有一个 Eureka 集群，它只知道其区域中的实例，每个区域至少有一个 Eureka 服务器来处理区域故障。
1）Application Service：服务提供者
2）Application Client：服务消费者
3）Make Remote Call：可以简单理解为调用 RESTful 的接口
4）us-east-1c、us-east-1d ...都是可以区，都属于 us-east-1 这个region（区域）
5、如图所示 Eureka 包含两个组件：Eureka Server 和 Eureka Client。 Eureka Server 提供服务注册服务，各个节点启动后，会在 Eureka Server 中进行注册，这样 Eureka Server 中的服务注册表中将会存储所有可用服务节点的信息，服务节点的信息可以在界面中直观的看到。
6、Eureka Client 是一个 Java 客户端，用于简化与 Eureka Server 的交互，客户端同时也具备一个内置的、使用轮询（round-robin）负载算法的负载均衡器。
7、应用启动后，Eureka Client 将会向 Eureka Server发送心跳（默认周期为30秒），如果Eureka Server在多个心跳周期内没有接收到某个节点的心跳，Eureka Server将会从服务注册表中把这个服务节点移除（默认90秒）。
8、Eureka Server 之间将会通过复制（Replicate）的方式完成数据的同步。
9、Eureka 还提供了客户端缓存的机制，即使所有的 Eureka Server 都挂掉，客户端依然可以利用缓存中的信息消费其他服务的API。
10、Eureka 通过心跳检测、健康检查、客户端缓存等机制，确保了系统的高可用性、灵活性和可伸缩性。
服务发现
为什么要使用服务发现?
1、运行在物理硬件上的传统应用中，服务实例的网络位置是相对固定的，代码能从一个偶尔更新的配置文件中读取网络位置。对于基于云端的、现代化的微服务应用而言，这却是一大难题。
服务实例的网络位置都是动态分配的，由于服务扩展升级、失败宕机等等，服务实例会经常动态改变，因此客户端代码需要使用更加复杂的服务发现机制。
服务发现有两大模式：客户端发现模式和服务端发现模式。
客户端发现模式
1、使用客户端发现模式时，客户端决定相应服务实例的网络位置，并且对请求实现负载均衡。客户端查询服务注册表，然后使用负载均衡算法从中选择一个实例，并发出请求。
2、服务注册表是一个可用服务实例的数据库，其中包含所有可用的服务实例，客户端从服务注册服务中查询，然后使用负载均衡算法从多个服务实例中选择出一个服务实例，最后发出请求。
3、服务实例的网络位置在启动时被记录到服务注册表，等实例终止时被删除，服务实例的注册信息通常使用心跳机制来定期刷新（如 Eureka客户端默认会30秒发送一次心跳，超过90秒未收到心跳，则会被移除）。
4、Netflix Eureka 其中就有服务注册表功能，为服务实例注册管理和查询可用实例提供了 REST API 接口，Netflix Ribbon 是 IPC 客户端，与 Eureka 一起实现对请求的负载均衡。（Eureka与Ribbon都已经集成在了Rispring-cloud-netflix项目中的）
5、客户端发现模式优缺点兼有。这一模式相对直接，除了服务注册外，其它部分无需变动。此外，由于客户端知晓可用的服务实例，能针对特定应用实现智能负载均衡，比如使用哈希一致性。这种模式的一大缺点就是客户端与服务注册绑定，要针对服务端用到的每个编程语言和框架，实现客户端的服务发现逻辑。
服务端发现模式
Consul + Nginx，请参考：http://blog.daocloud.io/microservices-4/
服务注册表
1、服务注册表是服务发现的核心部分，是包含服务实例的网络地址的数据库。服务注册表需要高可用而且随时更新。客户端能够缓存从服务注册表中获取的网络地址，然而，这些信息最终会过时，客户端也就无法发现服务实例。因此，服务注册表会包含若干服务端，使用复制协议保持一致性。
2、Netflix Eureka 是服务注册表的上好案例，为注册和请求服务实例提供了 REST API。服务实例使用 POST 请求来注册网络地址，每三十秒使用 PUT 请求来刷新注册信息。注册信息也能通过 HTTP DELETE 请求或者实例超时来被移除。以此类推，客户端能够使用 HTTP GET 请求来检索已注册的服务实例。
3、Netflix 通过在每个 AWS EC2 域运行一个或者多个 Eureka 服务实现高可用性。每个 Eureka 服务器都运行在拥有弹性 IP 地址的 EC2 实例上。DNS TEXT 记录被用来保存 Eureka 集群配置，后者包括可用域和 Eureka 服务器的网络地址列表。Eureka 服务在启动时会查询 DNS 去获取 Eureka 集群配置，确定同伴位置，以及给自己分配一个未被使用的弹性 IP 地址。
4、Eureka 客户端，包括服务和服务客户端，查询 DNS 去发现 Eureka 服务的网络地址。客户端首选同一域内的 Eureka 服务。然而，如果没有可用服务，客户端会使用其它可用域中的 Eureka 服务。
5、除了 Eureka ，主流的服务发现组件(提供服务注册表）还有：
1）etcd – 高可用、分布式、一致性的键值存储，用于共享配置和服务发现。Kubernetes 和 Cloud Foundry 是两个使用 etcd 的著名项目。
2）consul – 发现和配置的服务，提供 API 实现客户端注册和发现服务。Consul 通过健康检查来判断服务的可用性。
3）Apache ZooKeeper – 被分布式应用广泛使用的高性能协调服务。Apache ZooKeeper 最初是 Hadoop 的子项目，现在已成为顶级项目。
6、服务实例必须在注册表中注册和注销。注册和注销有两种不同的方法。方法一是服务实例自己注册，也叫自注册模式（self-registration pattern）；另一种是采用管理服务实例注册的其它系统组件，即第三方注册模式
自注册方式
1、当使用自注册模式时，服务实例负责在服务注册表中注册和注销，另外，如果需要的话，一个服务实例也要发送心跳来保证注册信息不会过时。
2、Netflix OSS Eureka 客户端是非常好的案例，它负责处理服务实例的注册和注销。Spring Cloud 能够执行包括服务发现在内的各种模式，使得利用 Eureka 自动注册服务实例更简单，只需要给 Java 配置类注释 @EnableEurekaClient。
3、自注册模式优缺点兼备。它相对简单，无需其它系统组件。然而，它的主要缺点是把服务实例和服务注册表耦合，必须在每个编程语言和框架内实现注册代码。
第三方注册模式
1、使用第三方注册模式，服务实例则不需要向服务注册表注册，而由被称为服务注册器的另一个系统模块会处理。
2、服务注册器会通过查询部署环境或订阅事件的方式来跟踪运行实例的更改，一旦侦测到有新的可用服务实例，会向注册表注册此服务，服务管理器也负责注销终止的服务实例。
3、Registrator 是一个开源的服务注册项目，它能够自动注册和注销被部署为 Docker 容器的服务实例。Registrator 支持包括 etcd 和 Consul 在内的多种服务注册表。
4、Netflix OSS Prana 是另一个服务注册器，主要面向非 JVM 语言开发的服务，是一款与服务实例一起运行的并行应用。Prana 使用 Netflix Eureka 来注册和注销服务实例。
5、服务注册器是部署环境的内置组件，由 Autoscaling Group 创建的 EC2 实例能够自动向 ELB 注册，Kubernetes 服务自动注册并能够被发现。
6、第三方注册模式也是优缺点兼具。在第三方注册模式中，服务与服务注册表解耦合，无需为每个编程语言和框架实现服务注册逻辑；相反，服务实例通过一个专有服务以中心化的方式进行管理。它的不足之处在于，除非该服务内置于部署环境，否则需要配置和管理一个高可用的系统组件。
总结
1、在微服务应用中，服务实例的运行环境会动态变化，实例网络地址也是如此，因此客户端为了访问服务必须使用服务发现机制。
2、服务注册表是服务发现的关键部分，服务注册表是可用服务实例的数据库，提供管理 API 和查询 API，服务实例使用管理 API 来实现注册和注销，系统组件使用查询 API 来发现可用的服务实例。
3、服务发现有两种主要模式：客户端发现和服务端发现。在使用客户端服务发现的系统中，客户端查询服务注册表，选择可用的服务实例，然后发出请求。在使用服务端发现的系统中，客户端通过路由转发请求，路由器查询服务注册表并转发请求到可用的实例。
4、服务实例的注册和注销也有两种方式。一种是服务实例自己注册到服务注册表中，即自注册模式；另一种则是由其它系统组件处理注册和注销，也就是第三方注册模式。
5、在一些部署环境中，需要使用 Netflix Eureka、etcd、Apache Zookeeper 等服务发现来设置自己的服务发现基础设施。而另一些部署环境则内置了服务发现。例如，Kubernetes 和 Marathon 处理服务实例的注册和注销，它们也在每个集群主机上运行代理，这个代理具有服务端发现路由的功能。
6、HTTP 反向代理和 Nginx 这样的负载均衡器能够用做服务器端的服务发现均衡器。服务注册表能够将路由信息推送到 Nginx 激活配置更新，譬如使用 Cosul Template。Nginx Plus 支持额外的动态配置机制，能够通过 DNS 从注册表中获取服务实例的信息，并为远程配置提供 API。
英文原文：https://www.nginx.com/blog/service-discovery-in-a-microservices-architecture/
翻译原文：http://blog.daocloud.io/microservices-4/
210
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
