什么是服务发现与服务注册

简单的来说就是一个微服务要调用另一个微服务，就必须知道这个微服务的地址及端口信息。采用一张注册表，注册上线可用的微服务及相关信息，微服务则从注册表上查找所需的其它微服务的相关信息。有两种主要的服务发现模式：客户端服务发现（client-side discovery）和服务器端服务发现（server-side discovery）愿意了解源码的朋友直接求求交流分享技术：二一四七七七五六三三

客户端发现

服务端服务发现

当发送请求到一个service的时候，客户端发送请求到一个router，这个router是在一个已知的地址上运行的。router查询service registry（可能在这个router中实现）, 然后把请求发送到可用的service实例。如下所示： 

服务发现组件的功能

服务注册表 
服务注册表是一个记录当前可用服务实例的网络信息的数据库，是服务发现机制的核心。服务注册表提供查询API和管理API，使用查询API获得可用的服务实例，使用管理API实现注册和注销；
服务注册 
服务注册:服务启动时，将服务的网络地址注册到服务注册表中；
健康检查 
服务发现组件会通过一些机制定时检测已注册的服务，如果发现某服务无法访问了（可能是某几个心跳周期后），就将该服务从服务注册表中移除。
服务发现组件：Eureka

Eureka是客户端发现类型的服务发现模式
Eureka来自生产环境
Spring Cloud对Eureka支持很好

上图是来自Eureka官方的架构图，大致描述了Eureka集群的工作过程。 
Eureka有两个概念，区域（Region)与可用区(Zone)，不太理解，先抄过来占个位置。

区域（Region):

AWS云服务在全球不同的地方都有数据中心，比如北美、南美、欧洲和亚洲等。与此对应，根据地理位置我们把某个地区的基础设施服务集合称为一个区域。通过AWS的区域，一方面可以使得AWS云服务在地理位置上更加靠近我们的用户，另一方面使得用户可以选择不同的区域存储他们的数据以满足法规遵循方面的要求。美东（北佛吉尼亚）、美西（俄勒冈）、美西（北加利佛尼亚）、欧洲（爱尔兰）、亚太（新加坡）、亚太（东京）等。每个区域都有自己对应的编码，如：编码对应
可用区(Zone):

AWS的每个区域一般由多个可用区（AZ）组成，而一个可用区一般是由多个数据中心组成。AWS引入可用区设计主要是为了提升用户应用程序的高可用性。因为可用区与可用区之间在设计上是相互独立的，也就是说它们会有独立的供电、独立的网络等，这样假如一个可用区出现问题时也不会影响另外的可用区。在一个区域内，可用区与可用区之间是通过高速网络连接，从而保证有很低的延时。AWS的区域与可用区的关系示意如下图所示：可用区 
每次当用户需要使用EC2相关资源的时候，他需要首先选择目标区域，如美东（北佛杰尼亚）us-east-1。然后在创建EC2实例的时候，用户可以选择实例所在的可用区，比如可以是us-east-1a或us-east-1b等。可用区的编码就是区域后面顺序添加不同的英文字母。
Eureka在springcloud中的使用

Eureka包含两个组件：Eureka Server 和 Eureka Client。

Eureka Server提供服务注册服务，各个节点启动后，会在Eureka Server中进行注册，这样Eureka Server中的服务注册表中将会存储所有可用服务节点的信息，服务节点的信息可以在界面中直观的看到。
Eureka Client是一个Java客户端，用于简化与Eureka Server的交互，客户端同时也具备一个内置的、使用轮询（round-robin）负载算法的负载均衡器。
在应用启动后，将会向Eureka Server发送心跳（默认周期为30秒）。如果Eureka Server在多个心跳周期内没有接收到某个节点的心跳，Eureka Server将会从服务注册表中把这个服务节点移除（默认90秒）。
Eureka Server之间将会通过复制的方式完成数据的同步。
Eureka还提供了客户端缓存的机制，即使所有的Eureka Server都挂掉，客户端依然可以利用缓存中的信息消费其他服务的API。
综上，Eureka通过心跳检测、健康检查、客户端缓存等机制，确保了系统的高可用性、灵活性和可伸缩性。

整体代码结构如下： 资料和源码来源