专栏首页EAWorld微服务架构实践:服务注册与发现中负载方案选型

微服务架构实践:服务注册与发现中负载方案选型

微服务架构不是银弹,在微服务架构中,我们将面临很多新的问题,这时候势必会引入一个服务注册发现问题。本文作者向大家介绍了随着负载均衡位置的不同,三种主要的服务注册与发现和负载均衡方案。

1.微服务架构下服务注册与发现机制

随着微服务架构深入人心,越来越多的企业将微服务架构付诸实践。相比于传统的单体应用架构,微服务架构有着得天独厚的优势;在传统的单体应用架构下,因为功能集中,代码中心化,一个发布包部署发布在一个进程的应用程序中,单体应用架构已经无法满足企业业务快速变化的需求。一方面,代码维护困难,扩展性较差,灵活性较低,另一方面,系统的修改成本,维护成本在增加以及构建时间,发布周期很长。而微服务架构,因为服务之间独立部署,每个服务在开发,测试,部署的时候,无论是开发周期还是难易程度,都比单块应用要好。

然而,微服务架构不是银弹, 在微服务架构中,会面临很多新的问题,微服务架构由一组小的服务组成,服务之间采用轻量级的通讯机制进行沟通,微服务之间调用关系是一个网状结构,一个微服务在调用另一个微服务的时候,无法知道另一个微服务的具体地址;由于每个服务属于"微"服务,每个服务生命周期不长,每个服务可能随时被关闭、重启、替换;在随着访问量增加的时候,微服务需要扩容,访问量减少时,微服务需要缩容;这样就导致每个微服务的地址在动态变化,这时候必然引入一个服务注册发现问题,也就是说客户端在调用的时候,需要知道服务端的地址,服务端在提供服务的时候,需要注册通告自己的地址,供客户端调用;同时服务端一般存在多个实例来提供服务,这就要求需要引入负载均衡的能力,随着负载均衡位置的不同,主要的服务注册与发现和负载均衡方案有三种

2.常见的服务注册与发现的方案

1.集中式负载均衡方案

集中式负载均衡也叫服务端负载均衡,如图1所示,负载均衡器在一台单独的主机上,可以采用软负载,如nginx,apache等,也可以采用硬负载,如F5等,它负责多实例服务的负载均衡,客户端直接通过域名访问负载均衡器,DNS服务器将域名解析到负载均衡器IP上:

(图1 集中式负载)

该方案实现较为简单,仍是业界的主流,可以充分利用负载均衡器的能力,根据不同的负载策略将请求分发到后面的服务实例上;同时,该方案缺点也很明显,负载均衡器存在单点问题,所有的流量都需要通过负载均衡器,如果负载均衡器存在问题,则直接导致服务不能正常提供服务;中间经过负载均衡器做代理,性能也有一定损耗。

2.客户端负载均衡方案

客户端负载针对服务端负载的缺点,做了一定的改进,如图2所示,负载能力由客户端进程提供,服务端实例注册自己的地址到注册中心,客户端从注册中心订阅服务提供者的地址,获取地址后,根据负载均衡实现策略进行服务路由:

(图2 客户端负载)

该方案在解决了服务端负载的单点问题,每个客户端都实现了自己的负载功能,负载能力和客户端进程在一起,和客户端的生命周期一致,如果负载均衡进程down了,则客户端也down了,而且只影响本身客户端,不会影响其他客户端;同时,该方案也有一定的缺点,负载要求每个客户端自己实现,如果不同的技术栈,每个客户端则需要使用不同的语言实现自己的负载能力,技术难度较大;业界的motan,dubbo采用此方案做服务注册与发现。

3.客户端主机独立负载均衡方案

第三种方案综合了前2个方案的优缺点,如图3所示,服务发现和负载的能力从客户端进程移出,客户端进程和负载均衡进程是2个独立的进程,在同一个主机上;服务实例还是在启动的时候注册自己的地址到注册中心,客户端直接发送请求给本机的负载均衡器。

(图3 客户端独立主机负载)

该方案是一个典型的分布式方案,没有单点问题,如果一个主机的负载均衡器出问题,只影响一个节点调用,不影响其他的节点,负载均衡器本身负载也较小,性能损耗较低;同时也不需要多种语言实现自己的负载能力,负载能力是公用的;但是该方案部署复杂,维护困难,出了异常之后,调试负载,定位问题都比较麻烦。

3.新一代的选择

前面说了那么多,对于服务注册与发现,在普元新一代数字化企业云平台中,我们是怎么实践的?在数字化企业云平台中,我们选择了DevOps这条路来实现我们理想的运营,同时以微服务架构为核心。DevOps的逻辑架构(新一代更多内容,请移步本公众号菜单:纯干货—数字化转型)如图4所示:

