SpringCloud之Eureka实战和架构设计解析.docx

? ? SpringCloud之Eureka实战和架构设计解析 ? ? SpringCloud之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的核心概念及其设计理念以及在实际企业级开发中的使用。 一、服务发现 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 00:80 weight=3 max_fails=3 fail_timeout=20s; server 01:80 weight=1 max_fails=3 fail_timeout=20s; server 02:80 weight=4 max_fails=3 fail_timeout=20s; } ## server { listen 80 default_server; server_name ; 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 ; location /api/servicea/ { proxy_pass /api/ ; } } 而A服务自己的Nginx则自己维护ip实例，比如： upstream servicea_api_servers { server 00:80 weight=3 max_fails=3 fail_timeout=20s; server 01:80 weight=1 max_fails=3 fail_timeout=20s; server 02:80 weight=4 max_fails=3 fail_timeout=20s; }