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

我是研究僧i 提交于 2020-02-28 17:06:18

前言

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

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

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

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

服务查询开源实现

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

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

Dubbo Admin

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

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

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

Naocs 控制台

当选择 Nacos 作为注册中心时,可以使用配套的 [Nacos 控制台](http://console.nacos.io/nacos/index.html#/login
)。Nacos 官网提供了一个在线控制台,以让用户有一个直观的体验:

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

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 默认采用的是旧版服务查询,下一个版本中我们将会切换新旧的默认值。

 

 

查看更多:https://yqh.aliyun.com/detail/6478?utm_content=g_1000105582

上云就看云栖号:更多云资讯,上云案例,最佳实践,产品入门,访问:https://yqh.aliyun.com/

易学教程内所有资源均来自网络或用户发布的内容,如有违反法律规定的内容欢迎反馈
该文章没有解决你所遇到的问题?点击提问,说说你的问题,让更多的人一起探讨吧!