专栏首页Kirito的技术分享微服务治理实践:服务查询

微服务治理实践:服务查询

本文是《微服务治理实践》系列篇的第二篇文章,为大家介绍如何实现服务查询。该系列文章基于阿里云商业化产品 EDAS 的微服务实践,如果你的团队具备较强的微服务治理能力,那么希望我们在微服务治理方面的实践和背后的思考,可以为你提供一些参考。

前言


自从微服务架构变得火热以后,越来越多服务治理相关的名词被大家所熟知,例如:服务注册发现、负载均衡、容错等等,其中有一项能力,可以说是服务治理平台的刚需,却又很少被大家提及,也是这篇文章即将介绍的内容 -- 服务查询。

什么是服务?其实并没有严格的定义,但按照使用不同框架的习惯,我们可以大概归纳如下:

1、Dubbo 一类的服务框架,接口即服务。一般以服务名、版本号、分组这样的三元组作为唯一标识

2、SpringCloud 一类的微服务,应用即服务。一般以应用名称作为唯一标识

Dubbo 和 SpringCloud 对于服务有不同的定义,主要原因在于二者的注册发现机制有所差别,Dubbo 以接口为粒度进行服务注册与发现;SpringCloud 以应用粒度进行服务注册于发现。

服务框架提供的自动注册与发现的机制,让开发者非常的省心,只需要关心对方的服务名即可,而不用关心服务的地址,但如果出现地址找不到,路由出错或者是想要查看服务注册信息、服务调用关系时,就有些犯难了,借助于服务查询,则可以对这些问题进行基本的定位。

服务查询开源实现

开源框架对服务查询的支持主要有 Apache Dubbo 提供的 Dubbo Admin、Nacos 提供的 Nacos 控制台 。首先介绍这两种开源实现,再介绍 EDAS 对服务查询的延伸。

服务查询主要包括:服务列表查询、服务详情查询、服务提供者列表、服务消费者列表、服务元数据等,下面主要展示服务列表查询。

Dubbo Admin

Dubbo Admin 支持 2.7 版本以上的 Dubbo 应用,提供了 Dubbo 基本的服务治理能力,其中就包括了服务查询。

Dubbo Admin:

https://github.com/apache/dubbo-admin

Dubbo Admin 默认支持 Zookeeper 注册中心,但理论上可以支持任意注册中心,只需要引入对应的注册中心扩展即可。由于 Zookeeper 并不支持模糊查询的需求,Dubbo Admin 采取了同步的策略,即在 Dubbo Admin 启动时将所有的注册信息同步在内存中,所以在服务查询时,实际是在对内存操作。

同步注册中心的服务信息并不困难,只需要依赖 dubbo-registry 模块中对应的注册中心扩展即可,本质上是把 dubbo-admin 当成了一个普通的 Dubbo 节点,而这个 Dubbo 节点并不提供服务也不消费服务,仅仅负责同步注册信息,服务变更信息也可以及时同步到 Dubbo Admin。

Naocs 控制台

当选择 Nacos 作为注册中心时,可以使用配套的 Nacos 控制台。Nacos 官网提供了一个在线控制台,以让用户有一个直观的体验:

http://console.nacos.io/nacos/index.html

Nacos :

https://nacos.io/zh-cn/docs/what-is-nacos.html

Nacos 控制台:

http://console.nacos.io/nacos/index.html#/login

Nacos 控制台的服务查询是对 Nacos Server 上存储数据的直接解析,在页面审查元素中,可以发现其调用了一些 OpenApi,但这部分 OpenApi 并没有在文档中开源出来。

开源实现总结