(图4 DevOps 逻辑视图)

服务注册与发现在DevOps的技术平台中,作为基础框架给上层DevOps后台服

务使用。

DevOps的运行视图如图5所示:

(图5 DevOps运行视图)

从图中可以看出,微服务之间存在错综复杂的调用关系,SRD主要解决各个微服务之间服务注册与发现的问题。在数字化企业云平台中,我们综合考虑了服务注册与发现几个方案的优缺点,同时结合我们平台的一些特点及技术栈,我们考虑了以下问题:

  1. 如何选择负载方案,我们选择了和方案三类似的负载方案;因为方案三弥补了前面两种方案的优缺点,带来的问题是部署复杂,但是我们采用K8S管理微服务的部署,负载本身的复杂由K8S自己解决了,不需要我们花很多成本解决部署难题。
  2. 在选择客户端主机独立负载的情况下,无法在服务提供者启动时获取到Cluster IP,我们的解决办法是通过域名访问,域名默认和当前应用名保持一致。

下面是我们服务注册与发现的架构图

(图6 新一代服务注册与发现架构图)

服务提供者在启动时,将当前应用的域名注册到服务注册表,客户端通过服务注册表拿到服务提供者的服务域名,客户端通过dns解析到Cluster IP,然后发起调用。

关于作者:

杨勇

现任普元SOA产品部高级软件工程师,曾带领团队完成BPFF,BPS Platform 7.2等研发项目。互联网技术高手,分布式,云计算,机器学习技术爱好者。

本文分享自微信公众号 - EAWorld(eaworld),作者:杨勇

原文出处及转载信息见文内详细说明,如有侵权,请联系 yunjia_community@tencent.com 删除。

原始发表时间:2016-07-04

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

我来说两句

0 条评论
登录 后参与评论

相关文章

  • 微服务模式系列之四:客户端服务实现

    译者自序: 熟悉我的朋友都知道,我很不喜欢翻译东西,因为在两种语言的思维方式之间做频繁切换对我来说是件很痛苦的事情。但是这次不一样,公司和同事的大力支持降低了我...

    yuanyi928
  • 微服务,我们如何与你相处

    本文为《架构探险-轻量级微服务架构》(黄勇 著)序 微服务来了,有了“服务”这两个字,这注定又是个一说就明白、一举例就糊涂、一讨论就吵架的概念。...

    yuanyi928
  • 微服务设计指南

    微服务是当今软件工程师的一个热门话题。让我们了解如何使用微服务架构风格构建真正模块化、业务敏捷的IT系统。

    yuanyi928
  • 物联网正在成为下一个云战场

      当云计算供应商之间的竞争日益加剧的同时,它们对物联网的兴趣也与日俱增。越来越多的连网设备如雨后春笋一般出现在市场上,令这片市场的竞争变得越来越强烈...

    腾讯研究院
  • WakeData惟客数据入选2019年中国B2B百强企业榜单 | 腾讯SaaS加速器·学员动态

    ? 来源 | 腾讯SaaS加速器首期项目-WakeData ---- 随着信息技术与实体经济深度融合发展,互联网发展模式从toC的消费互联网转向到toB的产业...

    腾讯SaaS加速器
  • FAQ | Rabbit'DNS常见问题解答

    请注意,本文编写于 272 天前,最后修改于 70 天前,其中某些信息可能已经过时。

    兔子吖
  • Linux内核管理风格

    Original: Documentation/process/management-style.rst Translator: Alex Shi alex.s...

    Linux阅码场
  • 北京神舟航天软件技术有限公司专场 — 纯前端表格技术应用研讨会

    2018 年 7 月 18 日,“赋能开发者,走进你身边——纯前端表格技术应用研讨会” 在北京神舟航天软件技术有限公司(以下简称:神软)盛大召开。数十位航天领域...

    葡萄城控件
  • C语言在嵌入式系统编程时的注意事项

    C语言是一门通用计算机编程语言,应用广泛。C语言的设计目标是提供一种能以简易的方式编译、处理低级存储器、产生少量的机器码以及不需要任何运行环境支持便能运行的编程...

    企鹅号小编
  • spring cloud系列教程第六篇-Eureka集群版

    本文是由凯哥(凯哥Java:kagejava)发布的《spring cloud系列教程》教程的总第六篇:《spring cloud系列教程第六篇-Eureka集...

    凯哥Java

扫码关注云+社区

领取腾讯云代金券