微服务--服务发现理论
一、微服务--服务发现理论
前文中提到微服务独立部署、具有清晰的边界，服务之间通过远程调用来构建复杂的业务功能，比如：电商的下单业务，可能需要远程调用商品服务、订单服务、库存服务等多个服务来完成一个完整的下单逻辑。而服务远程调用的前期是：调用方（消费者）要知道被调用方（生产者）的地址、端口、健康状态等。这种服务之间为实现远程调用彼此相互知晓对方信息，便是服务发现。
服务之间是通过什么方式来实现彼此发现的呢？一般有两种模式：服务器端模式，客户端模式。
服务器端模式
服务器端模式通过使用一个中间的服务器，来屏蔽被调用服务的复杂性与变动性，当有新的服务加入或老服务剔除时，只需要修改中间服务器上的配置即可，此模式的显著特点是：引入独立的中间代理服务器来屏蔽真实服务的具体细节。
如下图所示：服务A是调用方（消费者），服务B是被调用方，微服B有三个负载，分别部署在三台IP为100、101、102的机器上。当服务A要调用服务B时，先通过DNS域名解析找到Nginx服务器，然后将请求发送给Nginx，因为在Nginx上配置了服务B的真实访问地址，Nginx收到请求后根据负载均衡算法，将请求转发到某个真实的服务B，服务B将请求结果返回给Nginx，Nginx再将返回结果给服务A，整个请求流程结束。
当然中间服务器不一定非得Nginx，还可以时基于硬件的F5，也可以工作在传输层的IP负载均衡等。
该模式的优点是：配置集中在独立的中间服务器端完成，对代码没有任何入侵，也不存在跨平台跨语言的问题。因为，所有请求都需要穿透中间服务器，缺点也很明显：中间服务器会成为一个单点，对性能也会有所影响。
客户端模式（进程内）
我们再看客户端模式（下图），应用场景还是一样，服务A要调用服务B，服务B有三个负载。服务A调用服务B时，不需要通过中间服务器，而是在自己进程内维护了服务B的信息，再通过负载算法选择一个服务B直接调用。那服务A具体是怎么维护服务B的信息呢？为此引入了服务注册中心的概念，当服务B启动时向注册中心注册自己（将自己的信息发送到注册中心的注册表里），服务A再从注册中心获取所有注册的服务，这就是客户端模式的基本原理。
客户端模式因为在进程内直接调用服务，也叫做进程内负载，由于不需要穿透中间服务器，所以客户端模式的性能损耗比较小。但是，需要在服务内部维护服务注册信息，负载算法等，有一定的代码入侵性，对于跨平台，跨语言的支持不太友好。
服务发现的两种模式各有优缺点，也适用于不同的场景，对于大型应用一般会有多层负载，外层用服务器端负载均衡，内部用客户端负载均衡。下面将重点介绍Netflix的Eureka服务发现组件，我们会从设计理念与原理，代码实现等多个维度进行解析。