来自：阿里巴巴中间件

本文是《微服务治理实践》系列篇的第二篇文章，为大家介绍如何实现服务查询。该系列文章基于阿里云商业化产品 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 服务治理等等，未来会有更多增强特性，欢迎关注。

作者信息：徐靖峰，花名岛风，中间件技术-微服务产品团队高级研发工程师，负责 Dubbo / Spring Cloud 商业化产品开发相关工作，目前主要关注云原生、微服务等技术方向。

特别推荐一个分享架构+算法的优质内容，还没关注的小伙伴，可以长按关注一下：

长按订阅更多精彩▼如有收获，点个在看，诚挚感谢