微服务架构之「 服务注册 」

微服务架构是一个庞大复杂的工程,为什么说它庞大复杂呢?因为想要做好微服务,就必须先要建设好微服务所需的一系列基础设施和组件。我在前面的文章《架构设计之「 微服务入门 」》中已经初步介绍过了这些组件,包括:服务注册、服务网关、配置中心、服务框架、服务监控、服务追踪、服务治理等。

只有将这些基础设施搭建完善了,微服务实践的道路才能走的稳、走的远。后面的文章中会依次把每一个基础组件都详细分析一下。今天我们就先挑选「 服务注册 」聊一聊。

一、为什么需要「 服务注册 」?

我们先来举一个生活中的例子:在以前互联网还不够发达的时候,“114号码百事通”大家应该很熟悉,有啥需求就会去打个电话查询一下。比如想知道附近电影院电话是多少,就会先去打114问一下。那114为啥知道这么多信息呢,还不是因为各类服务者(商店、机构等)都已经在114上登记了嘛。所以这里的“114百事通”就相当于一个服务注册中心了,这里的各类商店机构就相当于可以提供不同服务的服务者了,而打电话的我们就是去寻找这些服务的消费者了。

我们再来回到微服务架构中,一般集群都会部署很多个微服务节点。这些节点一般也具备这2种角色,称为:“服务的提供者” 和 “服务的消费者”。

“服务消费者”需要调用“服务提供者”的API来获得服务。当“服务提供者”的节点有增加或减少的时候,也得让调用者(“服务消费者”)及时的知晓。而在大规模集群中,一般节点数目都很多,节点变化频繁,通过手动去维护这些节点的状态是不现实的,因此需要一个叫做“服务注册中心”的组件来实现。

“服务提供者”将自己的服务地址等信息登记到“服务注册中心”中,调用者(“服务消费者”)需要的时候,每次都先去“服务注册中心”查询即可。既解决了人工维护微服务节点状态的问题,也能解决多节点间负载均衡的问题。

二、「 服务注册 」的实现原理是什么?

在分析其原理之前,我们先来看一下这里包含的一些角色,有三类:“服务提供者”、“服务消费者”、“服务注册中心”。

其中“服务提供者”需要将自己的服务信息注册到“服务注册中心”里面。而“服务消费者”需要到“服务注册中心”里面去查询有哪些服务可以调用。因此,我们可以分为两个视角去分析原理:

  • 从“服务提供者”的视角, “服务提供者”向“服务注册中心”进行注册:登记注册具体的也有为两种方式,一种是 自己注册,另一种是 第三方注册
  1. 自己注册:如图,自己注册就是指微服务节点在启动的时候,自己去服务注册中心登记注册了,把自己的信息和状态传过去。这种方式整体结构比较简单,对于注册中心而言也比较省事,但是对于微服务节点而言,每个微服务都得包含这么一段注册的逻辑代码,架构上看起来不是很优美。再拿114百事通的例子解释一遍,自己注册就表示这是商家开店之后自己跑去告诉114电话台,说自己商店开业了,目前在经营着哪些服务,请求114登记下来。
  2. 第三方注册:如图,第三方注册就是指有一个“服务管理器”(图中的Service Manager),这个“服务管理器”会去管理所有的微服务和进程,以轮询或其它方式去检查有哪些微服务实例正在运行,会将这些微服务实例自动更新到服务注册中心。这是目前比较常用的方式,例如Eureka就是采用这个模式。如果再拿114百事通的例子来讲,就相当于114中心安排了一个管理员,这个管理员会定期的到街上去看一看有哪些新开的商店就把它登记下来,有哪些关闭了的商店就从注册中心删除掉。
  • 从“服务消费者”的视角,“服务消费者”向“服务注册中心”查询和调用服务:对于服务的查询和调用,也分为两种模式:客户端模式 和 代理模式
  1. 客户端模式在客户端模式下,“服务消费者”(图中的Client)在向“服务注册中心”查询到自己需要调用的“服务提供者”的地址之后,“服务消费者”(客户端)就会自己根据地址去访问微服务(图中的第3步 API Gateway是可选项,有API Gateway的情况下,API Gateway起到负载均衡作用,没有第3步的话,那就是Client直接调用Microservice,需要Client自己写负载均衡逻辑)。客户端模式在实现上比较简单。
  2. 代理模式在代理模式下,“服务消费者”(图中的Client)与 微服务、“服务注册中心”中间有一个 API Gateway组件相隔着。“服务消费者”只管去找API Gateway访问即可。至于去注册中心查询服务地址,以及访问服务地址的动作都由API Gateway效劳了,最后API Gateway在把结果返回给“服务消费者”即可。这种模式,看起来“服务消费者”省事了,但是API Gateway模块却复杂了,因为API Gateway就是整个系统的一个非常核心关键节点了,不仅需要保障自己的稳定性和性能,而且还需要处理一些负载均衡的逻辑。在大型架构中,这种模式用的还比较多。

