田小波的技术博客

本文主要介绍了流量录制与回放技术在压测场景下的应用。通过阅读本篇文章，你将了解到开源的录制工具如何内部系统集成、如何进行二次开发以支持 Dubbo 流量录制、怎样通过 Java 类加载机制解决 jar 包版本冲突问题、以及流量录制在自动化测试场景下的应用与价值等。文章共约 1.4 万字，配图17张。本篇文章是对我个人过去一年所负责的工作的总结，里面涉及到了很多技术点，个人从中学到了很多东西，也希望这篇文章能让大家有所收获。

本篇文章记录了一次接口慢查问题排查过程，该问题产生的现象迷惑性较高，同时由于问题偶发性高，排查难度也比较大。排查过程从 druid 数据源“导致”的一个慢查现象作为切入点，逐步分析，排除诸多可能性后仍无解。之后重新审视故障现象，换个角度分析，找到了问题根因。最后对问题原因进行了验证确认，结果符合预期。到此，排查过程算是结束了，本文对问题进行记录归档。

文章标题听起来很耸人听闻，不过确实没有夸大的意思，对于我们来说确实算得上”血案“了。这个问题最终导致了某个底层的核心应用15分钟内不可用，间接导致上层很多应用也出现了问题，尤其是一些支付相关的业务也出现了不可用情况。由于故障影响较大，该故障在内部定级很高。故障排查过程也算是一波三折，中间的槽点也比较多，特别是对网络比较了解的大佬能一眼看出来问题。这个故障的排查工作我也深度参与了，这里做一下总结，希望能给大家一些参考。

1.简介

限流顾名思义是限制流量，限制流量的目的是为了保障服务稳定运行，避免服务被流量冲垮。当流量超出服务处理能力时，部分请求将会被限流组件拦截。被拦截的请求可能会被丢弃，如果是 C 端请求，那么这个请求可能会被导向指定的错误页上，而不是生硬的拒绝。这里我们丢弃掉一部分请求，以保证大部分请求可以正常响应。如果我们不这样做，那么服务崩溃后，所有请求都将无法响应了。当一台机器崩溃后，该机器的所有流量将由其他机器承担，这样就会造成剩余机器压力增大，进而导致奔溃，最后形成雪崩。除此之外，服务崩溃还会造成数据不一致的严重问题，特别是一些敏感数据。比如对于电商网站，如果后台服务准备将某笔订单数据存入数据库时，服务突然崩溃，导致数据没有落库。这个时候，开发同学就要想办法修订数据了。

注: 本系列文章已捐赠给 Dubbo 社区，你也可以在 Dubbo 官方文档中阅读本系列文章。

1. 简介

在前面的文章中，我们分析了 Dubbo SPI、服务导出与引入、以及集群容错方面的代码。经过前文的铺垫，本篇文章我们终于可以分析服务调用过程了。Dubbo 服务调用过程比较复杂，包含众多步骤。比如发送请求、编解码、服务降级、过滤器链处理、序列化、线程派发以及响应请求等步骤。限于篇幅原因，本篇文章无法对所有的步骤一一进行分析。本篇文章将会重点分析请求的发送与接收、编解码、线程派发以及响应的发送与接收等过程，至于服务降级、过滤器链和序列化大家自行进行分析，也可以将其当成一个黑盒，暂时忽略也没关系。介绍完本篇文章要分析的内容，接下来我们进入正题吧。

注: 本系列文章已捐赠给 Dubbo 社区，你也可以在 Dubbo 官方文档中阅读本系列文章。

1.简介

LoadBalance 中文意思为负载均衡，它的职责是将网络请求，或者其他形式的负载“均摊”到不同的机器上。避免集群中部分服务器压力过大，而另一些服务器比较空闲的情况。通过负载均衡，可以让每台服务器获取到适合自己处理能力的负载。在为高负载的服务器分流的同时，还可以避免资源浪费，一举两得。负载均衡可分为软件负载均衡和硬件负载均衡。在我们日常开发中，一般很难接触到硬件负载均衡。但软件负载均衡还是能够接触到一些的，比如 Nginx。在 Dubbo 中，也有负载均衡的概念和相应的实现。Dubbo 需要对服务消费者的调用请求进行分配，避免少数服务提供者负载过大。服务提供者负载过大，会导致部分服务调用超时。因此将负载均衡到每个服务提供者上，是非常必要的。Dubbo 提供了4种负载均衡实现，分别是基于权重随机算法的 RandomLoadBalance、基于最少活跃调用数算法的 LeastActiveLoadBalance、基于 hash 一致性的 ConsistentHashLoadBalance，以及基于加权轮询算法的 RoundRobinLoadBalance。这几个负载均衡算法代码不是很长，但是想看懂也不是很容易，需要大家对这几个算法的原理有一定了解才行。如果不是很了解，也没不用太担心。我会在分析每个算法的源码之前，对算法原理进行简单的讲解，帮助大家建立初步的印象。

