技术方案 on Apache Dubbo

[Google Paper] 面向云时代的应用开发新模式

Fri, 26 May 2023 00:00:00 +0000

本文翻译自发表在以下地址的论文：https://serviceweaver.dev/assets/docs/hotos23_vision_paper.pdf

原文作者(Authors): Sanjay Ghemawat, Robert Grandl, Srdjan Petrovic, Michael Whittaker, Parveen Patel, Ivan Posva, Amin Vahdat

转载或发布请遵循原文许可： Permission to make digital or hard copies of part or all of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. Copyrights for thirdparty components of this work must be honored. For all other uses, contact the owner/author(s). HOTOS ’23, June 22–24, 2023, Providence, RI, USA © 2023 Copyright held by the owner/author(s). ACM ISBN 979-8-4007-0195-5/23/06. https://doi.org/10.1145/3593856.3595909

指标埋点

Mon, 20 Feb 2023 00:00:00 +0000

概述

1. 指标接入说明

2. 指标体系设计

Dubbo的指标体系，总共涉及三块，指标收集、本地聚合、指标推送

指标收集：将Dubbo内部需要监控的指标推送至统一的Collector中进行存储
本地聚合：指标收集获取的均为基础指标，而一些分位数指标则需通过本地聚合计算得出
指标推送：收集和聚合后的指标通过一定的方式推送至第三方服务器，目前只涉及Prometheus

3. 结构设计

移除原来与 Metrics 相关的类
创建新模块 dubbo-metrics/dubbo-metrics-api、dubbo-metrics/dubbo-metrics-prometheus，MetricsConfig 作为该模块的配置类
使用micrometer，在Collector中使用基本类型代表指标，如Long、Double等，并在dubbo-metrics-api中引入micrometer，由micrometer对内部指标进行转换

4. 数据流转

5. 目标

指标接口将提供一个 MetricsService，该 Service 不仅提供柔性服务所的接口级数据，也提供所有指标的查询方式，其中方法级指标的查询的接口可按如下方式声明

public interface MetricsService {

 /**
 * Default {@link MetricsService} extension name.
 */
 String DEFAULT_EXTENSION_NAME = "default";

 /**
 * The contract version of {@link MetricsService}, the future update must make sure compatible.
 */
 String VERSION = "1.0.0";

 /**
 * Get metrics by prefixes
 *
 * @param categories categories
 * @return metrics - key=MetricCategory value=MetricsEntityList
 */
 Map<MetricsCategory, List<MetricsEntity>> getMetricsByCategories(List<MetricsCategory> categories);

 /**
 * Get metrics by interface and prefixes
 *
 * @param serviceUniqueName serviceUniqueName (eg.group/interfaceName:version)
 * @param categories categories
 * @return metrics - key=MetricCategory value=MetricsEntityList
 */
 Map<MetricsCategory, List<MetricsEntity>> getMetricsByCategories(String serviceUniqueName, List<MetricsCategory> categories);

 /**
 * Get metrics by interface、method and prefixes
 *
 * @param serviceUniqueName serviceUniqueName (eg.group/interfaceName:version)
 * @param methodName methodName
 * @param parameterTypes method parameter types
 * @param categories categories
 * @return metrics - key=MetricCategory value=MetricsEntityList
 */
 Map<MetricsCategory, List<MetricsEntity>> getMetricsByCategories(String serviceUniqueName, String methodName, Class<?>[] parameterTypes, List<MetricsCategory> categories);
}

其中 MetricsCategory 设计如下:

Dubbo3 应用级服务发现设计

Mon, 30 Jan 2023 00:00:00 +0000

Objective

显著降低服务发现过程的资源消耗，包括提升注册中心容量上限、降低消费端地址解析资源占用等，使得 Dubbo3 框架能够支持更大规模集群的服务治理，实现无限水平扩容。
适配底层基础设施服务发现模型，如 Kubernetes、Service Mesh 等。

Background

我们从 Dubbo 最经典的工作原理图说起，Dubbo 从设计之初就内置了服务地址发现的能力，Provider 注册地址到注册中心，Consumer 通过订阅实时获取注册中心的地址更新，在收到地址列表后，consumer 基于特定的负载均衡策略发起对 provider 的 RPC 调用。

在这个过程中：

