第2章Spring Cloud Eureka上篇

Netflix Eureka（后文简称Eureka）是由Netflix开源的一款基于REST的服务发现组件，包括Eureka Server及Eureka Client。从2012年9月在GitHub上发布1.1.2版本以来，至今已经发布了231次，最新版本为2018年8月份发布的1.9.4版本。期间有进行2.x版本的开发，不过由于各种原因内部已经冻结开发，目前还是以1.x版本为主。Spring Cloud Netflix Eureka是Pivotal公司为了将Netflix Eureka整合于Spring Cloud生态系统提供的版本。

本章以Spring Cloud Finchley版本展开，对应Eureka的1.9.2版本，将系统全面地介绍服务发现的由来、Eureka的核心概念及其设计理念以及在实际企业级开发中的应用技巧。

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的路由。

由此可见，随着服务架构模式以及底层运维方式的变化，服务注册中心逐步在分布式系统架构中占据了一个重要的地位。