注: 本系列文章已捐赠给 Dubbo 社区，你也可以在 Dubbo 官方文档中阅读本系列文章。

1.简介

为了避免单点故障，现在的应用至少会部署在两台服务器上。对于一些负载比较高的服务，会部署更多台服务器。这样，同一环境下的服务提供者数量会大于1。对于服务消费者来说，同一环境下出现了多个服务提供者。这时会出现一个问题，服务消费者需要决定选择哪个服务提供者进行调用。另外服务调用失败时的处理措施也是需要考虑的，是重试呢，还是抛出异常，亦或是只打印异常等。为了处理这些问题，Dubbo 定义了集群接口 Cluster 以及及 Cluster Invoker。集群 Cluster 用途是将多个服务提供者合并为一个 Cluster Invoker，并将这个 Invoker 暴露给服务消费者。这样一来，服务消费者只需通过这个 Invoker 进行远程调用即可，至于具体调用哪个服务提供者，以及调用失败后如何处理等问题，现在都交给集群模块去处理。集群模块是服务提供者和服务消费者的中间层，为服务消费者屏蔽了服务提供者的情况，这样服务消费者就可以处理远程调用相关事宜。比如发请求，接受服务提供者返回的数据等。这就是集群的作用。

注: 本系列文章已捐赠给 Dubbo 社区，你也可以在 Dubbo 官方文档中阅读本系列文章。

1. 简介

上一篇文章分析了集群容错的第一部分 – 服务目录 Directory。服务目录在刷新 Invoker 列表的过程中，会通过 Router 进行服务路由。上一篇文章关于服务路由相关逻辑没有细致分析，一笔带过了，本篇文章将对此进行详细的分析。首先，先来介绍一下服务目录是什么。服务路由包含一条路由规则，路由规则决定了服务消费者的调用目标，即规定了服务消费者可调用哪些服务提供者。Dubbo 目前提供了三种服务路由实现，分别为条件路由 ConditionRouter、脚本路由 ScriptRouter 和标签路由 TagRouter。其中条件路由是我们最常使用的，标签路由暂未在我所分析的 2.6.4 版本中提供，该实现会在 2.7.0 版本中提供。本篇文章将分析条件路由相关源码，脚本路由和标签路由这里就不分析了。下面进入正题。

注: 本系列文章已捐赠给 Dubbo 社区，你也可以在 Dubbo 官方文档中阅读本系列文章。

1. 简介

前面文章分析了服务的导出与引用过程，从本篇文章开始，我将开始分析 Dubbo 集群容错方面的源码。这部分源码包含四个部分，分别是服务目录 Directory、服务路由 Router、集群 Cluster 和负载均衡 LoadBalance。这几个部分的源码逻辑比较独立，我会分四篇文章进行分析。本篇文章作为集群容错的开篇文章，将和大家一起分析服务目录相关的源码。在进行深入分析之前，我们先来了解一下服务目录是什么。服务目录中存储了一些和服务提供者有关的信息，通过服务目录，服务消费者可获取到服务提供者的信息，比如 ip、端口、服务协议等。通过这些信息，服务消费者就可通过 Netty 等客户端进行远程调用。在一个服务集群中，服务提供者数量并不是一成不变的，如果集群中新增了一台机器，相应地在服务目录中就要新增一条服务提供者记录。或者，如果服务提供者的配置修改了，服务目录中的记录也要做相应的更新。如果这样说，服务目录和注册中心的功能不就雷同了吗。确实如此，这里这么说是为了方便大家理解。实际上服务目录在获取注册中心的服务配置信息后，会为每条配置信息生成一个 Invoker 对象，并把这个 Invoker 对象存储起来，这个 Invoker 才是服务目录最终持有的对象。Invoker 有什么用呢？看名字就知道了，这是一个具有远程调用功能的对象。讲到这大家应该知道了什么是服务目录了，它可以看做是 Invoker 集合，且这个集合中的元素会随注册中心的变化而进行动态调整。

注: 本系列文章已捐赠给 Dubbo 社区，你也可以在 Dubbo 官方文档中阅读本系列文章。

1. 简介

在上一篇文章中，我详细的分析了服务导出的原理。本篇文章我们趁热打铁，继续分析服务引用的原理。在 Dubbo 中，我们可以通过两种方式引用远程服务。第一种是使用服务直联的方式引用服务，第二种方式是基于注册中心进行引用。服务直联的方式仅适合在调试或测试服务的场景下使用，不适合在线上环境使用。因此，本文我将重点分析通过注册中心引用服务的过程。从注册中心中获取服务配置只是服务引用过程中的一环，除此之外，服务消费者还需要经历 Invoker 创建、代理类创建等步骤。这些步骤，我将在后续章节中一一进行分析。