在之前的文章中讲过,用户可以通过 URL 请求以及配置中心进行灰度发布的操作,而且支持配置中心的灰度发布参数的动态变更。如果用户不希望使用上面的两种方式,Nepxion Discovery 框架还支持图形化进行灰度化配置。通过 Swagger 支持使用 Web 界面进行配置修改,同时Nepxion Discovery 也提供了桌面程序来进行灰度配置。其实桌面程序也是基于 restful 来进行操作的。Nepxion Discovery 框架支持以下几种方式的灰度发布的规则策略推送。

  • 基于远程配置中心的规则策略订阅推送。详细配置地址传送门
  • 基于Swagger和Rest的规则策略推送。详细配置地址传送门
  • 基于图形化桌面端和Web端的规则策略推送。详细配置地址传送门

首先我们先来了解一下如果进行桌面程序来操作配置中心进行灰度发布的推送的。

1、基于图形化桌面端和Web端的规则策略推送

① 获取图形化桌面端

桌面端获取方式有两种方式

  • 通过https://github.com/Nepxion/DiscoveryUI/releases下载最新版本的discovery-desktop-release
  • 编译https://github.com/Nepxion/DiscoveryUI下的desktop,在target目录下产生discovery-desktop-release

② 启动控制台

  • 通过https://github.com/Nepxion/DiscoveryPlatform下载最新版本的控制台
  • 导入IDE或者编译成Spring Boot程序运行
  • 运行之前,先修改src/main/resources/bootstrap.properties的相关配置,包括注册中心和配置中心的地址等

③ 启动图形化桌面端

  • 修改config/console.properties中的url,指向控制台的地址
  • 在Windows操作系统下,运行startup.bat,在Mac或者Linux操作系统下,运行startup.sh

④ 登录图形化桌面端

  • 登录认证,用户名和密码为admin/admin或者nepxion/nepxion。控制台支持简单的认证,用户名和密码配置- 在上述控制台的bootstrap.properties中,使用者可以自己扩展AuthenticationResource并注入,实现更专业的认证功能


如何进行基于桌面程序的全链路蓝绿发布编排建模,官方网站已经说得很清楚了,这里我就不在赘述了。访问地址 – Discovery#全链路蓝绿发布编排建模 。

之前已经说了不管是基于Swagger和Rest的规则策略推送 还是 基于图形化桌面端和Web端的规则策略推送 他们都基于对 Restful 接口的调用。那么这个 Restful 接口是谁提供的呢?其实就是 discovery-console 里面暴露的 restful 接口。

2、discovery-console

discovery-console 是控制平台目录,里面包含 4 个子模块:

+ discovery-console└ discovery-console-starter        【控制平台的starter】└ discovery-console-starter-apollo 【控制平台的Apollo Starter】└ discovery-console-starter-nacos  【控制平台的Nacos Starter】└ discovery-console-starter-redis  【控制平台的Redis Starter】

里面最核心的就是 discovery-console-starter,另外 3 个模块是对不同配置中心的支持。我们首先来分析一下 discovery-console-starter。这个项目里面有对 spring 的扩展,也就是先来解读一下 discovery-console-starter/resources/META-INF/spring.factories 文件。

discovery-console-starter/resources/META-INF/spring.factories

org.springframework.boot.env.EnvironmentPostProcessor=\
com.nepxion.discovery.console.context.ConsoleEnvironmentPostProcessororg.springframework.context.ApplicationContextInitializer=\
com.nepxion.discovery.console.context.ConsoleApplicationContextInitializerorg.springframework.boot.autoconfigure.EnableAutoConfiguration=\
com.nepxion.discovery.console.configuration.ConsoleAutoConfiguration
  • ConsoleEnvironmentPostProcessor:这个类的功能比较简单,它实现了 EnvironmentPostProcessor 对 Spring 环境类的扩展在环境里面添加了 Key 值为 spring.application.type ,value 为 console
  • ConsoleApplicationContextInitializer:这个类实现了 ApplicationContextInitializer,在 Spring 容器初始化之前会执行。对于容器类型非 AnnotationConfigApplicationContext 里面进行了 Log 打印以及添加了对 Web 环境的支持。
  • ConsoleAutoConfiguration:里面主要是配置了 Console 模块的几个功能:SwaggerConfiguration 暴露 swagger 接口,CorsRegistryConfiguration 支持跨越访问,ConsoleEndpoint 暴露控制灰度发布的 restful 接口。AuthenticationResource 提供用户验证功能,主要是用于客户端的登陆。

