2.1 服务发现概述
2.1.1 服务发现由来
服务发现及注册中心或是名字服务（后文统一简称服务发现），不是凭空出现的，其演进与软件开发的架构方式的演进有密切关联，大致如下：
1．单体架构时代
早期的互联网开发，多使用单体架构，服务自成一体，对于依赖的少数外部服务，会采用配置域名的方式访问，比如要使用外部短信供应商的短信发送接口，会使用appId和appKey，调用该供应商的域名接口即可。
2. SOA架构时代
随着SOA架构的流行，公司的内部服务开始从单体架构拆分为粒度较粗的服务化架构，这个时候，依赖的内部服务会比较多，那么内部的服务之间如何相互调用呢？以基于HTTP形式暴露服务为例，假设A服务部署在3台虚拟机上，这3个服务实例均有各自的独立内网ip，此时假设B服务要调用A服务的接口服务，有几种方式。
方式一：A服务把这3个服务实例的内网ip给到消费者B服务，这个时候B服务在没有Client端负载均衡技术的条件下，通常会在B服务自己的Nginx上配置A服务的upstream，即将A服务的3个服务实例配置进去，比如：
upstream servicea_api_servers {
server 192.168.99.100:80 weight=3 max_fails=3 fail_timeout=20s;
server 192.168.99.101:80 weight=1 max_fails=3 fail_timeout=20s;
server 192.168.99.102:80 weight=4 max_fails=3 fail_timeout=20s;
}
##......
server {
listen 80 default_server;
server_name serviceb.com.cn;
location /api/servicea/ {
proxy_pass http://servicea_api_servers/api/ ;
}
}
通过B服务自己的Nginx来维护A服务的具体实例ip，这种方式缺点比较明显，那就是B服务耦合了A服务的实现细节，当A服务实例扩充或者ip地址变化的时候，其下游的消费者都需要去修改这些ip，非常费劲。
方式二：为了解耦合，采用服务提供方A服务自己维护ip实例的方式，暴露统一的内网域名给消费者去消费，这样B服务只需要配置一个内网域名即可，比如：
server {
listen 80 default_server;
server_name serviceb.com.cn;
location /api/servicea/ {
proxy_pass http://servicea.com.cn/api/ ;
}
}
而A服务自己的Nginx则自己维护ip实例，比如：
upstream servicea_api_servers {
server 192.168.99.100:80 weight=3 max_fails=3 fail_timeout=20s;
server 192.168.99.101:80 weight=1 max_fails=3 fail_timeout=20s;
server 192.168.99.102:80 weight=4 max_fails=3 fail_timeout=20s;
}
##......
server {
listen 80 default_server;
server_name servicea.com.cn;
location /api/ {
proxy_pass http://servicea_api_servers/api/ ;
}
}
这样即实现了服务提供方与消费者之间的解耦，若A服务要变更实例ip地址，自己更改自身的Nginx配置即可。
3．微服务时代
在微服务时代，底层运维方式发生了巨大的变化，随着Docker的流行，业务服务不再部署在固定的虚拟机上，其ip地址也不再固定，这个时候前面的解决方案就显得捉襟见肘了。针对合格问题，不同的思考方式提出了不同的解决方案，这里列举几个。
方案一：以Nginx为例，在没有引入服务注册中心的时候，那就是手工或是通过脚本的方式，在部署的时候去更新Nginx的配置文件，然后reload。抑或是使用ngx_http_dyups_module通过rest api来在运行时直接更新upstream而不需要reload。
方案二：将服务注册中心作为一个标配的分布式服务组件，网关等都从服务注册中心获取相关服务的实例信息，实现动态路由。比如consul-template+Nginx的方案，通过consul监听服务实例变化，然后更新Nginx的配置文件，通过reload实现服务列表更新。又拍云的slardar也是这个思路，不过不是通过reload的方式来，而是通过在运行时通过consul获取服务列表来实现动态upstream的路由。
由此可见，随着服务架构模式以及底层运维方式的变化，服务注册中心逐步在分布式系统架构中占据了一个重要的地位。
2.1.2 Eureka简介
Eureka是Netflix公司开源的一款服务发现组件，该组件提供的服务发现可以为负载均衡、failover等提供支持，如图2-1所示。Eureka包括Eureka Server及Eureka Client。Eureka Server提供REST服务，而Eureka Client则是使用Java编写的客户端，用于简化与Eureka Server的交互。
图2-1 Eureka简图
Eureka最初是针对AWS不提供中间服务层的负载均衡的限制而设计开发的。AWS Elastic Load Balancer用来对客户端或终端设备请求进行负载均衡，而Eureka则用来对中间层的服务做服务发现，配合其他组件提供负载均衡的能力。
Netflix为什么要设计Eureka，而不是直接利用AWS Elastic Load Balancer或者AWS Route 53呢？其官方文档说明简要如下：
理论上可以使用AWS Elastic Load Balancer对内部进行负载均衡，但是这样就会暴露到外网，存在安全性问题，另外AWS Elastic Load Balancer是传统的基于代理的负载均衡解决方案，无法直接基于服务元数据信息定制负载均衡算法。因此Netflix设计了Eureka，一方面给内部服务做服务发现，另一方面可以结合ribbon组件提供各种个性化的负载均衡算法。
而AWS Route 53是一款命名服务，可以给中间层的服务提供服务发现功能，但它是基于DNS的服务，传统的基于DNS的负载均衡技术存在缓存更新延时问题，另外主要是无法对服务健康状态进行检查，因此Netflix就自己设计了Eureka。
2.1.3 服务发现技术选型
Jason Wilder在2014年2月的时候写了一篇博客《Open-Source Service Discovery》（http://jasonwilder.com/blog/2014/02/04/service-discovery-in-the-cloud/），总结了当时市面上的几类服务发现组件，这里补充上consul以及一致性算法，如表2-1所示。
表2-1 服务发现组件对比
从列表看，有很多服务发现组件可以选择，针对AP及CP，本书主要选取了Eureka及Consul为代表来阐述。关于Eureka及Consul的区别，Consul的官方文档有一个很好的阐述（http://www.consul.io/intro/vs/eureka.html），具体如下：
Eureka Server端采用的是P2P的复制模式，但是它不保证复制操作一定能成功，因此它提供的是一个最终一致性的服务实例视图；Client端在Server端的注册信息有一个带期限的租约，一旦Server端在指定期间没有收到Client端发送的心跳，则Server端会认为Client端注册的服务是不健康的，定时任务会将其从注册表中删除。Consul与Eureka不同，Consul采用Raft算法，可以提供强一致性的保证，Consul的agent相当于Netflix Ribbon + Netflix Eureka Client，而且对应用来说相对透明，同时相对于Eureka这种集中式的心跳检测机制，Consul的agent可以参与到基于gossip协议的健康检查，分散了Server端的心跳检测压力。除此之外，Consul为多数据中心提供了开箱即用的原生支持等。
那么基于什么考虑因素可以选择Eureka呢，主要有如下几点：
❑ 选择AP而不是CP，这一点在后面的章节会阐述。
❑ 如果团队是Java语言体系的，则偏好Java语言开发的，技术体系上比较统一，出问题也好排查修复，对组件的掌控力较强，方便扩展维护。
❑ 当然除此之外，更主要的是Eureka是Netflix开源套件的一部分，跟zuul, ribbon等整合的比较好。