关于运维:DubboAdmin-正式支持-30-服务治理

1次阅读

共计 4486 个字符,预计需要花费 12 分钟才能阅读完成。

作者介绍

程露,Java 开发工程师,中间件开发爱好者,关注服务治理。严浩,Dubbo 贡献者,关注 RPC、服务治理等畛域。

前言

Dubbo 置信大家并不生疏,是一款微服务开发框架,它提供了 RPC 通信与微服务治理两大要害能力。大家在日常开发中更多应用的是 dubbo 提供的 RPC 通信这一部分能力,而对其提供的服务治理的能力应用绝对少一些,本文的重点将放在服务治理这方面。dubbo 框架提供了极其丰富的服务治理的性能如流量管制、动静配置、服务 Mock、服务测试等性能,而 dubbo-admin 的作用在于将 dubbo 框架提供的服务治理能力提供一个开箱即用的平台。本文将介绍 dubbo-admin 所提供的性能,让大家疾速理解和应用 dubbo-admin 并对 dubbo 所提供的服务治理能力有个初步的理解。

服务详情

服务详情将以接口为维度展现 dubbo 服务所提供的服务信息,蕴含服务提供者、消费者信息和服务的元数据信息比方提供的办法名和参数列表。在最新版本反对了 dubbo 3.0 所提供的利用级发现模型,在注册起源用 利用级 / 接口级 进行辨别。

动静路由

Dubbo-Admin 提供了三种路由的反对,别离是条件路由、标签路由、Mesh 路由,所提供的性能能够轻松实现黑白名单、集群隔离、金丝雀公布等服务治理的诉求。上面将举例一一展现这一部分的性能。

条件路由

条件路由能够编写一些自定义路由规定实现服务治理的需要比方黑白名单、读写拆散等。路由规定在发动一次 RPC 调用前起到过滤指标服务器地址的作用,过滤后的地址列表,将作为生产端最终发动 RPC 调用的备选地址。

下图为一个简略的黑名单性能的实现,该路由规定的含意为禁止 IP 为 172.22.3.91 消费者调用服务 HelloService,条件路由规定的格局为:[服务消费者匹配条件] => [服务提供者匹配条件]。

标签路由

标签路由通过将某一个或多个服务的提供者划分到同一个分组,束缚流量只在指定分组中流转,从而实现流量隔离的目标,能够作为蓝绿公布、灰度公布等场景的能力根底。在 provider 利用级别上创立规定,对应的动态打标为 dubbo.provider.tag=tag1 和 @DubboService(tag = “tag2”)。

Mesh 路由

Mesh 路由是 dubbo 3.0 推出的全新的路由规定性能极其弱小,应用 mesh 路由可能笼罩上诉两种路由的性能场景,并且还能够组合出更加简单路由场景。

Mesh 路由将整个流量治理分成 VirtualService 和 DestinationRule 两局部,VirtualService 匹配入口流量,DestinationRule 匹配进口流量。上面将实现一个案例,通过对服务 HelloService 的 hi 办法通过入参 number 进行路由,实现入参为偶数的申请路由到 label 为 v1 的服务,入参为奇数的服务路由到 label 为 v2 的服务的性能。

​public interface HelloService {​
​ ​
​ String hi(Integer number);​
​​​
​}​

​服务实现返回服务提供方端口。

​​public class HelloServiceImpl implements HelloService {​​
​​​​​​
​​ @Value("${dubbo.protocol.port}")​​
​​ private String port;​​
​​​​​​
​​ @Override​​
​​ public String hi(Integer number) {​​
​​​​​​
​​ return "hi" + number + ", my port is :" + port;​​
​​ }​​
​​}​​

第一步:启动两个服务提供方参数别离为 port = 20883、dubbo.application.parameters.test-version = v1 和 port = 20884、dubbo.application.parameters.test-version = v2,通过 dubbo.application.parameters 定义的参数将会裸露到服务的 URL 上。

​dubbo.application.parameters.test-version = v1​
​dubbo.protocol.port=20883​

第二步:创立 mesh 路由规定,该路由规定定义了 VirtualService、DestinationRule 两局部。DestinationRule 局部将服务 URL 参数 test-version=v1 和 test-version=v2 别离划分为服务 v1 和 v2。VirtualService 则将匹配服务 HelloService#hi 办法的入参,将偶数路由到 v1 服务,奇数路由到 label 为 v2 的服务。

