MicroService--ServiceDiscovery

以Eureka为例，分析微服务中的服务注册于服务发现，Eureka是一个服务注册于服务发现的组件，是Netflix 公司的开源产品，能与负载均衡组件Ribbon，熔断组件Hystix，网管组件Zuul无缝整合，是SpringCloud最基础组件。

Eureka 工作的基本流程：
首先需要一个服务注册中心Eureka Server，其他的服务提供者和服务消费者将自己的信息（服务名称，服务的IP，服务的port等）通过REST API的形式提交给服务注册中心Eureka Server来注册，同时服务消费者获取一份服务列表信息，该列表包含了所有向服务注册中心Eureka Server注册的服务信息，服务消费者获取服务列表信息后，服务消费者就知道服务提供者的IP地址，可以通过HTTP远程调度来消费服务提供者的服务。

什么是服务发现：
服务发现提供了一种协调机制，方便服务的发布和查找，是支持大规模SOA的核心服务，在一定规模的应用系统中，服务的数量可能是几十个上百个，服务中有消费者，身缠着，那么消费者如何发现生产者这个时候需要提供一种机制来解决这个问题。

为什么需要服务发现？
当实现一个or一组服务时，服务调用方需要知道服务实例的访问信息，如IP，端口，地址等，如果都是人工去为每个服务实例配置访问信息，效率，可靠性，稳定性都是不能保证的，特别是在基于云的微服务体系中，服务实例被动态地分配访问信息，并且这些信息也可能会随着资源的调整有变化。

所以需要一套完整的服务发现机制来帮助我们去实现服务的注册，发现，自动化，实现不使用硬编码的方式，只需要服务名就可以使用服务。并且可以动态的实现服务的注册，销毁以及查找

服务发现具备哪些关键特性:
高可用：服务发现是SOA or 微服务体系中的核心功能，服务发现不可用意味着 应用的不可用，这是无法接受的。
提供服务的注册，销毁，保证服务的有效性以及可用性。
提供服务查找，服务实例是为客户端or调用者提供服务的，必须能让客户端通过通过一定对着查找到其需要访问的服务。

服务发现经典机制
传统LB模式，进程内LB模式，独立主机LB模式

传统LB模式

1服务上线，为其配置域名
2运维将服务信息配置到LB中
3访问者访问LB，LB调用服务并返回结果给消费者

优点：
实现方式简单
业界普遍在使用
缺点：
运维难度大，新增or撤销服务时，需要运维接入更改LB配置信息
存在单点故障：一台F5 或者nginx作为核心，若挂了则整体都不能正常工作
需要硬件配合，成本高，若使用F5作为LB，就需要外购硬件

进程内LB模式：

1 服务实例自动注册到服务注册中心
2 定期发送心跳，反应服务可用
3 服务消费者客户端带有服务发现和负载功能
4 LB定期同步服务注册表中服务
5 服务消费者通过LB调用服务实例

优点：
高可用性：每个客户端一个LB，不存在单点故障问题
服务发现无需运维接入：通过代码的形式实现服务的注册，发现，不需要运维额外配置信息
高性能：客户端直接通过LB获取服务实例访问地址信息，进而直接调用服务实例提供的服务接口，无中间过程损耗性能。

缺点：
多语言支持成本高：客户端代码与LB强耦合，需要为每种接入语言实现客户端代码与LB代码
升级成本高：客户端代码与LB强耦合，升级任何一个都必须要两者同时考虑。

独立主机LB模式

1 前面两种方式的折中
2 每个主机上部署一个LB
3 服务实例自动注册到服务注册中心
4 定期发送心跳，反应服务可用
5 LB定期同步服务注册表中服务信息
6 消费端调用本机LB，LB实现负载均衡和远程调用

优点：
可支持多种语言
无单点故障
性能高

缺点：
运维成本高：每个客户端都需要安装独立LB，客户端与LB状态两者都要兼顾，且客户端与LB是一对一的。

性能方案对比;

选型：
以实际状态出发，考虑集成的难度如何，上手难易程度，若某一个选型的缺点无法忍受，则一票否决也可以，技术的热度，社区的活跃度，资料的丰富层次也是一个维度，毕竟要考虑生产效率与学习成本，能使用开源项目尽量使用开源项目