三、「 服务注册 」如何实践?

讲完了服务注册中心的必要性和原理,我们再来看一下在实际应用中应该如何去应用。虽然我们可以根据原理自己去开发一套服务注册中心,但是如果没有特殊需求,还是不建议重复造轮子了,市面上有很多成熟的方案可以直接使用。

  • EurekaEureka是由Netflix开源,其架构如下图:从图中可以看到,我们的服务(图中Application Clinet与Application Service)要使用Eureka就需要集成它的SDK(图中Eureka Client)。图中的Eureka部署在了三个异地机房,也就是说Eureka是支持多中心部署的。服务提供者(Application Service)通过Eureka Client实现服务的注册、更新和注销等。服务消费者(Application Clinet)通过Eureka Client实现服务的查询和调用。Eureka支持了与Spring Cloud的集成,所以使用起来也非常方便,目前属于比较流行的方案。
  • ConsulConsul是另外一个非常流行的开源组件,如下图:Consul是在服务外进行完成一系列动作的,也就是说并不需要服务节点去依赖它的SDK,没有侵入性,所以跨语言的解决能力更强一些。它一般是在服务节点外通过一些探针的方法去检查应用是否存活,是否需要注册或注销。Consul也支持Spring Cloud集成,所以使用起来也很方便,也属于比较流行的方案。
  • Etcd、Zookeeper这两个也有一些公司基于它们来实现服务注册,也集成了Spring Cloud,不过不算非常广泛。

以上,就是对微服务架构中「 服务注册 」的一些思考。

Image placeholder
武子
未设置
  21人点赞

没有讨论,发表一下自己的看法吧

推荐文章
SOA架构和微服务架构的区别是什么?

来源:rrd.me/fqdANSOA架构和微服务架构的区别首先SOA和微服务架构一个层面的东西,而对于ESB和微服务网关是一个层面的东西,一个谈到是架构风格和方法,一个谈的是实现工具或组件。1.SOA

微服务架构中如何构建一个数据报告服务?

场景描述在微服务架构中,每个微服务负责自己的数据库,微服务A是不允许直接连接微服务B的数据库进行操作的。现在有2个微服务,一个是订单服务,一个是用户服务。有一个数据报告的需求:生成一份包含用户信息的订

微服务架构:拆分单体应用的难点

拆分单体应用为服务的难点从表面上看,通过定义与业务能力或子域相对应的服务来创建微服务架构的策略看起来很简单。但是,你可能会遇到几个障碍:网络延迟。同步进程间通信导致可用性降低。 在服务之间维持数据一致

微服务架构的四大金刚利器

Photo@ChristopherCampbell 文 | 孔凡勇概述互联网应用发展到今天,从单体应用架构到SOA以及今天的微服务,随着微服务化的不断升级进化,服务和服务之间的稳定性变得越来越重要,分

一个知名网站的微服务架构最佳实现

译者:蓝梦,十余年研发经验,现就职于某上市互联网公司。作者:小马,Medium 首席架构师。译者有话说,如果你的项目正在从单体升级为微服务而忧心;或者你在实践微服务过程中手忙脚乱,本文都是你不容错过的

金融行业微服务架构解析

转载本文需注明出处:微信公众号EAWorld,违者必究。引言:对于微服务,每个人都有自己的理解,与互联网企业的大量落地相比,微服务在传统金融行业还没有普及,这首先是传统金融行业线上系统需求更新和版本迭

微服务架构的四大杀手锏

Photo@ChristopherCampbell 文 | 孔凡勇概述互联网应用发展到今天,从单体应用架构到SOA以及今天的微服务,随着微服务化的不断升级进化,服务和服务之间的稳定性变得越来越重要,分

Nacos 服务注册与发现原理分析

Nacos另一个非常重要的特性就是服务注册与发现,说到服务的注册与发现相信大家应该都不陌生,在微服务盛行的今天,服务是非常重要的,而在Nacos中服务更被称为他的一等公民。Nacos支持几乎所有主流类

巨杉TechDay回顾 | 与携程、巨杉、知乎大牛一起探寻DT时代数据库架构之道

数据,已成众多企业的核心资产。如今企业越来越懂得数据的重要性,也愈发清楚数据将为公司带来的巨大价值。在物联网、AI等技术的普及下,数据井喷仍在持续进行,如何更好地管理和使用这些“无穷无尽”的数据,则成

基础架构之百变魔方

转载本文需注明出处:微信公众号EAWorld,违者必究。引言:“基础架构即代码(Infrastructure-as-Code,IaC)”是一种使用新的技术来构建和管理动态基础设施的方式。它把基础设施、