从上面的分析之中我们可以看到 discovery-console 的核心功能是提供 restful 为外部服务修改配置中心的路由规则。暴露 restful 接口的责任都是在ConsoleEndpoint这个类里面,那下面我们就来分析一下这个类。

3、ConsoleEndpoint

ConsoleEndpoint 这个类还是挺简单的,它其实是通过 spring mvc 暴露一些 restful 的接口。这个类里面主要持有以下几个对象:

ConsoleEndpoint.java

    @Autowiredprivate DiscoveryClient discoveryClient;@Autowired(required = false)private ConfigAdapter configAdapter;@Autowiredprivate AuthenticationResource authenticationResource;private RestTemplate consoleRestTemplate;
  • DiscoveryClient :服务发现客户端,可以从注册中心获取服务实例的信息。
  • ConfigAdapter :配置中心配置类,可以操作不同的配置中心,完成对配置中心灰度路由规则的操作
  • AuthenticationResource:用户认证处理类,用于客户端界面的登陆认证
  • RestTemplate:如果在图形化桌面端和Web端的规则策略推送时调用控制中心的接口时会把灰度策略推送到服务的各个实例里面

控制中心提供的灰度操作功能如下:

  • 登录认证
  • 获取注册发现中心类型
  • 获取配置中心类型
  • 获取服务注册中心的服务组名列表
  • 获取服务注册中心的服务名列表
  • 获取服务注册中心的网关名列表
  • 获取服务注册中心的服务实例列表
  • 获取服务注册中心的服务实例列表(精简数据)
  • 获取服务注册中心的服务实例的Map(精简数据)
  • 推送更新规则配置信息到远程配置中心
  • 清除规则配置信息到远程配置中心
  • 查看远程配置中心的规则配置信息
  • 批量异步推送更新规则配置信息
  • 批量同步推送更新规则配置信息
  • 批量异步清除更新的规则配置信息
  • 批量同步清除更新的规则配置信息
  • 批量异步更新服务的动态版本
  • 批量同步更新服务的动态版本
  • 批量异步清除服务的动态版本
  • 批量同步清除服务的动态版本
  • 更新哨兵规则列表
  • 清除哨兵规则列表
  • 校验策略的条件表达式

但是针对于以下操作需要使用 AbstractRestInvoker#invoke 操作。


这个操作其实是需要对具体服务的实例(比如:servierA)进行操作。里面 AbstractRestInvoker
这个类里面持有三个对象。

  • protected List<ServiceInstance> instances :当前服务的所有实例列表
  • RestTemplate restTemplate:Spring MVC 提供发送 HTTP 的组件接口
  • boolean async:是否异步执行

AbstractRestInvoker 有以下几个实例对象:

  • ConfigClearRestInvoker:配置清除 Restful 调用处理类
  • ConfigUpdateRestInvoker : 配置修改 Restful 调用处理类
  • SentinelClearRestInvoker: 清除Sentinel 哨兵规则列表 Restful 调用处理类
  • SentinelUpdateRestInvoker:更新Sentinel 规则列表 Restful 调用处理类
  • VersionClearRestInvoker:清除灰度 版本 Restful 调用处理类
  • VersionUpdateRestInvoker:修改灰度 版本 Restful 调用处理类

下面我们来分析一下 AbstractRestInvoker#invoke 的调用逻辑。

AbstractRestInvoker.java

public abstract class AbstractRestInvoker {public ResponseEntity<?> invoke() {if (CollectionUtils.isEmpty(instances)) {LOG.warn("No service instances found");return ResponseEntity.status(HttpStatus.INTERNAL_SERVER_ERROR).body("No service instances found");}List<ResultEntity> resultEntityList = new ArrayList<ResultEntity>();for (ServiceInstance instance : instances) {Map<String, String> metadata = instance.getMetadata();String host = instance.getHost();int port = instance.getPort();String contextPath = metadata.get(DiscoveryConstant.SPRING_APPLICATION_CONTEXT_PATH);String url = "http://" + host + ":" + port + UrlUtil.formatContextPath(contextPath) + getSuffixPath();String result = null;try {checkPermission(instance);result = doRest(url);if (!StringUtils.equals(result, DiscoveryConstant.OK)) {result = RestUtil.getCause(restTemplate);}} catch (Exception e) {result = e.getMessage();}ResultEntity resultEntity = new ResultEntity();resultEntity.setUrl(url);resultEntity.setResult(result);resultEntityList.add(resultEntity);}String info = getInfo();LOG.info(info + " results=\n{}", resultEntityList);return ResponseEntity.ok().body(resultEntityList);}......}

