You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@dubbo.apache.org by li...@apache.org on 2021/06/18 07:09:34 UTC
[dubbo-website] branch master updated: add 3.0 introduction doc
(#832)
This is an automated email from the ASF dual-hosted git repository.
liujun 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 18922c3 add 3.0 introduction doc (#832)
18922c3 is described below
commit 18922c3c718e710716deab9a9db995157ad43d16
Author: ken.lj <ke...@gmail.com>
AuthorDate: Fri Jun 18 15:09:28 2021 +0800
add 3.0 introduction doc (#832)
---
content/zh/docs/v2.7/user/examples/async-call.md | 2 +
content/zh/docs/v3.0/Introduction.md | 111 +++++++++++++++++----
content/zh/docs/v3.0/concepts/service-discovery.md | 13 ++-
content/zh/docs/v3.0/new-in-dubbo3.md | 10 ++
content/zh/docs/v3.0/references/_index.md | 2 +-
.../zh/docs/v3.0/references/features/async-call.md | 2 +
6 files changed, 117 insertions(+), 23 deletions(-)
diff --git a/content/zh/docs/v2.7/user/examples/async-call.md b/content/zh/docs/v2.7/user/examples/async-call.md
index ad5b120..85ebac6 100644
--- a/content/zh/docs/v2.7/user/examples/async-call.md
+++ b/content/zh/docs/v2.7/user/examples/async-call.md
@@ -101,6 +101,8 @@ public interface GreetingsService {
```
那还有一种方式，就是利用 Java 8 提供的 default 接口实现，重载一个带有 CompletableFuture 签名的方法。
+
+> CompletableFuture 签名的方法目前只支持 Dubbo 协议，其他协议由于第三方实现问题，需要视具体情况而定。
有两种方式来实现：
diff --git a/content/zh/docs/v3.0/Introduction.md b/content/zh/docs/v3.0/Introduction.md
index ad1c6f8..189676c 100644
--- a/content/zh/docs/v3.0/Introduction.md
+++ b/content/zh/docs/v3.0/Introduction.md
@@ -8,30 +8,107 @@ description: "这篇文档是关于 Dubbo 的简单介绍，涵盖 Dubbo 的核
---
Apache Dubbo 是一个款微服务开发框架，它提供了 RPC通信 与 微服务治理 两大关键能力。这意味着，使用 Dubbo 开发的微服务，将具备相互之间的远程发现与通信能力，
-同时利用 Dubbo 提供的丰富服务治理能力，实现诸如服务发现、负载均衡、流量调度等服务治理诉求。同时 Dubbo 是高度可扩展的，用户几乎可以在任意功能点去定制自己的实现，
-以改变框架的默认行为满足自己的业务需求。
+同时利用 Dubbo 提供的丰富服务治理能力，可以实现诸如服务发现、负载均衡、流量调度等服务治理诉求。同时 Dubbo 是高度可扩展的，用户几乎可以在任意功能点去定制自己的实现，以改变框架的默认行为来满足自己的业务需求。
-Dubbo 提供了丰富的多语言客户端实现，其中 Java、Golang 版本是目前稳定性、活跃度最好的版本，其他多语言客户端也在持续建设中。
+Dubbo3 基于 Dubbo2 演进而来，在保持原有核心功能特性的同时， Dubbo3 在易用性、超大规模微服务实践、云原生基础设施适配等几大方向上进行了全面升级。
+以下文档都将基于 Dubbo3 展开。
-
-## 简介
-
-## 核心概念
-Dubbo 提供的核心能力包括:
-* 服务定义
-* 服务远程通信
+## What Dubbo3 is
+如开篇所述，Dubbo 提供了构建云原生微服务业务的一站式解决方案，可以使用 Dubbo 快速定义并发布微服务组件，同时基于 Dubbo 开箱即用的丰富特性及超强的扩展能力，构建运维整个微服务体系所需的各项服务治理能力，如 Tracing、Transaction 等，Dubbo 提供的基础能力包括：
* 服务发现
+* 流式通信
* 负载均衡
-* 流量管理
-* 动态配置
+* 流量治理
+* .....
+
+Dubbo 计划提供丰富的多语言客户端实现，其中 Java、Golang 版本是当前稳定性、活跃度最好的版本，其他多语言客户端[]正在持续建设中。
+
+自开源以来，Dubbo 就被一众大规模互联网、IT公司选型，经过多年企业实践积累了大量经验。Dubbo3 是站在巨人肩膀上的下一代产品，它汲取了上一代的优点并针对已知问题做了大量优化，因此，Dubbo 在解决业务落地与规模化实践方面有着无可比拟的优势：
+* 开箱即用
+ * 易用性高，如 Java 版本的面向接口代理特性能实现本地透明调用
+ * 功能丰富，基于原生库或轻量扩展即可实现绝大多数的微服务治理能力
+* 超大规模微服务集群实践
+ * 高性能的跨进程通信协议
+ * 地址发现、流量治理层面，轻松支持百万规模集群实例
+* 企业级微服务治理能力
+ * 服务测试
+ * 服务Mock
+
+
+Dubbo3 是在云原生背景下诞生的，使用 Dubbo 构建的微服务遵循云原生思想，能更好的复用底层云原生基础设施、贴合云原生微服务架构。这体现在：
+* 服务支持部署在容器、Kubernetes平台，服务生命周期可实现与平台调度周期对齐；
+* 支持经典 Service Mesh 微服务架构，引入了 Proxyless Mesh 架构，进一步简化 Mesh 的落地与迁移成本，提供更灵活的选择；
+* 作为桥接层，支持与 SpringCloud、gRPC 等异构微服务体系的互调互通
+
+## 一站式微服务解决方案
+Dubbo 提供了从服务定义、服务发现、服务通信到流量管控等几乎所有的服务治理能力，并且尝试从使用上对用户屏蔽底层细节，以提供更好的易用性。
+
+定义服务在 Dubbo 中非常简单与直观，可以选择使用与某种语言绑定的方式（如 Java 中可直接定义 Interface），也可以使用 Protobuf IDL 语言中立的方式。无论选择哪种方式，站在服务消费方的视角，都可以通过 Dubbo 提供的透明代理直接编码。
+>需要注意的是，在 Dubbo 中，我们提到服务时，通常是指 RPC 粒度的、提供某个具体业务增删改功能的接口或方法，与一些微服务概念书籍中泛指的服务并不是一个概念。
+
+点对点的服务通信是 Dubbo 提供的另一项基本能力，Dubbo 以 RPC 的方式将请求数据（Request）发送给后端服务，并接收服务端返回的计算结果（Response）。RPC 通信对用户来说是完全透明的，使用者无需关心请求是如何发出去的、发到了哪里，每次调用只需要拿到正确的调用结果就行。同步的 Request-Response 是默认的通信模型，它最简单但却不能覆盖所有的场景，因此，Dubbo 提供更丰富的通信模型：
+* 消费端异步请求(Client Side Asynchronous Request-Response)
+* 提供端异步执行（Server Side Asynchronous Request-Response）
+* 消费端请求流（Request Streaming）
+* 提供端响应流（Response Streaming）
+* 双向流式通信（Bidirectional Streaming）
+
+Dubbo 的服务发现机制，让微服务组件之间可以独立演进并任意部署，消费端可以在无需感知对端部署位置与 IP 地址的情况下完成通信。Dubbo 提供的是 Client-Based 的服务发现机制，使用者可以有多种方式启用服务发现：
+* 使用独立的注册中心组件，如 Nacos、Zookeeper、Consul、Etcd 等。
+* 将服务的组织与注册交给底层容器平台，如 Kubernetes，这被理解是一种更云原生的方式
+
+透明地址发现让 Dubbo 请求可以被发送到任意 IP 实例上，这个过程中流量被随机分配。当需要对流量进行更丰富、更细粒度的管控时，就可以用到 Dubbo 的流量管控策略，Dubbo 提供了包括负载均衡、流量路由、请求超时、流量降级、重试等策略，基于这些基础能力可以轻松的实现更多场景化的路由方案，包括金丝雀发布、A/B测试、权重路由、同区域优先等，更酷的是，Dubbo 支持流控策略在运行态动态生效，无需重新部署。
+
+Dubbo 强大的服务治理能力不仅体现在核心框架上，还包括其优秀的扩展能力以及周边配套设施的支持。通过 Filter、Router、Protocol 等几乎存在于每一个关键流程上的扩展点定义，我们可以丰富 Dubbo 的功能或实现与其他微服务配套系统的对接，包括 Transaction、Tracing 目前都有通过 SPI 扩展的实现方案，具体可以参见 Dubbo 扩展性的详情，也可以在 apache/dubbo-spi-extensions 项目中发现与更多的扩展实现。
+
+## 大规模企业微服务实践沉淀
+Dubbo 最早诞生于阿里巴巴，随后加入 Apache 软件基金会，项目从设计之初就是为了解决企业的服务化问题，因此充分考虑了大规模集群场景下的服务开发与治理问题，如易用性、性能、流量管理、集群可伸缩性等。在 Dubbo 开源的将近 10 年时间内，Dubbo 几乎成为了国内微服务框架选型的首选框架，尤其受到大规模互联网、IT企业的认可，可以说作为开源服务框架，Dubbo 在支持微服务集群方面有着非常大的规模与非常久的实践经验积累，是最具有企业规模化微服务实践话语权的框架之一。采用 Dubbo 的企业涵盖互联网、传统IT、金融、生产制造业多个领域，一些典型用户包括阿里巴巴、携程、工商银行、中国人寿、海尔、金蝶等。
+
+在企业大规模实践的过程中，Dubbo 的稳定性得到了验证，服务治理的易用性与丰富度也在不断提升，而也就是在这样的背景下催生了下一代的产品 - Dubbo3。Dubbo3 的整个设计与开发过程，始终有来自社区团队与众多企业用户的共同参与，因此 Dubbo3 的许多核心架构与功能都充分考虑了大规模微服务实践诉求。阿里巴巴是参与在 Dubbo3 中的核心力量之一，作为企业用户其主导了该版本许多核心功能的设计与开发，阿里巴巴把 Dubbo3 社区版本确定为其未来内部主推的服务框架，并选择将内部 HSF 通过 Dubbo3 的形式贡献到开源社区，在阿里巴巴内部，众多业务线包括电商系统的考拉、交易平台，以及饿了么、钉钉等都已经成功迁移到 Dubbo3 版本。同样全程参与在 Dubbo3 开发与验证试点过程中的企业用户包括工商银行、携程、斗鱼、小米等。
+
+ Dubbo 的大规模实践经验主要体现在：
+ * 高性能通信
+ * 高可扩展性
+ * 超大规模集群实例水平扩展
+ * 丰富的服务治理能力
+
+ 关于 Dubbo 调用性能、支持超大规模集群地址方面的评测数据，将在随后发布，敬请期待。
+
+## 云原生友好
+
+Dubbo 从设计上是完全遵循云原生微服务开发理念的，这体现在多个方面，首先是对云原生基础设施与部署架构的支持，包括 Kubernetes、Service Mesh 等，另一方面，Dubbo 众多核心组件都已面向云原生升级，包括 Triple 协议、统一路由规则、对多语言支持。值得一提的是，如何使用 Dubbo 支持弹性伸缩的服务如 Serverless 也在未来计划之中，这包括利用 Native Image 提高 Dubbo 的启动速度与资源消耗等。
+
+结合当前版本，本节主要从以下两点展开 Dubbo 的云原生特性
+* 容器调度平台（Kubernetes）
+* Service Mesh
+
+### Kubernetes
+Dubbo 微服务要支持 Kubernetes 平台调度，最基础的就是实现 dubbo 服务生命周期与容器生命周期的对齐，这包括 Dubbo 的启动、销毁、服务注册等生命周期事件。相比于以往 Dubbo 自行定义生命周期事件，并要求开发人员在运维实践过程中遵守约定，Kubernetes 底层基础设施定义了严格的组件生命周期事件(probe)，转而要求 Dubbo 去按约定适配。
+
+Kubernetes Service 是另一个层面的适配，这体现了服务定义与注册向云原生底层基础设施下沉的趋势。在这种模式下，用户不再需要搭建额外的注册中心组件，Dubbo 消费端节点能自动对接到 Kubernetes（API-Server 或 DNS），根据服务名（Kubernetes Service Name） 查询到实例列表（Kubernetes endpoints）。 此时服务是通过标准的 Kubernetes Service API 定义，并被调度到各个节点。
+
+### Service Mesh
+
+Service Mesh 在业界得到了广泛的传播与认可，并被认为是下一代的微服务架构，这主要是因为它解决了很多棘手的问题，包括透明升级、多语言、依赖冲突、流量治理等。Service Mesh 的典型架构是通过部署独立的 Sidecar 组件来拦截所有的出口与入口流量，并在 Sidecar 中集成丰富的流量治理策略如负载均衡、路由等，除此之外，Service Mesh 还需要一个控制面（Control Plane）来实现对 Sidecar 流量的管控，即各种策略下发。我们在这里称这种架构为经典 Mesh。
+
+然而任何技术架构都不是完美的，经典 Mesh 在实施层面也面临成本过高的问题
+1. 需要运维控制面（Control Plane）
+2. 需要运维 Sidecar
+3. 需要考虑如何从原有 SDK 迁移到 Sidecar
+4. 需要考虑引入 Sidecar 后整个链路的性能损耗
+
+为了解决 Sidecar 引入的相关成本问题，Dubbo 引入了另一种变相的 Mesh 架构 - Proxyless Mesh，顾名思义，Proxyless Mesh 就是指没有 Sidecar 的部署，转而由 Dubbo SDK 直接与控制面交互，其架构图如下
+
+
+可以设想，在不同的组织、不同的发展阶段，未来以 Dubbo 构建的微服务将会允许有三种部署架构：传统 SDK、基于 Sidecar 的 Service Mesh、脱离 Sidecar 的 Proxyless Mesh。基于 Sidecar 的 Service Mesh，即经典的 Mesh 架构，独立的 sidecar 运行时接管所有的流量，脱离 Sidecar 的 Proxyless Mesh，富 SDK 直接通过 xDS 与控制面通信。Dubbo 微服务允许部署在物理机、容器、Kubernetes 平台之上，能做到以 Admin 为控制面，以统一的流量治理规则进行治理。
+
-以下是对一些关键概念的简单介绍。
+## 了解更多
-服务定义
+What's New in Dubbo3
-服务定义
+体验 Dubbo3
-服务定义
-## Dubbo3 vs Dubbo2
+迁移到 Dubbo3
diff --git a/content/zh/docs/v3.0/concepts/service-discovery.md b/content/zh/docs/v3.0/concepts/service-discovery.md
index 495427b..f14c88b 100644
--- a/content/zh/docs/v3.0/concepts/service-discovery.md
+++ b/content/zh/docs/v3.0/concepts/service-discovery.md
@@ -5,7 +5,11 @@ linkTitle: "服务发现"
weight: 1
description: "服务发现"
---
-服务发现，即消费端自动发现服务之地列表的能力，是微服务框架需要具备的关键能力。Dubbo 提供了基于消费端的自动服务发现能力，其基本工作原理如下图：
+服务发现，即消费端自动发现服务之地列表的能力，是微服务框架需要具备的关键能力，借助于自动化的服务发现，微服务之间可以在无需感知对端部署位置与 IP 地址的情况下实现通信。
+
+实现服务发现的方式有很多种，Dubbo 提供的是一种 Client-Based 的服务发现机制，通常还需要部署额外的第三方注册中心组件来协调服务发现过程，如常用的 Nacos、Consul、Zookeeper 等，Dubbo 自身也提供了对多种注册中心组件的对接，用户可以灵活选择。
+
+Dubbo 基于消费端的自动服务发现能力，其基本工作原理如下图：
@@ -21,7 +25,7 @@ dubbo
address: zookeeper://127.0.0.1:2181
```
-## 服务发现（Dubbo3 vs Dubbo2）
+## What's New in Dubbo3
就使用方式上而言，Dubbo3 与 Dubbo2 的服务发现配置是完全一致的，不需要改动什么内容。但就实现原理上而言，Dubbo3 引入了全新的服务发现模型 - 应用级服务发现，
在工作原理、数据格式上已完全不能兼容老版本服务发现。
@@ -33,11 +37,10 @@ Dubbo3 格式的 Provider 地址不能被 Dubbo2 的 Consumer 识别到，反之
* 对于老用户，要面临如何平滑迁移到应用级服务发现的问题，考虑到老用户的规则如此之大，Dubbo3 默认保持了接口级地址发现的行为，这保证了老用户可以直接无感升级到 Dubbo3。
而如果要开启应用级服务发现，则需要通过配置显示开启（双注册、双订阅），具体开启与平滑迁移过程，可参见《migration/地址发现迁移指南》。
-## 应用级服务发现
+## 应用级服务发现简介
概括来说，Dubbo3 引入的应用级服务发现主要有以下优势
* 适配云原生微服务变革。云原生时代的基础设施能力不断向上释放，像 Kubernetes 等平台都集成了微服务概念抽象，Dubbo3 的应用级服务发现是适配各种微服务体系的通用模型。
-* 提升性能与可伸缩性。支持超大规模集群的服务治理一直以来都是 Dubbo 的优势，通过引入应用级服务发现模型，从本质上解决了注册中心地址数据的存储与推送压力，相应的 Consumer 侧的地址计算压力也成数量级下降；
- 集群规模也开始变得可预测、可评估（与 RPC 接口数量无关，只与实例部署规模相关）。
+* 提升性能与可伸缩性。支持超大规模集群的服务治理一直以来都是 Dubbo 的优势，通过引入应用级服务发现模型，从本质上解决了注册中心地址数据的存储与推送压力，相应的 Consumer 侧的地址计算压力也成数量级下降；集群规模也开始变得可预测、可评估（与 RPC 接口数量无关，只与实例部署规模相关）。
下图是 Dubbo2 的服务发现模型：Provider 注册服务地址，Consumer 经过注册中心协调并发现服务地址，进而对地址发起通信，这是被绝大多数微服务框架的经典服务发现流程。而 Dubbo2 的特殊之处在于，它把 “RPC 接口”的信息也融合在了地址发现过程中，而这部分信息往往是和具体的业务定义密切相关的。
diff --git a/content/zh/docs/v3.0/new-in-dubbo3.md b/content/zh/docs/v3.0/new-in-dubbo3.md
new file mode 100644
index 0000000..4275905
--- /dev/null
+++ b/content/zh/docs/v3.0/new-in-dubbo3.md
@@ -0,0 +1,10 @@
+---
+type: docs
+title: "What's New in Dubbo3"
+linkTitle: "Dubbo3"
+weight: 2
+description: "Dubbo3 对比之前版本的变化。"
+---
+
+
+
diff --git a/content/zh/docs/v3.0/references/_index.md b/content/zh/docs/v3.0/references/_index.md
index 9ea05a6..f6b36b1 100755
--- a/content/zh/docs/v3.0/references/_index.md
+++ b/content/zh/docs/v3.0/references/_index.md
@@ -2,6 +2,6 @@
type: docs
title: "参考手册"
linkTitle: "参考手册"
-weight: 10
+weight: 70
description: "Dubbo 中已经实现的扩展"
---
diff --git a/content/zh/docs/v3.0/references/features/async-call.md b/content/zh/docs/v3.0/references/features/async-call.md
index ad5b120..85ebac6 100644
--- a/content/zh/docs/v3.0/references/features/async-call.md
+++ b/content/zh/docs/v3.0/references/features/async-call.md
@@ -101,6 +101,8 @@ public interface GreetingsService {
```
那还有一种方式，就是利用 Java 8 提供的 default 接口实现，重载一个带有 CompletableFuture 签名的方法。
+
+> CompletableFuture 签名的方法目前只支持 Dubbo 协议，其他协议由于第三方实现问题，需要视具体情况而定。
有两种方式来实现：