事务注解(@Transactional)引起的数据覆盖故障

最近组织团队内技术培训,刘聪为分享的一个跟事务和写数据库相关的case(bug)很有代表性。用事务,要小心!一、故障现象车辆交付履约流程上两个节点(工程项目)A和B,A修改一条数据记录item(工单)

大神讲解微服务治理的技术演进和架构实践

摘要:随着业务的发展,规模扩大,服务越来越多,需要协调线上运行的各个服务,保障服务的SLA;基于服务调用的性能KPI数据进行容量管理,合理分配各服务的资源占用;对故障业务做服务降级、流量控制、流量迁移

清晰架构(Clean Architecture)的Go微服务: 日志管理

良好的日志记录可以提供丰富的日志数据,便于在调试时发现问题,从而大大提高编码效率。记录器提供的自动化信息越多越好,日志信息也需要以简洁的方式呈现,便于找到重要的数据。日志需求: 无需修改业务代码即可切

万字详解Oracle架构、原理、进程,学会世间再无复杂架构

学习是一个循序渐进的过程,从面到点、从宏观到微观,逐步渗透,各个击破,对于Oracle, 怎么样从宏观上来理解呢?先来看一个图,这个图取自于教材,这个图对于从整体上理解ORACLE 的体系结构组件,非

架构转型先行——金融业务场景下的新一代架构实践

  赵勇中国农业银行研发中心架构管理办公室主任工程师中国农业银行研发中心架构管理办公室主任工程师,十年以上金融行业信息化架构设计与管控经验。历经互联网金融、两地三中心、分布式核心银行等大型银行系统工程

数字转型 架构演进 2019中国系统架构师大会盛大召开

2019年10月31日~11月2日,由IT168旗下ChinaUnix社区主办的第十一届中国系统架构师大会(SACC2019)在北京隆重召开。自2009年举办以来,大会云集了国内CTO、研发总监、高级

阿里支付宝架构师:谈谈我眼中的高并发架构【好文】

来源:my.oschina.net/u/3772106/blog/1793561前言高并发经常会发生在有大活跃用户量,用户高聚集的业务场景中,如:秒杀活动,定时领取红包等。为了让业务可以流畅的运行并且

架构师眼中的高并发架构

前言高并发经常发生在有大活跃用户量和用户高聚集的业务场景中,如:秒杀活动、定时领取红包等。为了让业务可以流畅的运行并且给用户一个好的交互体验,我们需要根据业务场景预估达到的并发量等因素,来设计适合自己

一站式入口服务|爱奇艺微服务平台 API 网关实战

写在前面在互联网业务微服务化改造过程中,按照以往的服务治理体系,各服务需要单独实现限流、鉴权、监控、日志等通用功能,构建入口时资源申请、工单批复、多系统配置等一系列流程对精力消耗极大,学习成本较高

前端微服务在字节跳动的落地之路

不少前端团队都面临着独石应用的工程巨大、理解困难和合作混乱的种种问题,微前端或许是一种比较好的解决方案,它允许我们为应用加入新功能而不影响整体结构。但同时,我们可能会付出一些代价,例如重复依赖、团

🚀 Hyperf 发布 v1.1.8 版本 | 企业级的 PHP 微服务云原生协程框架

更新内容 新增 #965新增RedisLua模块,用于管理Lua脚本; #1023hyperf/metric组件的Prometheus驱动新增CUSTOM_MODE模式; 修复 #1013修复Js

🚀 Hyperf 发布 v1.1.9 版本 | 企业级的 PHP 微服务云原生协程框架

更新内容 本周更新主要为DI组件新增了懒加载功能,配置为懒加载后,注入的对象为一个代理对象,在使用到时,才会实现对象的初始化。以及为DIContainer增加了set和define方法来动态的增加对象

🚀 Hyperf 发布 v1.1.9 版本 | 企业级的 PHP 微服务云原生协程框架

更新内容本周更新主要为DI组件新增了懒加载功能,配置为懒加载后,注入的对象为一个代理对象,在使用到时,才会实现对象的初始化。以及为DIContainer增加了set和define方法来动态的增加对象管

《PHP 微服务练兵》系列教程

本系列教程将从零开始使用PHP搭建微服务,涉及知识docker、mysql、Elasticsearch+Kibana日志分析系统、minio文件储存、阿里ACM配置中心、jenkens自动化测试部署、

从五个方面入手,保障微服务应用安全

随着计算机、互联网技术的飞速发展,信息安全已然是一个全民关心的问题,也是各大企业非常重视的问题。企业一般会从多个层次着手保障信息安全,如:物理安全、网络安全、系统安全(主机和操作系统)、应用安全等。对