Middleware
文章平均质量分 94
贝克街的流浪猫
公众号: 贝贝猫技术分享
展开
-
Sentinel 简介
引言随着微服务的流行,服务和服务之间的稳定性变得越来越重要。从本篇文章开始,我们将进入 Sentinel 的世界,看看它作为一个流量控制组件,是如何从流量控制、熔断降级、系统自适应保护等多个维度来保障微服务的稳定性的。本文作为 Sentinel 系列文章的开篇,会先简单地介绍一下 Sentinel 中的概念以及设计思想,在接下来的文章中,我们还会介绍 Sentinel 的使用方式,以及各个核心模块的实现原理。简介随着微服务的流行,服务和服务之间的稳定性变得越来越重要。Sentinel 是面向分布式服原创 2021-04-07 09:37:57 · 734 阅读 · 1 评论 -
Sentinel 定义资源
引言在前面的文章中,我们已经简单地介绍了 Sentinel 的核心概念、核心功能以及实现的思想,从本篇文章开始,我将介绍一下如何使用 Sentinel 的核心功能,本文先介绍一下如何定义 Sentinel 中的资源。简介Sentinel 可以简单的分为 Sentinel 核心库和 Dashboard。核心库不依赖 Dashboard,但是结合 Dashboard 可以取得最好的效果。这里所说的资源,可以是任何东西,服务,服务里的方法,甚至是一段代码。使用 Sentinel 来进行资源保护,主要分为几原创 2021-04-07 09:37:51 · 763 阅读 · 0 评论 -
Sentinel 规则的种类
引言在前面的文章中,我们已经简单地介绍了如何在 Sentinel 中如何定义资源,本文将介绍 Sentinel 中所包含的各种类型的规则。规则的种类Sentinel 的所有规则都可以在内存态中动态地查询及修改,修改之后立即生效。同时 Sentinel 也提供相关 API,供您来定制自己的规则策略。Sentinel 支持以下几种规则:流量控制规则、熔断降级规则、系统保护规则、来源访问控制规则和热点参数规则。流量控制流量控制(flow control),其原理是监控应用流量的 QPS 或并发线程数原创 2021-04-07 09:37:44 · 903 阅读 · 0 评论 -
Sentinel 查看和定义规则
引言在前面的文章中,我们已经简单地介绍了 Sentinel 中所包含的各类规则,本文将介绍 Sentinel 中各类规则的查看和修改方式。查看和修改规则查询更改规则引入了 transport 模块后,可以通过以下的 HTTP API 来获取所有已加载的规则:http://localhost:8719/getRules?type=<XXXX>type=flow: 以 JSON 格式返回现有的限流规则type=degrade: 返回现有生效的降级规则列表type=system: 则原创 2021-04-07 09:37:37 · 841 阅读 · 0 评论 -
Sentinel 实现原理——概述
引言在前面的文章中,我已经介绍了 Sentinel 中的概念,以及所提供的各类功能如何使用。从本篇文章开始,我们将深入到源码中,自顶向下地介绍 Sentinel 整体的实现原理以及各个核心模块的实现原理。本文作为这一部分介绍的开篇,我会先介绍一下 Sentinel 的整体设计思想,以及下层包含的各个模块,后续的文章中会详细地介绍各个核心模块的实现原理。整体设计接下来,我们会分别从数据和处理过程这两个角度介绍 Sentinel 的设计原理,首先,我们先介绍一下 Sentinel 中内部是如何组织数据的原创 2021-04-07 09:37:32 · 1445 阅读 · 1 评论 -
Sentinel 实现原理——Context
引言在前面的文章中,我已经介绍了 Sentinel 的整体设计思想,本文主要介绍 Sentinel 中贯穿整个调用链路的 Context 容器实现。源码解读Context 容器所存储的数据并不多,只包含如下属性:// com.alibaba.csp.sentinel.context.Contextpublic class Context { /** * Context name. */ private final String name; /**原创 2021-04-07 09:37:25 · 417 阅读 · 0 评论 -
Sentinel 实现原理——处理链
引言从本篇文章开始,就要介绍 Sentinel 限流降级功能的核心了,前面也说过 Sentinel 使用了一套类似于责任链的模式来实现这个部分,这里我们展开一下,将责任链中的各个部分分别详细的介绍一下。源码解读上图仅作为设计思想的展示,图中 Slot 的顺序已和最新版 Sentinel Slot Chain 顺序不一致前面我们已解说了,Sentinel 中最核心的功能都是通过一套处理链(责任链)来实现,处理链中的每一个处理单元被称为一个 Slot。每个 Slot 执行完业务逻辑处理后,都会触原创 2021-04-07 09:37:10 · 409 阅读 · 0 评论 -
Seata 简介
引言Seata 的前身 Fescar 刚开源的时候,就看过相关的文章和代码,代码写得很好,我还在另一个自己的项目中,借鉴了它的很多设计风格。最近想总结一篇关于分布式事务的文章,所以就想以 Seata 为中心,围绕它来细述分布式事务的点点滴滴。本文作为该系列文章的开篇,先简单地介绍一下 Seata 的背景和使用方式。背景互联网系统最初的设计一般都是单库单表,但随着业务数据规模的快速发展,数据量越来越大,单库单表逐渐成为瓶颈。所以,在这个阶段一般都会对数据库进行水平拆分,将原单库单表拆分成多个数据库分片。原创 2021-04-01 08:06:09 · 411 阅读 · 2 评论 -
Seata 设计方案
引言在深入介绍 Seata 的实现之前,我们先在一个较高的层面一览 Seata 的整体设计思想。设计方案整体架构首先,很自然的,我们可以把一个分布式事务理解成一个包含了若干分支事务的全局事务。全局事务的职责是协调其下管辖的分支事务达成一致,要么一起成功提交,要么一起失败回滚。此外,通常分支事务本身就是一个满足 ACID 的本地事务。基于两阶段提交模式,从设计上我们可以将整体分成三个大模块,即TM、RM、TC,具体解释如下:TM(Transaction Manager):全局事务管理器,控制全原创 2021-04-01 08:06:03 · 349 阅读 · 1 评论 -
Seata Transaction Coordinator
引言前面,我们已经介绍了 Seata 的整体设计思想,接下来我们深入到其实现细节中,本文介绍 Seata 中最核心的模块 Transaction Coordinator 的实现。TCTransaction Coordinator 整体的模块图如上所示:Coordinator Core: 在最下面的模块是事务协调器核心代码,主要用来处理事务协调的逻辑,如分支的注册, commit, rollback 等协调活动。Store: 存储模块,用来将我们的数据持久化,防止重启或者宕机数据丢失。Disc原创 2021-03-31 08:56:55 · 293 阅读 · 0 评论 -
Seata Transaction Manager
引言前面,我们已经介绍了 Seata 的整体设计思想,接下来我们深入到其实现细节中,本文介绍 Seata 中 Transaction Manager 的实现。TMTM 和 TC 一样是一个共通的模块, 无论是 AT 模式还是 TCC 模式都需要使用 TM 模块。首先 TM 在启动的时候会去连接 TC Server, 然后然后通过该 TM Client 与 TC 模块进行通讯。在 TM 模块中最核心的接口就是 GlobalTransaction, 里面包含了全局事务的创建, 提交, 回滚过程, 其实质原创 2021-03-31 08:56:49 · 377 阅读 · 1 评论 -
Seata 分支事务
引言前面,我们已经介绍了 Seata 的整体设计思想,接下来我们深入到其实现细节中,本文先来介绍 Seata 中分支事务的整体实现思想。Branch Type我们已经知道在 Seata 中, 分支事务分 AT 模式和 TCC 模式, 那么, Seata 是怎么区分出 AT 模式和 TCC 模式的呢? 这也借助了 Spring 的 AOP 特性, 我们在 TM 中介绍的 GlobalTransactionalInterceptor 实际上只负责 AT 模式, TCC 模式是另一套拦截器实现, 而这两种拦原创 2021-03-31 08:56:44 · 373 阅读 · 0 评论 -
Seata AT 分支事务
引言前面,我们已经介绍了 Seata 的整体设计思想,接下来我们深入到其实现细节中,本文介绍 Seata 中 AT 模式分支事务的实现。AT 模式前面在介绍 Seata 入口时, 大家可能会注意到 GlobalTransactionScanner 中还存在一个数据源的代理:// 替换默认的数据库连接源, 改为 AT 模式的数据源代理@Overridepublic Object postProcessBeforeInitialization(Object bean, String beanName原创 2021-03-31 08:56:39 · 780 阅读 · 0 评论 -
Seata TCC 分支事务
引言前面,我们已经介绍了 Seata 的整体设计思想,接下来我们深入到其实现细节中,本文介绍 Seata 中 TCC 模式分支事务的实现。TCC 模式先简单介绍一个 Seata 中 TCC 的使用方式, 然后我们在顺着它的使用方式, 一点点深入其实现方案。在 Seata TCC 模式中, 每个 RM 都需要将 TCC 接口以 RPC 的形式暴露出去, 同时向 TC 中注册, 告诉 TC 自己是某一 TCC 接口的提供方, 这样如果发生提交或者回滚时, TC 就知道该去找谁了。然后 TM 在进行 TC原创 2021-03-31 08:56:33 · 511 阅读 · 0 评论 -
RocketMQ 简介
引言本系列文章详细地介绍了 RocketMQ 的设计思想和实现细节,本文作为开篇,着重介绍了 RocketMQ 的设计思想已经常见使用场景。功能介绍简单来说,消息队列就是基础数据结构课程里“先进先出”的一种数据结构,但是如果要消除单点故障,保证消息传输的可靠性,并且还能应对大流量的冲击,对消息队列的要求就很高了。现在互联网“微架构”模式兴起,原有大型集中式的IT服务因为各种弊端,通常被分拆成细粒度的多个“微服务”,这些微服务可以在一个局域网内,也可能跨机房部署。一方面对服务之间松耦合的要求越来越高,另原创 2021-03-31 08:56:28 · 343 阅读 · 0 评论 -
RocketMQ NameServer
引言前面我们已经简单地介绍了 RocketMQ 的整体设计思路,本文着重其中 NameServer 部分的实现细节。NameServer本节主要介绍RocketMQ路由管理、服务注册及服务发现的机制,NameServer是整个RocketMQ的“大脑”。相信大家对“服务发现”这个词语并不陌生,分布式服务SOA架构体系中会有服务注册中心,分布式服务SOA的注册中心主要提供服务调用的解析服务,指引服务调用方(消费者)找到“远方”的服务提供者,完成网络通信,那么RocketMQ的路由中心存储的是什么数据呢?原创 2021-03-31 08:56:24 · 227 阅读 · 0 评论 -
RocketMQ 发送消息
引言前面我们已经简单地介绍了 RocketMQ 的整体设计思路,本文着重其中消息发送部分的实现细节。消息发送RocketMQ支持3种消息发送方式:同步(sync)、异步(async)、单向(oneway)。同步:发送者向MQ执行发送消息API时,同步等待,直到消息服务器返回发送结果。异步:发送者向MQ执行发送消息API时,指定消息发送成功后的回调函数,然后调用消息发送API后,立即返回,消息发送者线程不阻塞,直到运行结束,消息发送成功或失败的回调任务在一个新的线程中执行。单向:消息发送者向MQ原创 2021-03-31 08:56:19 · 276 阅读 · 0 评论 -
RocketMQ 消息存储文件
引言前面我们已经简单地介绍了 RocketMQ 的整体设计思路,本文着重其中消息存储文件部分。文件详解了解完了文件存储部分使用的核心技术,在让我们回到 RocketMQ 文件组织的讨论中来,接下来我将挨个分析各个核心文件存储的内容和使用方法。Commit文件commitlog 目录的组织方式在前面已经详细介绍过了,该目录下的文件主要存储消息,其特点是每一条消息长度不相同,CommitLog 文件存储的逻辑视图如下图所示,每条消息的前面4个字节存储该条消息的总长度。整个 CommitLog 文件默认原创 2021-03-30 08:41:44 · 297 阅读 · 0 评论 -
RocketMQ 内存映射
引言前面我们已经简单地介绍了 RocketMQ 的整体设计思路,本文着重其中使用到的内存映射相关内容。内存映射RocketMQ通过使用内存映射文件来提高IO访问性能,无论是CommitLog、 ConsumeQueue还是IndexFile,单个文件都被设计为固定长度,如果一个文件写满以后再创建一个新文件,文件名就为该文件第一条消息对应的全局物理偏移量。例如CommitLog的文件组织方式如下图所示。RocketMQ使用 MappedFile、 MappedFileQueue来封装存储文件。M原创 2021-03-31 08:56:02 · 417 阅读 · 0 评论 -
RocketMQ 消息存储
引言前面我们已经简单地介绍了 RocketMQ 的整体设计思路,本文着重其中消息存储部分的整体实现思路。消息存储通过前面的知识,我们已经知道了topic是如何分配到Broker的,以及消息发送方是如何决定把消息发送给哪个Broker的,接下来我们看一看Broker介绍到消息后,是怎么存储消息的。RocketMQ主要存储的文件包括CommitLog文件、ConsumeQueue文件、IndexFile文件。RocketMQ将所有主题的消息存储在同一个文件中,确保消息发送时顺序写文件,尽最大的能力确保消原创 2021-03-31 08:56:13 · 204 阅读 · 0 评论 -
RocketMQ 消息消费
引言前面我们已经简单地介绍了 RocketMQ 的整体设计思路,本文着重其中消息消费部分的实现细节。消息消费消息消费以组的模式开展,一个消费组内可以包含多个消费者,每一个消费组可订阅多个主题,消费组之间有集群模式与广播模式两种消费模式。集群模式,主题下的同一条消息只允许被其中一个消费者消费。广播模式,主题下的同一条消息将被集群内的所有消费者消费一次。消息服务器与消费者之间的消息传送也有两种方式:推模式、拉模式。所谓的拉模式,是消费端主动发起拉消息请求,而推模式是消息到达消息服务器后,推送给消息消费者。原创 2021-03-30 08:41:39 · 744 阅读 · 1 评论 -
RocketMQ 消息过滤
引言前面我们已经简单地介绍了 RocketMQ 的整体设计思路,本文着重其中消息过滤部分的实现细节。FilterServer 过滤器RocketMQ 提供了基于表达式与基于类模式两种过滤模式,前面已经详细介绍了整个消息拉取、基于表达式(TAG)的过滤模式。基于类模式过滤是指在 Broker 端运行 1 个或多个消息过滤服务器(FilterServer), RocketMQ 允许消息消费者自定义消息过滤实现类并将其代码上传到 FilterServer 上,消息消费者向 FilterServer 拉取消息原创 2021-03-30 08:41:33 · 235 阅读 · 0 评论 -
RocketMQ HA机制
引言前面我们已经简单地介绍了 RocketMQ 的整体设计思路,本文着重其中HA机制部分的实现细节。HA机制为了提高消息消费的高可用性,避免 Broker 发生单点故障引起存储在 Broker 上的消息无法及时消费,RocketMQ 引入了 Broker 主备机制,即消息消费到达主服务器后需要将消息同步到消息从服务器,如果主服务器 Broker 宕机后,消息消费者可以从从服务器拉取消息。工作机制RocketMQ HA 的实现原理如下。主服务器启动,并在特定端口上监听从服务器的连接从服务器主动原创 2021-03-30 08:41:10 · 287 阅读 · 0 评论 -
RocketMQ 事务消息
引言前面我们已经简单地介绍了 RocketMQ 的整体设计思路,本文着重其中事务消息部分的实现细节。事务消息Apache RocketMQ 在4.3.0版中已经支持分布式事务消息,这里 RocketMQ 采用了 2PC 的思想来实现了提交事务消息,同时增加一个补偿逻辑来处理二阶段超时或者失败的消息,如下图所示。上图说明了事务消息的大致方案,其中分为两个流程:正常事务消息的发送及提交、事务消息的补偿流程。事务消息发送及提交:发送消息(half 消息)服务端响应消息写入结果根据发送结果执行本原创 2021-03-30 08:41:04 · 176 阅读 · 1 评论 -
RocketMQ 常见问题
引言至此,我们已经介绍完了 RocketMQ 的所有实现细节,最后我们简单地介绍一下使用 RocketMQ 时常见的问题。常见问题顺序消息方案顺序消息是指消息的消费顺序和产生顺序相同,在有些业务逻辑下,必须保证顺序。比如订单的生成、付款、发货,这 3 个消息必须按顺序处理才行。顺序消息分为全局顺序消息和部分顺序消息,全局顺序消息指某个 Topic 下的所有消息都要保证顺序;部分顺序消息只要保证每一组消息被顺序消费即可,比如上面订单消息的例子,只要保证同一个订单 ID 的三个消息能按顺序消费即可。原创 2021-03-30 08:40:58 · 917 阅读 · 1 评论 -
Dubbo设计思想
引言之前在开发第一个项目的时候用到了Dubbo,但是对其实现原理并没有深入研究,最近想要总结一下关于RPC的相关知识,所以就选择Dubbo作为切入点,来一窥服务治理型RPC的设计。本文主要介绍 Dubbo 设计上的一些思想。背景随着互联网的发展,网站应用的规模不断扩大,常规的垂直应用架构已无法应对,分布式服务架构以及流动计算架构势在必行,亟需一个治理系统确保架构有条不紊的演进。单一应用架构当网站流量很小时,只需一个应用,将所有功能都部署在一起,以减少部署节点和成本。此时,用于简化增删改查工作量的原创 2021-03-30 08:40:40 · 238 阅读 · 0 评论 -
Dubbo SPI 简介
引言前面,我们已经介绍了 Dubbo 设计上的一些思想,本文主要介绍 Dubbo 在 SPI(Service Provider Interface)上的一些改进。SPI我们知道Dubbo的设计原则是微内核+富扩展,它的内核部分就是将各个模块组装起来,而各个模块都抽象称为接口,这样替换任意模块都非常方便。接下来就让我们一起来看一看Dubbo的扩展点是如何设计的。来源Dubbo 的扩展点加载从 JDK 标准的 SPI (Service Provider Interface) 扩展点发现机制加强而来。原创 2021-03-30 08:40:35 · 198 阅读 · 0 评论 -
Dubbo SPI 实现
引言前文中,我们已经介绍 Dubbo SPI 和 Java SPI 的区别以及一些增强,本文我们着重介绍 Dubbo SPI 的实现方式。实现原理SPI 全称为 Service Provider Interface,是一种服务发现机制。SPI 的本质是将接口实现类的全限定名配置在文件中,并由服务加载器读取配置文件,加载实现类。这样可以在运行时,动态为接口替换实现类。正因此特性,我们可以很容易的通过 SPI 机制为我们的程序提供拓展功能。SPI 机制在第三方框架中也有所应用,比如 Dubbo 就是通过原创 2021-03-30 08:40:31 · 210 阅读 · 0 评论 -
Dubbo实现方案总览
引言从这篇文章开始,我们就开始深入到 Dubbo 的实现细节中,本文旨在一个较高的层面上总览 Dubbo 的实现方案。总览首先,我们简单的介绍一下各个功能点的实现,然后再深入代码中,详细分析每个功能点的细节。解析服务基于 dubbo.jar 内的 META-INF/spring.handlers 配置,Spring 在遇到 dubbo 名称空间时,会回调 DubboNamespaceHandler。所有 dubbo 的标签,都统一用 DubboBeanDefinitionParser 进行解析,原创 2021-03-30 08:40:25 · 212 阅读 · 0 评论 -
Dubbo服务暴露
引言通过前面的文章,想必大家对 Dubbo 的整体实现思想已经有了一个全面的认识,本文中,我们主要深入介绍服务暴露的实现细节。暴露服务方式Dubbo 服务导出过程始于 Spring 容器发布刷新事件,Dubbo 在接收到事件后,会立即执行服务导出逻辑。整个逻辑大致可分为三个部分,第一部分是前置工作,主要用于检查参数,组装 URL。第二部分是导出服务,包含导出服务到本地 (JVM),和导出服务到远程两个过程。第三部分是向注册中心注册服务,用于服务发现。起点服务导出的入口方法是 ServiceBean原创 2021-03-29 09:03:21 · 173 阅读 · 0 评论 -
Dubbo服务引用
引言前面的文章中,我们已经详细介绍了服务暴露的相关细节,本文中,我们主要深入介绍服务引用的实现细节。引用服务方式在 Dubbo 中,我们可以通过两种方式引用远程服务。第一种是使用服务直连的方式引用服务,第二种方式是基于注册中心进行引用。服务直连的方式仅适合在调试或测试服务的场景下使用,不适合在线上环境使用。因此,接下来我将重点分析通过注册中心引用服务的过程。从注册中心中获取服务配置只是服务引用过程中的一环,除此之外,服务消费者还需要经历 Invoker 创建、代理类创建等步骤。Dubbo 服务引用的转载 2021-03-29 09:03:16 · 281 阅读 · 0 评论 -
Dubbo服务目录
引言前面的文章中,我们分别介绍了服务暴露与服务引用的相关细节,本文中,我们来看一看上述两个过程的粘合剂服务目录的实现细节。服务目录在进行深入分析之前,我们先来了解一下服务目录是什么。服务目录中存储了一些和服务提供者有关的信息,通过服务目录,服务消费者可获取到服务提供者的信息,比如 ip、端口、服务协议等。通过这些信息,服务消费者就可通过 Netty 等客户端进行远程调用。在一个服务集群中,服务提供者数量并不是一成不变的,如果集群中新增了一台机器,相应地在服务目录中就要新增一条服务提供者记录。或者,如果原创 2021-03-29 09:03:07 · 149 阅读 · 0 评论 -
Dubbo服务路由
引言当一个服务存在多个 Provider 时,势必就需要考虑服务路由问题,本文中,我们就来介绍 Dubbo 服务路由的实现细节。服务路由服务目录在刷新 Invoker 列表的过程中,会通过 Router 进行服务路由,筛选出符合路由规则的服务提供者。服务路由包含一条路由规则,路由规则决定了服务消费者的调用目标,即规定了服务消费者可调用哪些服务提供者。Dubbo 目前提供了三种服务路由实现,分别为条件路由 ConditionRouter、脚本路由 ScriptRouter 和标签路由 TagRouter原创 2021-03-29 09:03:02 · 228 阅读 · 0 评论 -
Dubbo集群容错
引言本文中,我们将详细地介绍 Dubbo 在集群容错这个方向上所做出的努力。集群容错为了避免单点故障,现在的应用通常至少会部署在两台服务器上。对于一些负载比较高的服务,会部署更多的服务器。这样,在同一环境下的服务提供者数量会大于1。对于服务消费者来说,同一环境下出现了多个服务提供者。这时会出现一个问题,服务消费者需要决定选择哪个服务提供者进行调用。另外服务调用失败时的处理措施也是需要考虑的,是重试呢,还是抛出异常,亦或是只打印异常等。为了处理这些问题,Dubbo 定义了集群接口 Cluster 以及原创 2021-03-29 09:02:57 · 132 阅读 · 0 评论 -
Dubbo负载均衡
引言本文中,我们将详细地介绍 Dubbo 在负载均衡这个方向上所做出的努力。负载均衡LoadBalance 中文意思为负载均衡,它的职责是将网络请求,或者其他形式的负载“均摊”到不同的机器上。避免集群中部分服务器压力过大,而另一些服务器比较空闲的情况。通过负载均衡,可以让每台服务器获取到适合自己处理能力的负载。在为高负载服务器分流的同时,还可以避免资源浪费,一举两得。负载均衡可分为软件负载均衡和硬件负载均衡。在我们日常开发中,一般很难接触到硬件负载均衡。但软件负载均衡还是可以接触到的,比如 Nginx原创 2021-03-29 09:02:51 · 161 阅读 · 0 评论 -
Dubbo Provider 函数执行过程
引言在 Dubbo 系列文章的最后,我们回过头来看一下整个 RPC 过程是如何运作起来的,本文着重介绍整个调用链路中 Provider 的函数执行过程。服务调用过程在前面的文章中,我们分析了 Dubbo SPI、服务导出与引入、以及集群容错方面的代码。经过前文的铺垫,我们终于可以分析服务调用过程了。Dubbo 服务调用过程比较复杂,包含众多步骤,比如发送请求、编解码、服务降级、过滤器链处理、序列化、线程派发以及响应请求等步骤。接下来我们将会重点分析请求的发送与接收、编解码、线程派发以及响应的发送与接收原创 2021-03-29 09:02:45 · 271 阅读 · 0 评论 -
Dubbo Consumer 发送请求
引言在 Dubbo 系列文章的最后,我们回过头来看一下整个 RPC 过程是如何运作起来的,本文着重介绍整个调用链路中 Consumer 发送请求的执行过程。消费方发送请求本节我们来看一下同步调用模式下,服务消费方是如何发送调用请求的。在深入分析源码前,我们先来看一张图。这张图展示了服务消费方发送请求过程的部分调用栈,略为复杂。从上图可以看出,经过多次调用后,才将请求数据送至 Netty NioClientSocketChannel。这样做的原因是通过 Exchange 层为框架引入 Request原创 2021-03-29 09:02:27 · 183 阅读 · 0 评论 -
Dubbo Provider 接收请求
引言在 Dubbo 系列文章的最后,我们回过头来看一下整个 RPC 过程是如何运作起来的,本文着重介绍整个调用链路中 Provider 接收请求的执行过程。提供方接收请求前面说过,默认情况下 Dubbo 使用 Netty 作为底层的通信框架。Netty 检测到有数据入站后,首先会通过解码器对数据进行解码,并将解码后的数据传递给下一个入站处理器的指定方法。所以在进行后续的分析之前,我们先来看一下数据解码过程。这里直接分析请求数据的解码逻辑,忽略中间过程,如下:public class Exchang原创 2021-03-29 09:02:16 · 346 阅读 · 0 评论 -
Dubbo Provider 返回结果
引言在 Dubbo 系列文章的最后,我们回过头来看一下整个 RPC 过程是如何运作起来的,本文着重介绍整个调用链路中 Provider 返回结果的执行过程。返回调用结果服务提供方调用指定服务后,会将调用结果封装到 Response 对象中,并将该对象返回给服务消费方。服务提供方也是通过 NettyChannel 的 send 方法将 Response 对象返回。本节我们仅需关注 Response 对象的编码过程即可,这里仍然省略一些中间调用,直接分析具体的编码逻辑。public class Exch原创 2021-03-29 09:01:57 · 386 阅读 · 0 评论 -
Dubbo Consumer 接收返回值
引言在 Dubbo 系列文章的最后,我们回过头来看一下整个 RPC 过程是如何运作起来的,本文着重介绍整个调用链路中 Consumer 接收返回值的执行过程。接收调用结果服务消费方在收到响应数据后,首先要做的事情是对响应数据进行解码,得到 Response 对象。然后再将该对象传递给下一个入站处理器,这个入站处理器就是 NettyHandler。接下来 NettyHandler 会将这个对象继续向下传递,最后 AllChannelHandler 的 received 方法会收到这个对象,并将这个对象派原创 2021-03-28 10:47:28 · 572 阅读 · 0 评论