You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@dubbo.apache.org by al...@apache.org on 2022/07/18 07:02:39 UTC
[dubbo-website] branch master updated: Update docs in arch (#1249)
This is an automated email from the ASF dual-hosted git repository.
albumenj pushed a commit to branch master
in repository https://gitbox.apache.org/repos/asf/dubbo-website.git
The following commit(s) were added to refs/heads/master by this push:
new 1dfe82d204 Update docs in arch (#1249)
1dfe82d204 is described below
commit 1dfe82d204523a7d166d189ef593ce4f7e48ecdf
Author: Albumen Kevin <jh...@gmail.com>
AuthorDate: Mon Jul 18 15:02:34 2022 +0800
Update docs in arch (#1249)
* Add arch docs
* add service-invocation
---
.../concepts-and-architecture/code-architecture.md | 105 ++++++++++++++
.../overall-architecture.md | 65 ++++++++-
.../concepts-and-architecture/service-discovery.md | 18 +--
.../service-invocation.md | 153 ++++++++++++++++++++-
static/imgs/v3/concepts/filter-arch.jpg | Bin 0 -> 193805 bytes
static/imgs/v3/concepts/invoke-arch.jpg | Bin 0 -> 121885 bytes
6 files changed, 318 insertions(+), 23 deletions(-)
diff --git a/content/zh/docs3-building/java-sdk/concepts-and-architecture/code-architecture.md b/content/zh/docs3-building/java-sdk/concepts-and-architecture/code-architecture.md
new file mode 100644
index 0000000000..87bbead1d9
--- /dev/null
+++ b/content/zh/docs3-building/java-sdk/concepts-and-architecture/code-architecture.md
@@ -0,0 +1,105 @@
+---
+type: docs
+title: "代码架构"
+linkTitle: "代码架构"
+weight: 2
+---
+
+
+## 整体设计
+
+
+
+图例说明：
+
+* 图中左边淡蓝背景的为服务消费方使用的接口，右边淡绿色背景的为服务提供方使用的接口，位于中轴线上的为双方都用到的接口。
+* 图中从下至上分为十层，各层均为单向依赖，右边的黑色箭头代表层之间的依赖关系，每一层都可以剥离上层被复用，其中，Service 和 Config 层为 API，其它各层均为 SPI。
+* 图中绿色小块的为扩展接口，蓝色小块为实现类，图中只显示用于关联各层的实现类。
+* 图中蓝色虚线为初始化过程，即启动时组装链，红色实线为方法调用过程，即运行时调时链，紫色三角箭头为继承，可以把子类看作父类的同一个节点，线上的文字为调用的方法。
+
+## 各层说明
+
+* **config 配置层**：对外配置接口，以 `ServiceConfig`, `ReferenceConfig` 为中心，可以直接初始化配置类，也可以通过 spring 解析配置生成配置类
+* **proxy 服务代理层**：服务接口透明代理，生成服务的客户端 Stub 和服务器端 Skeleton, 以 `ServiceProxy` 为中心，扩展接口为 `ProxyFactory`
+* **registry 注册中心层**：封装服务地址的注册与发现，以服务 URL 为中心，扩展接口为 `RegistryFactory`, `Registry`, `RegistryService`
+* **cluster 路由层**：封装多个提供者的路由及负载均衡，并桥接注册中心，以 `Invoker` 为中心，扩展接口为 `Cluster`, `Directory`, `Router`, `LoadBalance`
+* **monitor 监控层**：RPC 调用次数和调用时间监控，以 `Statistics` 为中心，扩展接口为 `MonitorFactory`, `Monitor`, `MonitorService`
+* **protocol 远程调用层**：封装 RPC 调用，以 `Invocation`, `Result` 为中心，扩展接口为 `Protocol`, `Invoker`, `Exporter`
+* **exchange 信息交换层**：封装请求响应模式，同步转异步，以 `Request`, `Response` 为中心，扩展接口为 `Exchanger`, `ExchangeChannel`, `ExchangeClient`, `ExchangeServer`
+* **transport 网络传输层**：抽象 mina 和 netty 为统一接口，以 `Message` 为中心，扩展接口为 `Channel`, `Transporter`, `Client`, `Server`, `Codec`
+* **serialize 数据序列化层**：可复用的一些工具，扩展接口为 `Serialization`, `ObjectInput`, `ObjectOutput`, `ThreadPool`
+
+## 关系说明
+
+* 在 RPC 中，Protocol 是核心层，也就是只要有 Protocol + Invoker + Exporter 就可以完成非透明的 RPC 调用，然后在 Invoker 的主过程上 Filter 拦截点。
+* 图中的 Consumer 和 Provider 是抽象概念，只是想让看图者更直观的了解哪些类分属于客户端与服务器端，不用 Client 和 Server 的原因是 Dubbo 在很多场景下都使用 Provider, Consumer, Registry, Monitor 划分逻辑拓扑节点，保持统一概念。
+* 而 Cluster 是外围概念，所以 Cluster 的目的是将多个 Invoker 伪装成一个 Invoker，这样其它人只要关注 Protocol 层 Invoker 即可，加上 Cluster 或者去掉 Cluster 对其它层都不会造成影响，因为只有一个提供者时，是不需要 Cluster 的。
+* Proxy 层封装了所有接口的透明化代理，而在其它层都以 Invoker 为中心，只有到了暴露给用户使用时，才用 Proxy 将 Invoker 转成接口，或将接口实现转成 Invoker，也就是去掉 Proxy 层 RPC 是可以 Run 的，只是不那么透明，不那么看起来像调本地服务一样调远程服务。
+* 而 Remoting 实现是 Dubbo 协议的实现，如果你选择 RMI 协议，整个 Remoting 都不会用上，Remoting 内部再划为 Transport 传输层和 Exchange 信息交换层，Transport 层只负责单向消息传输，是对 Mina, Netty, Grizzly 的抽象，它也可以扩展 UDP 传输，而 Exchange 层是在传输层之上封装了 Request-Response 语义。
+* Registry 和 Monitor 实际上不算一层，而是一个独立的节点，只是为了全局概览，用层的方式画在一起。
+
+## 模块分包
+
+
+
+模块说明：
+
+* **dubbo-common 公共逻辑模块**：包括 Util 类和通用模型。
+* **dubbo-remoting 远程通讯模块**：相当于 Dubbo 协议的实现，如果 RPC 用 RMI协议则不需要使用此包。
+* **dubbo-rpc 远程调用模块**：抽象各种协议，以及动态代理，只包含一对一的调用，不关心集群的管理。
+* **dubbo-cluster 集群模块**：将多个服务提供方伪装为一个提供方，包括：负载均衡, 容错，路由等，集群的地址列表可以是静态配置的，也可以是由注册中心下发。
+* **dubbo-registry 注册中心模块**：基于注册中心下发地址的集群方式，以及对各种注册中心的抽象。
+* **dubbo-monitor 监控模块**：统计服务调用次数，调用时间的，调用链跟踪的服务。
+* **dubbo-config 配置模块**：是 Dubbo 对外的 API，用户通过 Config 使用Dubbo，隐藏 Dubbo 所有细节。
+* **dubbo-container 容器模块**：是一个 Standlone 的容器，以简单的 Main 加载 Spring 启动，因为服务通常不需要 Tomcat/JBoss 等 Web 容器的特性，没必要用 Web 容器去加载服务。
+
+整体上按照分层结构进行分包，与分层的不同点在于：
+
+* container 为服务容器，用于部署运行服务，没有在层中画出。
+* protocol 层和 proxy 层都放在 rpc 模块中，这两层是 rpc 的核心，在不需要集群也就是只有一个提供者时，可以只使用这两层完成 rpc 调用。
+* transport 层和 exchange 层都放在 remoting 模块中，为 rpc 调用的通讯基础。
+* serialize 层放在 common 模块中，以便更大程度复用。
+
+## 依赖关系
+
+
+
+图例说明：
+
+* 图中小方块 Protocol, Cluster, Proxy, Service, Container, Registry, Monitor 代表层或模块，蓝色的表示与业务有交互，绿色的表示只对 Dubbo 内部交互。
+* 图中背景方块 Consumer, Provider, Registry, Monitor 代表部署逻辑拓扑节点。
+* 图中蓝色虚线为初始化时调用，红色虚线为运行时异步调用，红色实线为运行时同步调用。
+* 图中只包含 RPC 的层，不包含 Remoting 的层，Remoting 整体都隐含在 Protocol 中。
+
+## 调用链
+
+展开总设计图的红色调用链，如下：
+
+
+
+## 暴露服务时序
+
+展开总设计图右边服务提供方暴露服务的蓝色初始化链，时序图如下：
+
+
+
+## 引用服务时序
+
+展开总设计图左边服务消费方引用服务的绿色初始化链，时序图如下：
+
+
+
+## 领域模型
+
+在 Dubbo 的核心领域模型中：
+
+* Protocol 是服务域，它是 Invoker 暴露和引用的主功能入口，它负责 Invoker 的生命周期管理。
+* Invoker 是实体域，它是 Dubbo 的核心模型，其它模型都向它靠扰，或转换成它，它代表一个可执行体，可向它发起 invoke 调用，它有可能是一个本地的实现，也可能是一个远程的实现，也可能一个集群实现。
+* Invocation 是会话域，它持有调用过程中的变量，比如方法名，参数等。
+
+## 基本设计原则
+
+* 采用 Microkernel + Plugin 模式，Microkernel 只负责组装 Plugin，Dubbo 自身的功能也是通过扩展点实现的，也就是 Dubbo 的所有功能点都可被用户自定义扩展所替换。
+* 采用 URL 作为配置信息的统一格式，所有扩展点都通过传递 URL 携带配置信息。
+
+更多设计原则参见：[框架设计原则](../principals/)
diff --git a/content/zh/docs3-building/java-sdk/concepts-and-architecture/overall-architecture.md b/content/zh/docs3-building/java-sdk/concepts-and-architecture/overall-architecture.md
index 540ed7d024..fdaa476f1a 100644
--- a/content/zh/docs3-building/java-sdk/concepts-and-architecture/overall-architecture.md
+++ b/content/zh/docs3-building/java-sdk/concepts-and-architecture/overall-architecture.md
@@ -5,7 +5,68 @@ linkTitle: "总体架构"
weight: 1
---
-### 总体架构图
+
-### 消费端调用原理（选址等）
+##### 节点角色说明
+
+| 节点 | 角色说明 |
+| ------------- | ------------- |
+| `Provider` | 暴露服务的服务提供方 |
+| `Consumer` | 调用远程服务的服务消费方 |
+| `Registry` | 服务注册与发现的注册中心 |
+| `Monitor` | 统计服务的调用次数和调用时间的监控中心 |
+| `Container` | 服务运行容器 |
+
+##### 调用关系说明
+
+0. 服务容器负责启动，加载，运行服务提供者。
+1. 服务提供者在启动时，向注册中心注册自己提供的服务。
+2. 服务消费者在启动时，向注册中心订阅自己所需的服务。
+3. 注册中心返回服务提供者地址列表给消费者，如果有变更，注册中心将基于长连接推送变更数据给消费者。
+4. 服务消费者，从提供者地址列表中，基于软负载均衡算法，选一台提供者进行调用，如果调用失败，再选另一台调用。
+5. 服务消费者和提供者，在内存中累计调用次数和调用时间，定时每分钟发送一次统计数据到监控中心。
+
+Dubbo 架构具有以下几个特点，分别是连通性、健壮性、伸缩性、以及向未来架构的升级性。
+
+## 连通性
+
+* 注册中心负责服务地址的注册与查找，相当于目录服务，服务提供者和消费者只在启动时与注册中心交互，注册中心不转发请求，压力较小
+* 监控中心负责统计各服务调用次数，调用时间等，统计先在内存汇总后每分钟一次发送到监控中心服务器，并以报表展示
+* 服务提供者向注册中心注册其提供的服务，并汇报调用时间到监控中心，此时间不包含网络开销
+* 服务消费者向注册中心获取服务提供者地址列表，并根据负载算法直接调用提供者，同时汇报调用时间到监控中心，此时间包含网络开销
+* 注册中心，服务提供者，服务消费者三者之间均为长连接，监控中心除外
+* 注册中心通过长连接感知服务提供者的存在，服务提供者宕机，注册中心将立即推送事件通知消费者
+* 注册中心和监控中心全部宕机，不影响已运行的提供者和消费者，消费者在本地缓存了提供者列表
+* 注册中心和监控中心都是可选的，服务消费者可以直连服务提供者
+
+## 健壮性
+
+* 监控中心宕掉不影响使用，只是丢失部分采样数据
+* 数据库宕掉后，注册中心仍能通过缓存提供服务列表查询，但不能注册新服务
+* 注册中心对等集群，任意一台宕掉后，将自动切换到另一台
+* 注册中心全部宕掉后，服务提供者和服务消费者仍能通过本地缓存通讯
+* 服务提供者无状态，任意一台宕掉后，不影响使用
+* 服务提供者全部宕掉后，服务消费者应用将无法使用，并无限次重连等待服务提供者恢复
+
+## 伸缩性
+
+* 注册中心为对等集群，可动态增加机器部署实例，所有客户端将自动发现新的注册中心
+* 服务提供者无状态，可动态增加机器部署实例，注册中心将推送新的服务提供者信息给消费者
+
+## 升级性
+
+当服务集群规模进一步扩大，带动IT治理结构进一步升级，需要实现动态部署，进行流动计算，现有分布式服务架构不会带来阻力。下图是未来可能的一种架构：
+
+
+
+##### 节点角色说明
+
+| 节点 | 角色说明 |
+| ------------- | ------------- |
+| `Deployer ` | 自动部署服务的本地代理 |
+| `Repository` | 仓库用于存储服务应用发布包 |
+| `Scheduler` | 调度中心基于访问压力自动增减服务提供者 |
+| `Admin` | 统一管理控制台 |
+| `Registry` | 服务注册与发现的注册中心 |
+| `Monitor` | 统计服务的调用次数和调用时间的监控中心 |
\ No newline at end of file
diff --git a/content/zh/docs3-building/java-sdk/concepts-and-architecture/service-discovery.md b/content/zh/docs3-building/java-sdk/concepts-and-architecture/service-discovery.md
index 866f2edcbb..53dbd401b1 100644
--- a/content/zh/docs3-building/java-sdk/concepts-and-architecture/service-discovery.md
+++ b/content/zh/docs3-building/java-sdk/concepts-and-architecture/service-discovery.md
@@ -2,7 +2,7 @@
type: docs
title: "服务发现"
linkTitle: "服务发现"
-weight: 2
+weight: 3
---
服务发现，即消费端自动发现服务地址列表的能力，是微服务框架需要具备的关键能力，借助于自动化的服务发现，微服务之间可以在无需感知对端部署位置与 IP 地址的情况下实现通信。
@@ -24,18 +24,6 @@ dubbo
address: zookeeper://127.0.0.1:2181
```
-## What's New in Dubbo3
-就使用方式上而言，Dubbo3 与 Dubbo2 的服务发现配置是完全一致的，不需要改动什么内容。但就实现原理上而言，Dubbo3 引入了全新的服务发现模型 - 应用级服务发现，
-在工作原理、数据格式上已完全不能兼容老版本服务发现。
-
-* Dubbo3 应用级服务发现，以应用粒度组织地址数据
-* Dubbo2 接口级服务发现，以接口粒度组织地址数据
-
-Dubbo3 格式的 Provider 地址不能被 Dubbo2 的 Consumer 识别到，反之 Dubbo2 的消费者也不能订阅到 Dubbo3 Provider。
-* 对于新用户，我们提倡直接启用 Dubbo3 的默认行为，即启用应用级服务发现，参见《[应用级服务发现](../../../java-sdk/upgrades-and-compatibility/service-discovery#应用级服务发现)》；
-* 对于老用户，要面临如何平滑迁移到应用级服务发现的问题，考虑到老用户的规模如此之大，Dubbo3 默认保持了接口级地址发现的行为，这保证了老用户可以直接无感升级到 Dubbo3。
-而如果要开启应用级服务发现，则需要通过配置显示开启（双注册、双订阅），具体开启与平滑迁移过程，可参见《[地址发现迁移指南](../../../java-sdk/upgrades-and-compatibility/service-discovery/service-discovery-samples#应用级服务发现迁移示例)》。
-
## 应用级服务发现简介
概括来说，Dubbo3 引入的应用级服务发现主要有以下优势
* 适配云原生微服务变革。云原生时代的基础设施能力不断向上释放，像 Kubernetes 等平台都集成了微服务概念抽象，Dubbo3 的应用级服务发现是适配各种微服务体系的通用模型。
@@ -66,6 +54,4 @@ Dubbo3 服务发现模型更适合构建可伸缩的服务体系，这点要如
对于 Dubbo3 来说，新的注册发现模型只需要 1 个服务（只和应用有关和接口无关）， 只注册和机器实例数相等的 1 * 100 = 100 个虚拟节点到注册中心。
在这个简单的示例中，Dubbo 所注册的地址数量下降到了原来的 1 / 100，对于注册中心、订阅方的存储压力都是一个极大的释放。更重要的是，
地址发现容量彻底与业务 RPC 定义解耦开来，整个集群的容量评估对运维来说将变得更加透明：部署多少台机器就会有多大负载，不会像 Dubbo2 一样，
-因为业务 RPC 重构就会影响到整个集群服务发现的稳定性。
-
-请通过以下 blog 了解更多应用级服务发现设计原则细节。
+因为业务 RPC 重构就会影响到整个集群服务发现的稳定性。
\ No newline at end of file
diff --git a/content/zh/docs3-building/java-sdk/concepts-and-architecture/service-invocation.md b/content/zh/docs3-building/java-sdk/concepts-and-architecture/service-invocation.md
index 9426206f6b..4399756b1a 100644
--- a/content/zh/docs3-building/java-sdk/concepts-and-architecture/service-invocation.md
+++ b/content/zh/docs3-building/java-sdk/concepts-and-architecture/service-invocation.md
@@ -1,13 +1,156 @@
---
type: docs
-title: "服务调用"
+title: "服务调用扩展点"
linkTitle: "服务调用"
-weight: 3
+weight: 4
+description: "本文将介绍如何 Dubbo 3 中自定义扩展调用链路上核心的扩展点以满足您的需求。"
---
+
-Filter
+如上图所示，从服务调用的角度来看，Dubbo 在链路中提供了丰富的扩展点，覆盖了负载均衡方式、选址前后的拦截器、服务端处理拦截器等。
+简单来说 Dubbo 发起远程调用的时候，主要工作流程可以分为消费端和服务端两个部分。
-Router
+消费端的工作流程如下：
+- 通过 Stub 接收来自用户的请求，并且封装在 `Invocation` 对象中
+- 将 `Invocation` 对象传递给 `ClusterFilter`（**扩展点**）做选址前的请求预处理，如请求参数的转换、请求日志记录、限流等操作都是在此阶段进行的
+- 将 `Invocation` 对象传递给 `Cluster`（**扩展点**）进行集群调用逻辑的决策，如快速失败模式、安全失败模式等决策都是在此阶段进行的
+ - `Cluster` 调用 `Directory` 获取所有可用的服务端地址信息
+ - `Directory` 调用 `StateRouter`（**扩展点**，推荐使用） 和 `Router`（**扩展点**） 对服务端的地址信息进行路由筛选，此阶段主要是从全量的地址信息中筛选出本次调用允许调用到的目标，如基于打标的流量路由就是在此阶段进行的
+ - `Cluster` 获得从 `Directory` 提供的可用服务端信息后，会调用 `LoadBalance` （**扩展点**）从多个地址中选择出一个本次调用的目标，如随机调用、轮询调用、一致性哈希等策略都是在此阶段进行的
+ - `Cluster` 获得目标的 `Invoker` 以后将 `Invocation` 传递给对应的 `Invoker`，并等待返回结果，如果出现报错则执行对应的决策（如快速失败、安全失败等）
+- 经过上面的处理，得到了带有目标地址信息的 `Invoker`，会再调用 `Filter`（**扩展点**）进行选址后的请求处理（由于在消费端侧创建的 `Filter` 数量级和服务端地址量级一致，如无特殊需要建议使用 `ClusterFilter` 进行扩展拦截，以提高性能）
+- 最后 `Invocation` 会被通过网络发送给服务端
+
+服务端的工作流程如下：
+- 服务端通信层收到请求以后，会将请求传递给协议层构建出 `Invocation`
+- 将 `Invocation` 对象传递给 `Filter` （**扩展点**）做服务端请求的预处理，如服务端鉴权、日志记录、限流等操作都是在此阶段进行的
+- 将 `Invocation` 对象传递给动态代理做真实的服务端调用
+
+## Filter（拦截器）
+
+拦截器可以实现服务提供方和服务消费方调用过程拦截，Dubbo 本身的大多功能均基于此扩展点实现，每次远程方法执行，该拦截都会被执行，请注意对性能的影响。
+其中在消费端侧，`ClusterFilter` 用于选址前的拦截和 `Filter` 用于选址后的拦截。如无特殊需要使用 `ClusterFilter` 进行扩展拦截，以提高性能。
+
+
+
+在 Dubbo 3 中，`Filter` 和 `ClusterFilter` 的接口签名被统一抽象到 `BaseFilter` 中，开发者可以分别实现 `Filter` 或 `ClusterFilter` 的接口来实现自己的拦截器。
+如果需要拦截返回状态，可以直接实现 `BaseFilter.Listener` 的接口，Dubbo 将自动识别，并进行调用。
+
+```java
+package org.apache.dubbo.rpc;
+
+public interface BaseFilter {
+
+ Result invoke(Invoker<?> invoker, Invocation invocation) throws RpcException;
+
+ interface Listener {
+
+ void onResponse(Result appResponse, Invoker<?> invoker, Invocation invocation);
+
+ void onError(Throwable t, Invoker<?> invoker, Invocation invocation);
+ }
+}
+```
+
+```java
+package org.apache.dubbo.rpc;
+
+@SPI(scope = ExtensionScope.MODULE)
+public interface Filter extends BaseFilter {
+}
+```
+
+```java
+package org.apache.dubbo.rpc.cluster.filter;
+
+@SPI(scope = ExtensionScope.MODULE)
+public interface ClusterFilter extends BaseFilter {
+}
+```
+
+特别的，如果需要在 Consumer 侧生效 `Filter` 或 `ClusterFilter`，需要增加 `@Activate` 注解，并且需要指定 `group` 的值为 `consumer`。
+
+```java
+@Activate(group = CommonConstants.CONSUMER)
+```
+
+如果需要在 Consumer 侧生效 `Filter` 或 `ClusterFilter`，需要增加 `@Activate` 注解，并且需要指定 `group` 的值为 `provider`。
+
+```java
+@Activate(group = CommonConstants.PROVIDER)
+```
+
+具体调用拦截扩展方式请[参考](../../reference-manual/spi/description/filter/)
+
+## Router（路由选址）
+
+路由选址提供从多个服务提供方中选择**一批**满足条件的目标提供方进行调用的能力。
+Dubbo 的路由主要需要实现 3 个接口，分别是负责每次调用筛选的 `route` 方法，负责地址推送后缓存的 `notify` 方法，以及销毁路由的 `stop` 方法。
+在 Dubbo 3 中推荐实现 `StateRouter` 接口，能够提供高性能的路由选址方式。
+
+```java
+package org.apache.dubbo.rpc.cluster.router.state;
+
+public interface StateRouter<T> {
+
+ BitList<Invoker<T>> route(BitList<Invoker<T>> invokers, URL url, Invocation invocation,
+ boolean needToPrintMessage, Holder<RouterSnapshotNode<T>> nodeHolder) throws RpcException;
+
+ void notify(BitList<Invoker<T>> invokers);
+
+ void stop();
+}
+```
+
+```java
+package org.apache.dubbo.rpc.cluster;
+
+public interface Router extends Comparable<Router> {
+
+ @Deprecated
+ List<Invoker<T>> route(List<Invoker<T>> invokers, URL url, Invocation invocation) throws RpcException;
+
+ <T> RouterResult<Invoker<T>> route(List<Invoker<T>> invokers, URL url, Invocation invocation,
+ boolean needToPrintMessage) throws RpcException;
+
+ <T> void notify(List<Invoker<T>> invokers);
+
+ void stop();
+}
+```
+
+具体路由选址扩展方式请[参考](../../reference-manual/spi/description/router/)
+
+## Cluster（集群规则）
+
+集群规则提供在有多个服务提供方时进行结果聚合、容错等能力。
+
+```java
+package org.apache.dubbo.rpc.cluster.support;
+
+public abstract class AbstractClusterInvoker<T> implements ClusterInvoker<T> {
+
+ protected abstract Result doInvoke(Invocation invocation, List<Invoker<T>> invokers,
+ LoadBalance loadbalance) throws RpcException;
+}
+```
+
+
+具体集群规则扩展方式请[参考](../../reference-manual/spi/description/cluster/)
+
+## LoadBalance（负载均衡）
+
+负载均衡提供从多个服务提供方中选择**一个**目标提供方进行调用的能力。
+
+```java
+package org.apache.dubbo.rpc.cluster;
+
+public interface LoadBalance {
+
+ <T> Invoker<T> select(List<Invoker<T>> invokers, URL url, Invocation invocation) throws RpcException;
+}
+```
+
+具体调用拦截扩展方式请[参考](../../reference-manual/spi/description/load-balance/)
-LoadBalance
\ No newline at end of file
diff --git a/static/imgs/v3/concepts/filter-arch.jpg b/static/imgs/v3/concepts/filter-arch.jpg
new file mode 100644
index 0000000000..95af47c879
Binary files /dev/null and b/static/imgs/v3/concepts/filter-arch.jpg differ
diff --git a/static/imgs/v3/concepts/invoke-arch.jpg b/static/imgs/v3/concepts/invoke-arch.jpg
new file mode 100644
index 0000000000..ee2ef4b9ff
Binary files /dev/null and b/static/imgs/v3/concepts/invoke-arch.jpg differ