总的来说,服务查询的开源实现都能够解决一定程度的问题,但同时也有一些局限性:

  • Dubbo Admin 有版本的限制,只支持 Dubbo 2.7+
  • Dubbo Admin 同步了注册中心中全量的数据,资源消耗大,且由于内存限制,无法横向扩展,实现并不优雅
  • Nacos 控制台提供的服务信息是注册中心视角的服务,而不是微服务视角的服务,有理解 gap
  • Nacos 控制台缺少与微服务治理其他能力的联动,本质上还是注册中心的功能
  • 开源实现无法满足混合部署类型微服务的诉求,部分公司可能多种微服务框架并存

EDAS 服务查询实践


EDAS 支持 Dubbo、SpringCloud、HSF 三种微服务的部署,在设计微服务治理功能时,一般会考虑多个微服务框架是否兼容的问题。我们遇到了一些难点:

  • 微服务框架版本多 Dubbo 支持 2.5.x,2.6.x,2.7.x,SpringCloud 支持 D 以上的版本
  • 注册中心类型多 虽然 EDAS 提供了 EDAS 注册中心替用户托管了注册中心,但仍然有一部分用户习惯使用自建的注册中心:Zookeeper、Nacos、Eureka
  • 部署形态多 EDAS 支持 ECS Jar 包部署,同时支持 K8s 镜像部署,服务治理的实现不能受到部署形态的约束
  • 用户改造成本 尽可能降低用户的迁移成本,一般我们认为用户零感知是目标
  • 性能 & 可扩展 Dubbo Admin 拉取全量数据的模式自然不能被接受,最终方案需要具备可扩展性
  • 云上服务的限制 受到用户协议的限制,EDAS 不能在未经用户授权的情况下访问其注册中心,自建注册中心也应当能够享受服务治理

综上这些难点,我们最终采用了无侵入式的 Agent 方案来对托管微服务应用进行微服务治理。

无侵入方案通过 Agent 技术来实现,通过字节码增强技术,运行时对框架代码进行增强,例如服务创建、服务注销时进行拦截,上报给 EDAS。

基于 Agent 实现服务查询可以解决之前诸多痛点

  • Dubbo 和 SpringCloud 的多个版本在核心链路的改动很小,因此我们花费了少量的代价便覆盖到了所有版本。
  • Agent 实现与注册中心无关,即使注册中心宕机,也可以在 EDAS 控制台查询到服务
  • ECS Jar 应用启动时由 EDAS 增加 -javaagent: 启动参数感知到微服务 Agent,K8s 容器应用由 EDAS 增加微服务 pilot,不受部署形态约束
  • 用户无感知,没有迁移成本,仅仅只需要重启一次应用
  • 服务信息上报到 EDAS 后台,可以进行加工存储,不受制于注册中心的存储格式限制,可以任意扩展

下面我们在 EDAS 中部署一个 Dubbo 应用,来体验 EDAS 服务查询。

创建应用

第一步:选择 ECS 集群,Java 运行时环境。

第二步:可以在引导页面直接选择,使用官方提供的 Dubbo 服务端应用 Demo 进行部署。

第三步:填写版本号,确认创建应用。

服务查询控制台

服务列表页

服务详情页

服务查询实现细节


EDAS 通过微服务 Agent 拦截服务注册、服务下线信息及时上报给 EDAS,所以在正常情况下,服务查询的延时大概在 1 分钟以内。另外,还需要考虑服务宕机的场景,例如 kill -9 pid 并不会触发服务下线的逻辑,在注册中心场景下,服务与注册中心之间存在长连接,以心跳超时为标识摘除意外下线的实例;在 EDAS Agent 服务查询场景下同样存在心跳,意外下线的服务会在 3 分钟后被摘除。

Agent 上报的数据和用户注册中心的数据虽然同源,但处在不同链路上,需要对两者的概念做一些区分:

  • 注册中心存储的是服务调用过程中实际的服务信息
  • EDAS 存储的是服务意图上报的服务信息

基于上述的理解,服务控制台在大多数情况可以反馈出服务真实的情况,但在极少数场景下会存在数据一致性的问题,服务调用链路会以注册中心中的数据为准,EDAS 控制台不会影响服务调用。