通过传入的服务实例的列表,然后根据服务实例的信息拼接调用的 URL。拼接地址为:

String url = "http://" + host + ":" + port + UrlUtil.formatContextPath(contextPath) + getSuffixPath();

也就是其实前面都是通过服务实例获取域名、端口以及 ContextPathgetSuffixPath() 其实就是对应的业务操作。比如版本清除也就是 VersionClearRestInvoker 里面 version/clear- + async(异步)/sync(同步)。那么这个地址是哪里提供的呢?

其实这个地址是在 discovery-plugin-admin-center-starter 这个模块里面进行提供的。不管是基于Swagger和Rest的规则策略推送 还是 基于图形化桌面端和Web端的规则策略推送 操作其实都是基于 discovery-consolediscovery-console相当于是一个桥梁的作用。

  • 通过 DiscoveryClient来操作注册中心
  • 通过 ConfigAdapter 来操作配置中心
  • 通过 RestTemplate 来操作服务实例

如果需要界面化操作的时候微服务里面必须引入 discovery-plugin-admin-center-starter 这个模块。 discovery-plugin-admin-center-starter 里面暴露了以下 restful功能接口:

  • ConfigEndpoint :以 /config 开头的 Restful 配置接口
  • GitEndpoint:以/git 开的头的 Git Restful 信息接口
  • InspectorEndpoint:以/inspector 开头的 Restful 全链路侦测接口
  • RouterEndpoint:以/router 开头的 Restful 路由接口
  • SentinelCoreEndpoint:以/sentinel-core 开头的 Restful 哨兵核心接口
  • SentinelParamEndpoint:以/sentinel-param 开头的 Restful 哨兵参数接口
  • StrategyEndpoint:以/strategy 开头的 Restful 策略接口
  • VersionEndpoint:以/version 开头的 Restful 版本接口

其中 discovery-console-starter 里面的 AbstractRestInvoker 继承类与 discovery-plugin-admin-center-starter 里面的暴露的 XXXEndpoint 的关系是:

AbstractRestInvoker 继承类 XXXEndpoint
ConfigClearRestInvoker ConfigEndpoint
ConfigUpdateRestInvoker ConfigEndpoint
SentinelClearRestInvoker SentinelCoreEndpoint / SentinelParamEndpoint
SentinelUpdateRestInvoker SentinelCoreEndpoint / SentinelParamEndpoint
VersionClearRestInvoker VersionEndpoint
VersionUpdateRestInvoker VersionEndpoint

4、Discovery 图形化桌面端

Discovery 图形化桌面端其实是通过 java swing 编写的客户端工具,它默认配置的 discovery-console 地址是在 desktop/src/main/resource/config/console.properties 里面的值是 url=http://localhost:6001/ 。当然你也可以在登陆界面进行自定义。


这个工程其实挺简单的。这里面需要提的就是以下两点:

  • 启动类是 com.nepxion.discovery.console.desktop.ConsoleLauncher.
  • Nepxion Discovery 基于 ConsoleController 把桌面应用程序与 discovery-console 里面提供的服务进行结合

