微服务治理实践：服务查询
本文是《微服务治理实践》系列篇的第二篇文章，为大家介绍如何实现服务查询。该系列文章基于阿里云商业化产品 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
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 商业化团队也在招人，除了 EDAS，我们还有 ARMS (应用实时监控服务)、MSE（微服务引擎）、ACM（应用配置管理）、SAE（Serverless 应用引擎）等独立产品。我们在忙什么？用心打磨这些产品，就是我们的工作。团队的目标是将阿里巴巴在服务治理上的最佳实践通过产品化的形式输出给阿里云上的企业客户，帮助客户实现业务永远在线。
简历投递方式：[email protected]
Java干货
视频资料
技术交流群