FAQ

问题一 :Agent 拦截了我的服务,我的应用数据是不是也会泄漏? 答:Agent 仅仅拦截了服务的描述信息,不会对应用数据进行拦截,已经有很多成熟的产品在做类似的事:例如分布式链路跟踪、应用监控。

问题二:为什么服务下线了,仍然可以在 EDAS 控制台查询到服务? 答:下线脚本不优雅、应用宕机、K8s Pod 缩容(概率)都有可能导致控制台感知不到服务下线,可以在 3 分钟之后再观察。

问答三:为什么通过旧版服务查询可以查询到数据,而切换到新版服务查询没有数据? 答:只有在 2020-01-20 之后重启过的应用才能在新版服务查询中查到数据。重启过后的应用会自动挂载上最新的 Agent,新版 Agent 才支持新版服务查询。鉴于部分用户的应用没有重启过,目前 EDAS 默认采用的是旧版服务查询,下一个版本中我们将会切换新旧的默认值。

不仅仅是服务查询


本文介绍了两款开源产品 Dubbo Admin、Nacos 控制台服务查询的实现,对他们进行了对比,并引出了 EDAS 服务查询。服务查询本身并不是一个特别高大上的能力,但却是服务治理不可或缺的一个能力。服务查询还充当了一个服务治理入口的角色,只有搜出了服务,才能对他们进行后续的治理,可见其基础性。EDAS 针对很多微服务场景做了增强,例如分布式链路跟踪、金丝雀发布、离群摘除、Dubbo 服务治理等等,未来会有更多增强特性,欢迎关注。

本文分享自微信公众号 - Kirito的技术分享(cnkirito)

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

原始发表时间:2020-03-03

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

我来说两句

0 条评论
登录 后参与评论

相关文章

  • 浅谈服务治理与微服务

    Tanyboye
  • 微服务治理istio

    Service Mesh 的中文译为“服务网格”,是一个用于处理服务和服务之间通信的基础设施层,它负责为构建复杂的云原生应用传递可靠的网络请求,并为服务通信实现...

    yuezhimi
  • 微服务实践

    什么是微服务 微服务的两个核心: 微:服务粒度更细,即服务要细到API 服务:提供好服务,让服务好用 总结以上两点,来看这张图: ? 从图可以看出,微服务很简单...

    春哥大魔王
  • .NET Core微服务之基于Consul实现服务治理

      Consul是HashiCorp公司推出的开源工具,用于实现分布式系统的服务发现与配置。与其他分布式服务注册与发现的方案,比如 Airbnb的SmartSt...

    Edison Zhou
  • .NET Core微服务之基于Consul实现服务治理(续)

    上一篇发布之后,很多人点赞和评论,不胜惶恐,这一篇把上一篇没有弄到的东西补一下,也算是给各位前来询问的朋友的一些回复吧。

    Edison Zhou
  • 使用服务网格/Istio开发微服务3:服务治理

    ROUND_ROBIN,LEAST_CONN,RANDOM,PASSTHROUGH

    谢正伟
  • 微服务概览与治理

    基本上在产品的最开始阶段,为了快速构建产品,都是单体架构,尽快我们也会按照业务划分模块,但是这个样子始终最终部署的时候还是单体式应用。

    后场技术
  • 自动化微服务治理

    你可以把它想象为一个用于帮助更好开发微服务应用的工具。顺便一提,因为手头上并没有这样的场景。所以,我先把我的相关思路记载下来,方便于后续集成。而且大部分功能已经...

    Phodal
  • 使用 Istio 治理微服务

    使用云平台可以为组织提供丰富的好处。然而,不可否认的是,采用云可能会给 DevOps 团队带来压力。开发人员必须使用微服务以满足应用的可移植性,同时运营商管理了...

    搜云库技术团队

扫码关注云+社区

领取腾讯云代金券