每个 Provider 通过特定的 key 向注册中心注册本机可访问地址；
注册中心通过这个 key 对 provider 实例地址进行聚合；
Consumer 通过同样的 key 从注册中心订阅，以便及时收到聚合后的地址列表；

这里，我们对接口级地址发现的内部数据结构进行详细分析。

首先，看右下角 provider 实例内部的数据与行为。Provider 部署的应用中通常会有多个 Service，也就是 Dubbo2 中的服务，每个 service 都可能会有其独有的配置，我们所讲的 service 服务发布的过程，其实就是基于这个服务配置生成地址 URL 的过程，生成的地址数据如图所示；同样的，其他服务也都会生成地址。

然后，看一下注册中心的地址数据存储结构，注册中心以 service 服务名为数据划分依据，将一个服务下的所有地址数据都作为子节点进行聚合，子节点的内容就是实际可访问的ip地址，也就是我们 Dubbo 中 URL，格式就是刚才 provider 实例生成的。

这里把 URL 地址数据划分成了几份：

首先是实例可访问地址，主要信息包含 ip port，是消费端将基于这条数据生成 tcp 网络链接，作为后续 RPC 数据的传输载体
其次是 RPC 元数据，元数据用于定义和描述一次 RPC 请求，一方面表明这条地址数据是与某条具体的 RPC 服务有关的，它的版本号、分组以及方法相关信息，另一方面表明
下一部分是 RPC 配置数据，部分配置用于控制 RPC 调用的行为，还有一部分配置用于同步 Provider 进程实例的状态，典型的如超时时间、数据编码的序列化方式等。
最后一部分是自定义的元数据，这部分内容区别于以上框架预定义的各项配置，给了用户更大的灵活性，用户可任意扩展并添加自定义元数据，以进一步丰富实例状态。

结合以上两页对于 Dubbo2 接口级地址模型的分析，以及最开始的 Dubbo 基本原理图，我们可以得出这么几条结论：

启发式流控制

Mon, 30 Jan 2023 00:00:00 +0000

整体介绍

本文所说的柔性服务主要是指consumer端的负载均衡和provider端的限流两个功能。在之前的dubbo版本中，

负载均衡部分更多的考虑的是公平性原则，即consumer端尽可能平等的从provider中作出选择，在某些情况下表现并不够理想。
限流部分只提供了静态的限流方案，需要用户对provider端设置静态的最大并发值，然而该值的合理选取对用户来讲并不容易。

我们针对这些存在的问题进行了改进。

负载均衡

使用介绍

在原本的dubbo版本中，有五种负载均衡的方案供选择，他们分别是 Random、ShortestResponse、RoundRobin、LeastActive 和 ConsistentHash。其中除 ShortestResponse 和 LeastActive 外，其他的几种方案主要是考虑选择时的公平性和稳定性。

对于 ShortestResponse 来说，其设计目的是从所有备选的 provider 中选择 response 时间最短的以提高系统整体的吞吐量。然而存在两个问题：

在大多数的场景下，不同provider的response时长没有非常明显的区别，此时该算法会退化为随机选择。
response的时间长短有时也并不能代表机器的吞吐能力。对于 LeastActive 来说，其认为应该将流量尽可能分配到当前并发处理任务较少的机器上。但是其同样存在和 ShortestResponse 类似的问题，即这并不能单独代表机器的吞吐能力。

基于以上分析，我们提出了两种新的负载均衡算法。一种是同样基于公平性考虑的单纯 P2C 算法，另一种是基于自适应的方法 adaptive，其试图自适应的衡量 provider 端机器的吞吐能力，然后将流量尽可能分配到吞吐能力高的机器上，以提高系统整体的性能。

总体效果

对于负载均衡部分的有效性实验在两个不同的情况下进行的，分别是提供端机器配置比较均衡和提供端机器配置差距较大的情况。

使用方法

使用方法与原本的负载均衡方法相同。只需要在consumer端将"loadbalance"设置为"p2c"或者"adaptive"即可。

代码结构

负载均衡部分的算法实现只需要在原本负载均衡框架内继承 LoadBalance接口即可。

原理介绍

P2C算法

Power of Two Choice算法简单但是经典，主要思路如下：

对于每次调用，从可用的provider列表中做两次随机选择，选出两个节点providerA和providerB。
比较providerA和providerB两个节点，选择其“当前正在处理的连接数”较小的那个节点。

adaptive算法

代码的github地址