《重新定义Spring Cloud实战》——2.Spring Cloud Eureka上篇

举报
华章计算机 发表于 2019/06/04 13:16:28 2019/06/04
【摘要】 本书摘自《重新定义Spring Cloud实战》——书中第2章,第2.1.1节,作者是许进、叶志远、钟尊发、蔡波斯、方志朋、郭芳碧、朱德明。

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

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


【版权声明】本文为华为云社区用户转载文章,如果您发现本社区中有涉嫌抄袭的内容,欢迎发送邮件进行举报,并提供相关证据,一经查实,本社区将立刻删除涉嫌侵权内容,举报邮箱: cloudbbs@huaweicloud.com
  • 点赞
  • 收藏
  • 关注作者

评论(0

0/1000
抱歉,系统识别当前为高风险访问,暂不支持该操作

全部回复

上滑加载中

设置昵称

在此一键设置昵称,即可参与社区互动!

*长度不超过10个汉字或20个英文字符,设置后3个月内不可修改。

*长度不超过10个汉字或20个英文字符,设置后3个月内不可修改。

举报
请填写举报理由
0/200