​apiVersion: service.dubbo.apache.org/v1alpha1​
​kind: VirtualService​
​metadata:​
​ name: demo/oddEvenRouter​
​spec:​
​ dubbo:​
​ - routedetail:​
​ - match:​
​ - method:​
​ argc: 1​
​ args:​
​ - index: 0​
​ num_value:​
​ oneof:​
​ - exact: 0.0​
​ mod: 2.0​
​ type: int​
​ name_match:​
​ exact: hi​
​ name: even-route​
​ route:​
​ - destination:​
​ host: demo​
​ subset: v1​
​ - match:​
​ - method:​
​ argc: 1​
​ args:​
​ - index: 0​
​ num_value:​
​ oneof:​
​ - exact: 1.0​
​ mod: 2.0​
​ type: int​
​ name_match:​
​ exact: hi​
​ name: odd-route​
​ route:​
​ - destination:​
​ host: demo2​
​ subset: v2 ​
​ services:​
​ - exact: org.test.apache.dubbo.interfaces.HelloService ​
​---​
​apiVersion: service.dubbo.apache.org/v1alpha1​
​kind: DestinationRule​
​metadata:​
​ name: test-route​
​spec:​
​ host: demo​
​ subsets:​
​ - name: v1​
​ labels:​
​ test-version: v1​
​ - name: v2​
​ labels:​
​ test-version: v2​

第三步:启动消费者进行测试,能够看见返回后果如咱们期待的那样,通过上诉案例实现了一个简略的灰度性能,当然也能够轻松实现 A/ B 测试、金丝雀公布等性能。

动静配置

动静配置提供了毋庸重启能够动静调整 RPC 调用行为的一种能力。比方批改超时工夫、权重、负载平衡策略调整、服务降级等。防止了为了调整 Dubbo 参数而须要重启服务的场面,上面将展现一些常见的参数调整状况。

  1. 超时工夫调整,超时工夫调整为 6000 ms
​configVersion: v2.7​
​enabled: true​
​configs: ​
​ - addresses: [0.0.0.0] # 0.0.0.0 for all addresses​
​ side: consumer # effective side, consumer or addresses​
​ parameters: ​
​ timeout: 6000 # dynamic config parameter​
  1. 权重调整
​configVersion: v2.7​
​scope: application​
​key: demo-provider​
​enabled: true​
​configs:​
​- addresses: ["10.20.153.10:20880"]​
​ side: provider​
​ parameters:​
​ weight: 200​
  1. 负载策略调整
​configVersion: v2.7​
​scope: application​
​key: demo-consumer​
​enabled: true​
​configs:​
​- side: consumer​
​ parameters:​
​ loadbalance: random​

文档与测试

接口文档

Dubbo-Api-Docs 是一个展现 dubbo 接口文档,测试接口的工具,相当于 swagger 对于 RESTful 格调的 Web 服务的作用。应用该性能须要 dubbo 服务引入相干包 dubbo-api-docs-annotations 和 dubbo-api-docs-core,应用应用通过注解的模式形容接口和参数信息。

​<dependency>​
​ <groupId>org.apache.dubbo</groupId>​
​ <artifactId>dubbo-api-docs-annotations</artifactId>​
​ <version>${dubbo-version}</version>​
​</dependency>​

​<dependency>​
​ <groupId>org.apache.dubbo</groupId>​
​ <artifactId>dubbo-api-docs-core</artifactId>​
​ <version>${dubbo-version}</version>​
​</dependency>

效果图如下

服务测试

服务测试相比 dubbo-api-docs 不须要引入任何依赖就能对 dubbo 服务进行测试,不便疾速调整和验证 dubbo 服务,效果图如下:

服务 Mock

服务 Mock 通过无代码嵌入的形式将 Consumer 对 Provider 的申请进行拦挡,动静的对 Consumer 的申请进行放行或返回用户自定义的 Mock 数据。从而解决在后期开发过程中,Consumer 所依赖的 Provider 未准备就绪时,造成 Consumer 开发方的阻塞问题。

只须要以下两步,即可享受服务 Mock 性能带来的便捷:

第一步:Consumer 利用引入服务 Mock 依赖,增加 JVM 启动参数 -Denable.dubbo.admin.mock=true 开启服务 Mock 性能。

​<denpendency>​
​ <groupId>org.apache.dubbo.extensions</groupId>​
​ <artifactId>dubbo-mock-admin</artifactId>​
​ <version>last</version>​
​</denpendency>

第二步:在 Dubbo Admin 中配置对应的 Mock 数据。

小结

本文介绍了 dubbo-admin 的大部分性能,笼罩开发、测试和线上整个阶段。心愿本文可能给应用和动手 dubbo- admin 带来一些帮忙,具体的应用细节还须要参考官网,也心愿 dubbo-admin 可能给 dubbo 使用者带来一个全新的体验,更不便疾速的应用 dubbo 所提供进去服务治理的能力。

正文完
 0