前言
自从微服务架构变得火热以后，越来越多服务治理相关的名词被大家所熟知，例如：服务注册发现、负载均衡、容错等等，其中有一项能力，可以说是服务治理平台的刚需，却又很少被大家提及，也是这篇文章即将介绍的内容 -- 服务查询。
什么是服务？其实并没有严格的定义，但按照使用不同框架的习惯，我们可以大概归纳如下：
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/
来源：oschina
链接：https://my.oschina.net/u/4209562/blog/3178281