11、Nepxion Discovery 之全链路界面操作蓝绿灰度发布相关推荐

  1. 13、Nepxion Discovery 之 全链路调用链监控

    在进行微服务调用的时候,为了系统的高可用性,不仅需要进行灰度发布验证服务的可用性.同时对于服务健康的监控也是很重要的一环.Nepxion Discovery 在这方面也有监控方面的集成,包含以下几个方 ...

  2. Libra-Platform微服务平台之全链路蓝绿灰度发布

    1.Libra-Platform 微服务平台 Libra-Platform微服务平台.基于SpringCloud(2020.0.x) + SpringCloudAlibaba(2021.x) + Sp ...

  3. 灰度发布框架Discovery介绍

    概述 灰度发布(又名金丝雀发布)是指在黑与白之间,能够平滑过渡的一种发布方式. 可以进行A/B testing,即让一部分用户继续用产品特性A,一部分用户开始用产品特性B,如果用户对B没有什么反对意见 ...

  4. 全链路压测一招搞定,阿里云性能测试铂金版发布

    摘要: 阿里云性能测试(Performance Testing Service)是卓越的SaaS性能测试平台,具备强大的分布式压测能力,可模拟海量用户的真实业务场景,让所有性能问题无所遁形.近日,PT ...

  5. 高德全链路压测平台TestPG的架构与实践

    导读 2018年十一当天,高德DAU突破一个亿,不断增长的日活带来喜悦的同时,也给支撑高德业务的技术人带来了挑战.如何保障系统的稳定性,如何保证系统能持续的为用户提供可靠的服务?是所有高德技术人面临的 ...

  6. 高德地图全链路压测平台TestPG的架构与实践

    高德地图:全链路压测平台TestPG的架构与实践 转自  https://www.sohu.com/a/341414025_692515 1. 导读 2019年以来,高德DAU一个亿进入常态,不断增长 ...

  7. 有赞11·11:全链路压测方案设计与实施详解

    2017年双十一即将来临,对于买家来说是一年一度的购物狂欢,可是对于电商公司的技术人员来说,却是一年一次的大考.如何用更少的预算完成指定当前业务规模的流量高峰,是技术的永恒主题. \\ 由InfoQ举 ...

  8. OpenKruise:阿里巴巴 双11 全链路应用的云原生部署基座

    来源 | 阿里巴巴云原生公众号 作者 | 王思宇(酒祝) OpenKruise 是由阿里云于 2019 年 6 月开源的云原生应用自动化引擎,本质是基于 Kubernetes 标准扩展出来一个的应用负 ...

  9. 独家揭秘 | 阿里怎么做双11全链路压测?

    阿里妹导读:全链路压测是阿里的首创,我们将从工作内容.操作过程.运行总结等多个方向来介绍下阿里内部典型电商活动(如双11准备),以给大家展示一个完整的压测流程,帮助更多的企业和用户更好的完成性能测试. ...

最新文章

  1. 斐波那契数列的四种实现
  2. mysql中pager命令妙用
  3. 30道Web前端面试题,你能答出多少道?
  4. 为什么mysql 5.7.24启停不显示错误信息?log-error_verbosity参数
  5. 朱海舟宣布新一批应用已经适配锤子TNT 网友:救救海舟
  6. yum 更新内核报错 “Error: initscripts conflicts with centos-release-7-0.1406.el7.centos.2.3.x86_64的解决办法
  7. python __builtins__ str类 (65)
  8. 150分试卷c语言,连续5道C语言题目一共送150分啊,题目2.一个农场有头母牛,现 爱问知识人...
  9. html鼠标各种坐标,各种MOUSE鼠标形状的表示方法
  10. Discrete Cosine Transform Network for Guided Depth Map Super-Resolution
  11. psd.js 解析PSD文件
  12. 【TouchDesigner学习笔记与资料】
  13. Codeforces Round #831 (Div. 1 + Div. 2) problem C
  14. 美元汇率Pascal题解
  15. 小数化分数c++(附做法数学证明)
  16. Android实现下载文件(图片)显示进度
  17. JAVA 正则表达式 (超详细)
  18. 【Py】pyecharts数据可视化案例——地下室空气治理
  19. FME转换DWG到KML或KMZ
  20. 使用java方式装配Bean

热门文章

  1. linux 命令行修改mac,Linux下修改MAC地址
  2. Mule学习-简单示例
  3. 传统企业线下收益不可观,问答营销是你线上引流的好方法
  4. UNIX环境高级编程-环境配置
  5. 2022.7.14 花旗银行外包面试
  6. 记录win10安装多个版本cuda与cudnn+切换使用+发现的一些有趣现象
  7. 定时器之计时(时间的转换)
  8. Swig在windows下的使用流程
  9. 【机器学习基础】支持向量回归
  10. 机器学习 —— 支持向量机