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 994073c 3.0 docs content (#818)
994073c is described below
commit 994073c91cdf781a842f80687151ea75474dd608
Author: ken.lj <[email protected]>
AuthorDate: Thu Jun 3 14:56:51 2021 +0800
3.0 docs content (#818)
---
content/en/downloads/_index.md | 16 +
content/zh/blog/news/v3-service-discovery.md | 360 +++++++++++++++++++++
content/zh/docs/v3.0/Introduction.md | 39 +++
content/zh/docs/v3.0/_index.md | 2 +-
content/zh/docs/v3.0/advanced/_index.md | 9 +
content/zh/docs/v3.0/concepts/configuration.md | 7 +
content/zh/docs/v3.0/concepts/extensibility.md | 7 +
.../concepts/registry-configcenter-metadata.md | 39 +++
content/zh/docs/v3.0/concepts/rpc-protocol.md | 16 +
content/zh/docs/v3.0/concepts/service-discovery.md | 70 ++++
.../zh/docs/v3.0/concepts/traffic-management.md | 9 +
content/zh/docs/v3.0/examples/_index.md | 10 +-
content/zh/docs/v3.0/examples/quick-start.md | 16 +
content/zh/docs/v3.0/migration/_index.md | 2 +-
content/zh/docs/v3.0/references/_index.md | 2 +-
static/imgs/blog/servicediscovery/arc.png | Bin 0 -> 152651 bytes
static/imgs/blog/servicediscovery/centers.png | Bin 0 -> 219313 bytes
static/imgs/blog/servicediscovery/meta.png | Bin 0 -> 131472 bytes
.../imgs/blog/servicediscovery/metadatacenter.png | Bin 0 -> 64175 bytes
.../imgs/blog/servicediscovery/metadataservice.png | Bin 0 -> 20057 bytes
static/imgs/blog/servicediscovery/rpc-dubbo.png | Bin 0 -> 46055 bytes
static/imgs/blog/servicediscovery/rpc-k8s.png | Bin 0 -> 359553 bytes
static/imgs/blog/servicediscovery/rpc-sc.png | Bin 0 -> 41557 bytes
static/imgs/blog/servicediscovery/rpc.png | Bin 0 -> 26796 bytes
static/imgs/blog/servicediscovery/rpc1.png | Bin 0 -> 41557 bytes
.../servicediscovery/servicediscovery-perf.png | Bin 0 -> 389833 bytes
static/imgs/blog/servicediscovery/workflow.png | Bin 0 -> 226611 bytes
static/imgs/v3/concepts/centers-config.png | Bin 0 -> 103809 bytes
static/imgs/v3/concepts/centers-metadata.png | Bin 0 -> 106862 bytes
static/imgs/v3/concepts/centers-registry.png | Bin 0 -> 101211 bytes
static/imgs/v3/concepts/servicediscovery_k8s.png | Bin 0 -> 170454 bytes
static/imgs/v3/concepts/servicediscovery_mem.png | Bin 0 -> 581805 bytes
static/imgs/v3/concepts/servicediscovery_old.png | Bin 0 -> 188631 bytes
static/imgs/v3/concepts/threecenters.png | Bin 0 -> 113151 bytes
34 files changed, 595 insertions(+), 9 deletions(-)
diff --git a/content/en/downloads/_index.md b/content/en/downloads/_index.md
new file mode 100644
index 0000000..7638667
--- /dev/null
+++ b/content/en/downloads/_index.md
@@ -0,0 +1,16 @@
+---
+title: Downloads
+menu:
+ main:
+ weight: 50
+---
+
+<!--add blocks of content here to add more sections to the community page -->
+{{% blocks/lead %}}
+You may consider contributing more to the following side projects of Apache
Dubbo:
+{{% /blocks/lead %}}
+
+{{< blocks/section color="white" height="auto">}}
+
+{{< /blocks/section >}}
+
diff --git a/content/zh/blog/news/v3-service-discovery.md
b/content/zh/blog/news/v3-service-discovery.md
new file mode 100644
index 0000000..30f3e97
--- /dev/null
+++ b/content/zh/blog/news/v3-service-discovery.md
@@ -0,0 +1,360 @@
+---
+title: "Dubbo3 应用级服务发现"
+linkTitle: "应用级服务发现"
+date: 2021-06-02
+description: >
+ 本文介绍了 Dubbo3 应用级服务发现的实现原理
+---
+
+## 1 服务发现（Service Discovery） 概述
+
+从 Internet 刚开始兴起，如何动态感知后端服务的地址变化就是一个必须要面对的问题，为此人们定义了 DNS
协议，基于此协议，调用方只需要记住由固定字符串组成的域名，就能轻松完成对后端服务的访问，而不用担心流量最终会访问到哪些机器 IP，因为有代理组件会基于 DNS
地址解析后的地址列表，将流量透明的、均匀的分发到不同的后端机器上。
+
+在使用微服务构建复杂的分布式系统时，如何感知 backend 服务实例的动态上下线，也是微服务框架最需要关心并解决的问题之一。业界将这个问题称之为 -
微服务的地址发现（Service Discovery），业界比较有代表性的微服务框架如 SpringCloud、Microservices、Dubbo
等都抽象了强大的动态地址发现能力，并且为了满足微服务业务场景的需求，绝大多数框架的地址发现都是基于自己设计的一套机制来实现，因此在能力、灵活性上都要比传统
DNS 丰富得多。如 SpringCloud 中常用的 Eureka， Dubbo 中常用的 Zookeeper、Nacos
等，这些注册中心实现不止能够传递地址（IP + Port），还包括一些微服务的 Metadata
信息，如实例序列化类型、实例方法列表、各个方法级的定制化配置等。
+
+下图是微服务中 Service Discovery
的基本工作原理图，微服务体系中的实例大概可分为三种角色：服务提供者（Provider）、服务消费者（Consumer）和注册中心（Registry）。而不同框架实现间最主要的区别就体现在注册中心数据的组织：地址如何组织、以什么粒度组织、除地址外还同步哪些数据？
+
+
+
+我们今天这篇文章就是围绕这三个角色展开，重点看下 Dubbo 中对于服务发现方案的设计，包括之前老的服务发现方案的优势和缺点，以及 Dubbo 3.0
中正在设计、开发中的全新的**面向应用粒度的地址发现方案**，我们期待这个新的方案能做到：
+
+* **支持几十万/上百万级集群实例的地址发现**
+* **与不同的微服务体系（如 Spring Cloud）实现在地址发现层面的互通**
+
+
+
+## 2 Dubbo 地址发现机制解析
+
+我们先以一个 DEMO 应用为例，来快速的看一下 Dubbo “接口粒度”服务发现与“应用粒度”服务发现体现出来的区别。这里我们重点关注 Provider
实例是如何向注册中心注册的，并且，为了体现注册中心数据量变化，我们观察的是两个 Provider 实例的场景。
+
+
+
+**应用 DEMO 提供的服务列表如下：**
+
+```xml
+<dubbo:service interface="org.apache.dubbo.samples.basic.api.DemoService"
ref="demoService"/>
+<dubbo:service interface="org.apache.dubbo.samples.basic.api.GreetingService"
ref="greetingService"/>
+```
+
+我们示例注册中心实现采用的是 Zookeeper ，启动 192.168.0.103 和 192.168.0.104
两个实例后，以下是两种模式下注册中心的实际数据
+
+**1. “接口粒度” 服务发现**
+
+192.168.0.103 实例注册的数据
+
+```text
+dubbo://192.168.0.103:20880/org.apache.dubbo.samples.basic.api.DemoService?anyhost=true&application=demo-provider&default=true&deprecated=false&dubbo=2.0.2&dynamic=true&generic=false&interface=org.apache.dubbo.samples.basic.api.DemoService&methods=testVoid,sayHello&pid=995&release=2.7.7&side=provider×tamp=1596988171266
+
+dubbo://192.168.0.103:20880/org.apache.dubbo.samples.basic.api.GreetingService?anyhost=true&application=demo-provider&default=true&deprecated=false&dubbo=2.0.2&dynamic=true&generic=false&interface=org.apache.dubbo.samples.basic.api.GreetingService&methods=greeting&pid=995&release=2.7.7&side=provider×tamp=1596988170816
+```
+
+192.168.0.104 实例注册的数据
+
+```text
+dubbo://192.168.0.104:20880/org.apache.dubbo.samples.basic.api.DemoService?anyhost=true&application=demo-provider&default=true&deprecated=false&dubbo=2.0.2&dynamic=true&generic=false&interface=org.apache.dubbo.samples.basic.api.DemoService&methods=testVoid,sayHello&pid=995&release=2.7.7&side=provider×tamp=1596988171266
+
+dubbo://192.168.0.104:20880/org.apache.dubbo.samples.basic.api.GreetingService?anyhost=true&application=demo-provider&default=true&deprecated=false&dubbo=2.0.2&dynamic=true&generic=false&interface=org.apache.dubbo.samples.basic.api.GreetingService&methods=greeting&pid=995&release=2.7.7&side=provider×tamp=1596988170816
+```
+
+
+
+**2. “应用粒度” 服务发现**
+
+192.168.0.103 与 192.168.0.104 两个实例共享一份注册中心数据，如下：
+
+```text
+{
+ "name": "demo-provider",
+ "id": "192.168.0.103:20880",
+ "address": "192.168.0.103",
+ "port": 20880,
+ "metadata": {
+ "dubbo.endpoints": "[{\"port\":20880,\"protocol\":\"dubbo\"}]",
+ "dubbo.metadata.storage-type": "local",
+ "dubbo.revision": "6785535733750099598"
+ },
+ "time": 1583461240877
+}
+```
+
+
+
+{
+ "name": "demo-provider",
+ "id": "192.168.0.104:20880",
+ "address": "192.168.0.104",
+ "port": 20880,
+ "metadata": {
+ "dubbo.endpoints": "[{\"port\":20880,\"protocol\":\"dubbo\"}]",
+ "dubbo.metadata.storage-type": "local",
+ "dubbo.revision": "7829635812370099387"
+ },
+ "time": 1583461240877
+}
+
+对比以上两种不同粒度的服务发现模式，从 “接口粒度” 升级到 “应用粒度”
后我们可以总结出最大的区别是：注册中心数据量不再与接口数成正比，不论应用提供有多少接口，注册中心只有一条实例数据。
+
+那么接下来我们详细看下这个变化给 Dubbo 带来了哪些好处。
+
+## 3 Dubbo 应用级服务发现的意义
+我们先说结论，应用级服务发现给 Dubbo 带来以下优势：
+
+1. 与业界主流微服务模型对齐，比如 SpringCloud、Kubernetes Native Service等。
+2. 提升性能与可伸缩性。注册中心数据的重新组织（减少），能最大幅度的减轻注册中心的存储、推送压力，进而减少 Dubbo Consumer
侧的地址计算压力；集群规模也开始变得可预测、可评估（与 RPC 接口数量无关，只与实例部署规模相关）。
+
+### 3.1 对齐主流微服务模型
+自动、透明的实例地址发现（负载均衡）是所有微服务框架需要解决的事情，这能让后端的部署结构对上游微服务透明，上游服务只需要从收到的地址列表中选取一个，发起调用就可以了。要实现以上目标，涉及两个关键点的自动同步：
+
+* 实例地址，服务消费方需要知道地址以建立链接
+* RPC 方法定义，服务消费方需要知道 RPC 服务的具体定义，不论服务类型是 rest 或 rmi 等。
+
+
+
+对于 RPC 实例间借助注册中心的数据同步，REST 定义了一套非常有意思的成熟度模型，感兴趣的朋友可以参考这里的链接
https://www.martinfowler.com/articles/richardsonMaturityModel.html， 按照文章中的 4
级成熟度定义，Dubbo 当前基于接口粒度的模型可以对应到 L4 级别。
+
+接下来，我们看看 Dubbo、SpringCloud 以及 Kubernetes 分别是怎么围绕自动化的实例地址发现这个目标设计的。
+
+**1. Spring Cloud**
+
+Spring Cloud 通过注册中心只同步了应用与实例地址，消费方可以基于实例地址与服务提供方建立链接，但是消费方对于如何发起 http
调用（SpringCloud 基于 rest 通信）一无所知，比如对方有哪些 http endpoint，需要传入哪些参数等。
+
+RPC 服务这部分信息目前都是通过线下约定或离线的管理系统来协商的。这种架构的优缺点总结如下。
+优势：部署结构清晰、地址推送量小；
+缺点：地址订阅需要指定应用名， provider 应用变更（拆分）需消费端感知；RPC 调用无法全自动同步。
+
+
+
+**2. Dubbo**
+
+Dubbo 通过注册中心同时同步了实例地址和 RPC 方法，因此其能实现 RPC 过程的自动同步，面向 RPC 编程、面向 RPC
治理，对后端应用的拆分消费端无感知，其缺点则是地址推送数量变大，和 RPC 方法成正比。
+
+
+
+
+**3. Dubbo + Kubernetes**
+
+Dubbo 要支持 Kubernetes native service，相比之前自建注册中心的服务发现体系来说，在工作机制上主要有两点变化：
+
+* 服务注册由平台接管，provider 不再需要关心服务注册
+* consumer 端服务发现将是 Dubbo 关注的重点，通过对接平台层的 API-Server、DNS 等，Dubbo client 可以通过一个
[Service
Name](https://kubernetes.io/docs/concepts/services-networking/service/)（通常对应到
Application Name）查询到一组 [Endpoints]()（一组运行 provider 的 pod），通过将 Endpoints 映射到
Dubbo 内部地址列表，以驱动 Dubbo 内置的负载均衡机制工作。
+
+> Kubernetes Service 作为一个抽象概念，怎么映射到 Dubbo 是一个值得讨论的点
+>
+> * Service Name - > Application Name，Dubbo 应用和 Kubernetes
服务一一对应，对于微服务运维和建设环节透明，与开发阶段解耦。
+>
+> ```yaml
+> apiVersion: v1
+> kind: Service
+> metadata:
+> name: provider-app-name
+> spec:
+> selector:
+> app: provider-app-name
+> ports:
+> - protocol: TCP
+> port:
+> targetPort: 9376
+> ```
+>
+>
+>
+> * Service Name - > Dubbo RPC Service，Kubernetes 要维护调度的服务与应用内建 RPC
服务绑定，维护的服务数量变多。
+>
+> ```yaml
+> ---
+> apiVersion: v1
+> kind: Service
+> metadata:
+> name: rpc-service-1
+> spec:
+> selector:
+> app: provider-app-name
+> ports: ##
+> ...
+> ---
+> apiVersion: v1
+> kind: Service
+> metadata:
+> name: rpc-service-2
+> spec:
+> selector:
+> app: provider-app-name
+> ports: ##
+> ...
+> ---
+> apiVersion: v1
+> kind: Service
+> metadata:
+> name: rpc-service-N
+> spec:
+> selector:
+> app: provider-app-name
+> ports: ##
+> ...
+> ```
+>
+>
+
+
+
+结合以上几种不同微服务框架模型的分析，我们可以发现，Dubbo 与 SpringCloud、Kubernetes
等不同产品在微服务的抽象定义上还是存在很大不同的。SpringCloud 和 Kubernetes
在微服务的模型抽象上还是比较接近的，两者基本都只关心实例地址的同步，如果我们去关心其他的一些服务框架产品，会发现它们绝大多数也是这么设计的；
+> 即 REST 成熟度模型中的 L3 级别。
+
+对比起来 Dubbo 则相对是比较特殊的存在，更多的是从 RPC 服务的粒度去设计的。
+> 对应 REST 成熟度模型中的 L4 级别。
+
+如我们上面针对每种模型做了详细的分析，每种模型都有其优势和不足。而我们最初决定 Dubbo 要做出改变，往其他的微服务发现模型上的对齐，是我们最早在确定
Dubbo 的云原生方案时，我们发现要让 Dubbo 去支持 Kubernetes Native Service，模型对齐是一个基础条件；另一点是来自用户侧对
Dubbo 场景化的一些工程实践的需求，得益于 Dubbo 对多注册、多协议能力的支持，使得 Dubbo
联通不同的微服务体系成为可能，而服务发现模型的不一致成为其中的一个障碍，这部分的场景描述请参见以下文章：https://www.atatech.org/articles/157719
+
+### 3.2 更大规模的微服务集群 - 解决性能瓶颈
+这部分涉及到和注册中心、配置中心的交互，关于不同模型下注册中心数据的变化，之前原理部分我们简单分析过。为更直观的对比服务模型变更带来的推送效率提升，我们来通过一个示例看一下不同模型注册中心的对比：
+
+
+
+图中左边是微服务框架的一个典型工作流程，Provider 和 Consumer 通过注册中心实现自动化的地址通知。其中，Provider
实例的信息如图中表格所示：
+ 应用 DEMO 包含三个接口 DemoService 1 2 3，当前实例的 ip 地址为 10.210.134.30。
+ * 对于 Spring Cloud 和 Kubernetes 模型，注册中心只会存储一条 `DEMO - 10.210.134.30+metadata`
的数据；
+ * 对于老的 Dubbo 模型，注册中心存储了三条接口粒度的数据，分别对应三个接口 DemoService 1 2 3，并且很多的址数据都是重复的；
+
+可以总结出，基于应用粒度的模型所存储和推送的数据量是和应用、实例数成正比的，只有当我们的应用数增多或应用的实例数增长时，地址推送压力才会上涨。
+而对于基于接口粒度的模型，数据量是和接口数量正相关的，鉴于一个应用通常发布多个接口的现状，这个数量级本身比应用粒度是要乘以倍数的；另外一个关键点在于，接口粒度导致的集群规模评估的不透明，相对于实i例、应用增长都通常是在运维侧的规划之中，接口的定义更多的是业务侧的内部行为，往往可以绕过评估给集群带来压力。
+
+以 Consumer 端服务订阅举例，根据我对社区部分 Dubbo 中大规模头部用户的粗略统计，根据受统计公司的实际场景，一个 Consumer
应用要消费（订阅）的 Provier 应用数量往往要超过 10 个，而具体到其要消费（订阅）的的接口数量则通常要达到 30 个，平均情况下 Consumer
订阅的 3 个接口来自同一个 Provider 应用，如此计算下来，如果以应用粒度为地址通知和选址基本单位，则平均地址推送和计算量将下降 60% 还要多，
+而在极端情况下，也就是当 Consumer 端消费的接口更多的来自同一个应用时，这个地址推送与内存消耗的占用将会进一步得到降低，甚至可以超过 80% 以上。
+
+一个典型的几段场景即是 Dubbo 体系中的网关型应用，有些网关应用消费（订阅）达 100+ 应用，而消费（订阅）的服务有 1000+ ，平均有 10
个接口来自同一个应用，如果我们把地址推送和计算的粒度改为应用，则地址推送量从原来的 n * 1000 变为 n * 100，地址数量降低可达近 90%。
+
+## 4 应用级服务发现工作原理
+
+### 4.1 设计原则
+上面一节我们从**服务模型**及**支撑大规模集群**的角度分别给出了 Dubbo
往应用级服务发现靠拢的好处或原因，但这么做的同时接口粒度的服务治理能力还是要继续保留，这是 Dubbo 框架编程模型易用性、服务治理能力优势的基础。
+以下是我认为我们做服务模型迁移仍要坚持的设计原则
+
+* 新的服务发现模型要实现对原有 Dubbo 消费端开发者的无感知迁移，即 Dubbo 继续面向 RPC 服务编程、面向 RPC
服务治理，做到对用户侧完全无感知。
+* 建立 Consumer 与 Provider 间的自动化 RPC 服务元数据协调机制，解决传统微服务模型无法同步 RPC 级接口配置的缺点。
+
+### 4.2 基本原理详解
+
+应用级服务发现作为一种新的服务发现机制，和以前 Dubbo 基于 RPC
服务粒度的服务发现在核心流程上基本上是一致的：即服务提供者往注册中心注册地址信息，服务消费者从注册中心拉取&订阅地址信息。
+
+这里主要的不同有以下两点：
+
+#### 4.2.1 注册中心数据以“应用 - 实例列表”格式组织，不再包含 RPC 服务信息
+
+
+
+以下是每个 Instance metadata 的示例数据，总的原则是 metadata 只包含当前 instance 节点相关的信息，不涉及 RPC
服务粒度的信息。
+
+总体信息概括如下：实例地址、实例各种环境标、metadata service 元数据、其他少量必要属性。
+
+```json
+{
+ "name": "provider-app-name",
+ "id": "192.168.0.102:20880",
+ "address": "192.168.0.102",
+ "port": 20880,
+ "sslPort": null,
+ "payload": {
+ "id": null,
+ "name": "provider-app-name",
+ "metadata": {
+ "metadataService":
"{\"dubbo\":{\"version\":\"1.0.0\",\"dubbo\":\"2.0.2\",\"release\":\"2.7.5\",\"port\":\"20881\"}}",
+ "endpoints":
"[{\"port\":20880,\"protocol\":\"dubbo\"}]",
+ "storage-type": "local",
+ "revision": "6785535733750099598",
+ }
+ },
+ "registrationTimeUTC": 1583461240877,
+ "serviceType": "DYNAMIC",
+ "uriSpec": null
+}
+```
+
+#### 4.2.2 Client – Server 自行协商 RPC 方法信息
+
+在注册中心不再同步 RPC 服务信息后，服务自省在服务消费端和提供端之间建立了一条内置的 RPC
服务信息协商机制，这也是“服务自省”这个名字的由来。服务端实例会暴露一个预定义的 MetadataService RPC 服务，消费端通过调用
MetadataService 获取每个实例 RPC 方法相关的配置信息。
+
+
+
+当前 MetadataService 返回的数据格式如下，
+
+```json
+[
+
"dubbo://192.168.0.102:20880/org.apache.dubbo.demo.DemoService?anyhost=true&application=demo-provider&deprecated=false&dubbo=2.0.2&dynamic=true&generic=false&interface=org.apache.dubbo.demo.DemoService&methods=sayHello&pid=9585&release=2.7.5&side=provider×tamp=1583469714314",
+
"dubbo://192.168.0.102:20880/org.apache.dubbo.demo.HelloService?anyhost=true&application=demo-provider&deprecated=false&dubbo=2.0.2&dynamic=true&generic=false&interface=org.apache.dubbo.demo.DemoService&methods=sayHello&pid=9585&release=2.7.5&side=provider×tamp=1583469714314",
+
"dubbo://192.168.0.102:20880/org.apache.dubbo.demo.WorldService?anyhost=true&application=demo-provider&deprecated=false&dubbo=2.0.2&dynamic=true&generic=false&interface=org.apache.dubbo.demo.DemoService&methods=sayHello&pid=9585&release=2.7.5&side=provider×tamp=1583469714314"
+]
+```
+
+> 熟悉 Dubbo 基于 RPC 服务粒度的服务发现模型的开发者应该能看出来，服务自省机制机制将以前注册中心传递的 URL 一拆为二：
+>
+> * 一部分和实例相关的数据继续保留在注册中心，如 ip、port、机器标识等。
+> * 另一部分和 RPC 方法相关的数据从注册中心移除，转而通过 MetadataService 暴露给消费端。
+>
+> **理想情况下是能达到数据按照实例、RPC 服务严格区分开来，但明显可以看到以上实现版本还存在一些数据冗余，有些也数据还未合理划分。尤其是
MetadataService 部分，其返回的数据还只是简单的 URL 列表组装，这些 URL其实是包含了全量的数据。**
+
+以下是服务自省的一个完整工作流程图，详细描述了服务注册、服务发现、MetadataService、RPC 调用间的协作流程。
+
+
+
+* 服务提供者启动，首先解析应用定义的“普通服务”并依次注册为 RPC 服务，紧接着注册内建的 MetadataService 服务，最后打开 TCP
监听端口。
+* 启动完成后，将实例信息注册到注册中心（仅限 ip、port 等实例相关数据），提供者启动完成。
+* 服务消费者启动，首先依据其要“消费的 provider 应用名”到注册中心查询地址列表，并完成订阅（以实现后续地址变更自动通知）。
+* 消费端拿到地址列表后，紧接着对 MetadataService 发起调用，返回结果中包含了所有应用定义的“普通服务”及其相关配置信息。
+* 至此，消费者可以接收外部流量，并对提供者发起 Dubbo RPC 调用
+
+> 在以上流程中，我们只考虑了一切顺利的情况，但在更详细的设计或编码实现中，我们还需要严格约定一些异常场景下的框架行为。比如，如果消费者
MetadataService 调用失败，则在重试知道成功之前，消费者将不可以接收外部流量。
+
+### 4.3 服务自省中的关键机制
+#### 4.3.1 元数据同步机制
+
+Client 与 Server 间在收到地址推送后的配置同步是服务自省的关键环节，目前针对元数据同步有两种具体的可选方案，分别是：
+* 内建 MetadataService。
+* 独立的元数据中心，通过中细化的元数据集群协调数据。
+
+**1. 内建 MetadataService**
+MetadataService 通过标准的 Dubbo
协议暴露，根据查询条件，会将内存中符合条件的“普通服务”配置返回给消费者。这一步发生在消费端选址和调用前。
+
+**元数据中心**
+复用 2.7 版本中引入的元数据中心，provider 实例启动后，会尝试将内部的 RPC 服务组织成元数据的格式到元数据中心，而 consumer
则在每次收到注册中心推送更新后，主动查询元数据中心。
+
+> 注意 consumer
端查询元数据中心的时机，是等到注册中心的地址更新通知之后。也就是通过注册中心下发的数据，我们能明确的知道何时某个实例的元数据被更新了，此时才需要去查元数据中心。
+
+
+
+#### 4.3.2 RPC 服务 < - > 应用映射关系
+
+回顾上文讲到的注册中心关于“应用 -
实例列表”结构的数据组织形式，这个变动目前对开发者并不是完全透明的，业务开发侧会感知到查询/订阅地址列表的机制的变化。具体来说，相比以往我们基于 RPC
服务来检索地址，现在 consumer 需要通过指定 provider 应用名才能实现地址查询或订阅。
+
+老的 Consumer 开发与配置示例：
+
+```xml
+<!-- 框架直接通过 RPC Service 1/2/N 去注册中心查询或订阅地址列表 -->
+<dubbo:registry address="zookeeper://127.0.0.1:2181"/>
+<dubbo:reference interface="RPC Service 1" />
+<dubbo:reference interface="RPC Service 2" />
+<dubbo:reference interface="RPC Service N" />
+```
+
+新的 Consumer 开发与配置示例：
+
+```xml
+<!-- 框架需要通过额外的 provided-by="provider-app-x" 才能在注册中心查询或订阅到地址列表 -->
+<dubbo:registry address="zookeeper://127.0.0.1:2181?registry-type=service"/>
+<dubbo:reference interface="RPC Service 1" provided-by="provider-app-x"/>
+<dubbo:reference interface="RPC Service 2" provided-by="provider-app-x" />
+<dubbo:reference interface="RPC Service N" provided-by="provider-app-y" />
+```
+
+以上指定 provider 应用名的方式是 Spring Cloud 当前的做法，需要 consumer 端的开发者显示指定其要消费的 provider
应用。
+
+以上问题的根源在于注册中心不知道任何 RPC 服务相关的信息，因此只能通过应用名来查询。
+
+为了使整个开发流程对老的 Dubbo 用户更透明，同时避免指定 provider 对可扩展性带来的影响（参见下方说明），我们设计了一套 `RPC
服务到应用名`的映射关系，以尝试在 consumer 自动完成 RPC 服务到 provider 应用名的转换。
+
+
+
+> Dubbo 之所以选择建立一套“接口-应用”的映射关系，主要是考虑到 service - app
映射关系的不确定性。一个典型的场景即是应用/服务拆分，如上面提到的配置`<dubbo:reference interface="RPC Service 2"
provided-by="provider-app-x" />`，PC Service 2 是定义于 provider-app-x
中的一个服务，未来它随时可能会被开发者分拆到另外一个新的应用如 provider-app-x-1 中，这个拆分要被所有的 PC Service 2
消费方感知到，并对应用进行修改升级，如改为`<dubbo:reference interface="RPC Service 2"
provided-by="provider-app-x-1" />`，这样的升级成本不可否认还是挺高的。
+> 到底是 Dubbo 框架帮助开发者透明的解决这个问题，还是交由开发者自己去解决，当然这只是个策略选择问题，并且 Dubbo 2.7.5+
版本目前是都提供了的。其实我个人更倾向于交由业务开发者通过组织上的约束来做，这样也可进一步降低 Dubbo 框架的复杂度，提升运行态的稳定性。
+
+## 5 总结与展望
+应用级服务发现机制是 Dubbo 面向云原生走出的重要一步，它帮 Dubbo 打通了与其他微服务体系之间在地址发现层面的鸿沟，也成为 Dubbo 适配
Kubernetes Native Service 等基础设施的基础。我们期望 Dubbo
在新模型基础上，能继续保留在编程易用性、服务治理能力等方面强大的优势。但是我们也应该看到应用粒度的模型一方面带来了新的复杂性，需要我们继续去优化与增强；另一方面，除了地址存储与推送之外，应用粒度在帮助
Dubbo 选址层面也有进一步挖掘的潜力。
\ No newline at end of file
diff --git a/content/zh/docs/v3.0/Introduction.md
b/content/zh/docs/v3.0/Introduction.md
new file mode 100644
index 0000000..502e244
--- /dev/null
+++ b/content/zh/docs/v3.0/Introduction.md
@@ -0,0 +1,39 @@
+---
+type: docs
+title: "Dubbo3 简介"
+linkTitle: "简介"
+weight: 1
+description: "这篇文档是关于 Dubbo 的简单介绍，涵盖 Dubbo 的核心概念、基本使用方式以及 Dubbo3 核心功能，无论你是
Dubbo 的老用户还是新用户，都可以通过这篇
+文档快速了解 Dubbo 及新版本带来的变化。"
+---
+
+Apache Dubbo 是一个款微服务开发框架，它提供了 RPC通信 与 微服务治理 两大关键能力。这意味着，使用 Dubbo
开发的微服务，将具备相互之间的远程发现与通信能力，
+同时利用 Dubbo 提供的丰富服务治理能力，实现诸如服务发现、负载均衡、流量调度等服务治理诉求。同时 Dubbo
是高度可扩展的，用户几乎可以在任意功能点去定制自己的实现，
+以改变框架的默认行为满足自己的业务需求。
+
+Dubbo 提供了丰富的多语言客户端实现，其中 Java、Golang 版本是目前稳定性、活跃度最好的版本，其他多语言客户端也在持续建设中。
+
+This page introduces you to gRPC and protocol buffers. gRPC can use protocol
buffers as both its Interface Definition Language (IDL) and as its underlying
message interchange format. If you’re new to gRPC and/or protocol buffers, read
this! If you just want to dive in and see gRPC in action first, select a
language and try its Quick start.
+
+## 简介
+In gRPC, a client application can directly call a method on a server
application on a different machine as if it were a local object, making it
easier for you to create distributed applications and services. As in many RPC
systems, gRPC is based around the idea of defining a service, specifying the
methods that can be called remotely with their parameters and return types. On
the server side, the server implements this interface and runs a gRPC server to
handle client calls. On the clien [...]
+
+## 核心概念
+Dubbo 提供的核心能力包括:
+* 服务定义
+* 服务远程通信
+* 服务发现
+* 负载均衡
+* 流量管理
+* 动态配置
+
+以下是对一些关键概念的简单介绍。
+
+服务定义
+
+服务定义
+
+服务定义
+## Dubbo3 vs Dubbo2
+
+
diff --git a/content/zh/docs/v3.0/_index.md b/content/zh/docs/v3.0/_index.md
index 0263767..2cb1464 100755
--- a/content/zh/docs/v3.0/_index.md
+++ b/content/zh/docs/v3.0/_index.md
@@ -3,7 +3,7 @@
type: docs
title: "Dubbo 3.0"
linkTitle: "Dubbo 3.0"
-weight: 20
+weight: 10
description: "Dubbo 3.0 文档"
---
diff --git a/content/zh/docs/v3.0/advanced/_index.md
b/content/zh/docs/v3.0/advanced/_index.md
new file mode 100755
index 0000000..31ed9a3
--- /dev/null
+++ b/content/zh/docs/v3.0/advanced/_index.md
@@ -0,0 +1,9 @@
+
+---
+type: docs
+title: "高级用法"
+linkTitle: "高级用法"
+weight: 40
+description: "Dubbo 3.0 文档"
+---
+
diff --git a/content/zh/docs/v3.0/concepts/configuration.md
b/content/zh/docs/v3.0/concepts/configuration.md
new file mode 100644
index 0000000..6812482
--- /dev/null
+++ b/content/zh/docs/v3.0/concepts/configuration.md
@@ -0,0 +1,7 @@
+---
+type: docs
+title: "配置管理"
+linkTitle: "配置"
+weight: 4
+description: "描述 Dubbo 支持的配置，Dubbo 的动态配置能力。"
+---
\ No newline at end of file
diff --git a/content/zh/docs/v3.0/concepts/extensibility.md
b/content/zh/docs/v3.0/concepts/extensibility.md
new file mode 100644
index 0000000..0b7fa47
--- /dev/null
+++ b/content/zh/docs/v3.0/concepts/extensibility.md
@@ -0,0 +1,7 @@
+---
+type: docs
+title: "如何扩展 Dubbo"
+linkTitle: "扩展性"
+weight: 6
+description: "Dubbo 通过 SPI 机制提供了非常灵活的可扩展性"
+---
\ No newline at end of file
diff --git a/content/zh/docs/v3.0/concepts/registry-configcenter-metadata.md
b/content/zh/docs/v3.0/concepts/registry-configcenter-metadata.md
new file mode 100644
index 0000000..8d45e23
--- /dev/null
+++ b/content/zh/docs/v3.0/concepts/registry-configcenter-metadata.md
@@ -0,0 +1,39 @@
+---
+type: docs
+title: "Dubbo 部署架构（注册中心 配置中心 元数据中心）"
+linkTitle: "部署架构"
+weight: 5
+description: "了解 Dubbo 的三大中心化组件，它们各自的职责、工作方式。"
+---
+
+作为一个微服务框架，Dubbo sdk 跟随着微服务组件被部署在分布式集群各个位置，为了在分布式环境下实现各个微服务组件间的协作，
+Dubbo 定义了一些中心化组件，这包括：
+* 注册中心。协调 Consumer 与 Provider 之间的地址注册与发现
+* 配置中心。
+ * 存储 Dubbo 启动阶段的全局配置，保证配置的跨环境共享与全局一致性
+ * 负责服务治理规则（路由规则、动态配置等）的存储与推送。
+* 元数据中心。
+ * 接收 Provider 上报的服务接口元数据，为 Admin 等控制台提供运维能力（如服务测试、接口文档等）
+ * 作为服务发现机制的补充，提供额外的接口/方法级别配置信息的同步能力，相当于注册中心的额外扩展
+
+ 
+
+上图完整的描述了 Dubbo 微服务组件与各个中心的交互过程。
+
+以上三个中心并不是运行 Dubbo
的必要条件，用户完全可以根据自身业务情况决定只启用其中一个或多个，以达到简化部署的目的。通常情况下，所有用户都会以独立的注册中心
+开始 Dubbo 服务开发，而配置中心、元数据中心则会在微服务演进的过程中逐步的按需被引入进来。
+
+> 当然在 Dubbo + Mesh 的场景下，随着 Dubbo 服务注册能力的弱化，注册中心也不再是必选项，其职责开始被控制面取代。
+> 请参见 Dubbo Mesh 方案的描述，ThinSDK 与 Proxyless Mesh。
+
+## 注册中心
+
+
+## 配置中心
+类比 Spring Cloud Config同
+
+
+## 元数据中心
+
+
+
diff --git a/content/zh/docs/v3.0/concepts/rpc-protocol.md
b/content/zh/docs/v3.0/concepts/rpc-protocol.md
new file mode 100644
index 0000000..2bf9863
--- /dev/null
+++ b/content/zh/docs/v3.0/concepts/rpc-protocol.md
@@ -0,0 +1,16 @@
+---
+type: docs
+title: "RPC 通信协议"
+linkTitle: "协议"
+weight: 2
+description: "描述 Dubbo3 支持的通信协议"
+---
+
+RPC 协议
+
+## Triple（Dubbo3）
+
+## Dubbo2
+
+## 其他协议
+
diff --git a/content/zh/docs/v3.0/concepts/service-discovery.md
b/content/zh/docs/v3.0/concepts/service-discovery.md
new file mode 100644
index 0000000..495427b
--- /dev/null
+++ b/content/zh/docs/v3.0/concepts/service-discovery.md
@@ -0,0 +1,70 @@
+---
+type: docs
+title: "服务发现"
+linkTitle: "服务发现"
+weight: 1
+description: "服务发现"
+---
+服务发现，即消费端自动发现服务之地列表的能力，是微服务框架需要具备的关键能力。Dubbo 提供了基于消费端的自动服务发现能力，其基本工作原理如下图：
+
+
+
+服务发现的一个核心组件是注册中心，Provider 注册地址到注册中心，Consumer 从注册中心读取和订阅 Provider 地址列表。
+因此，要启用服务发现，需要为 Dubbo 增加注册中心配置：
+
+以 dubbo-spring-boot-starter 使用方式为例，增加 registry 配置
+
+```properties
+# application.properties
+dubbo
+ registry
+ address: zookeeper://127.0.0.1:2181
+```
+
+## 服务发现（Dubbo3 vs Dubbo2）
+就使用方式上而言，Dubbo3 与 Dubbo2 的服务发现配置是完全一致的，不需要改动什么内容。但就实现原理上而言，Dubbo3 引入了全新的服务发现模型
- 应用级服务发现，
+在工作原理、数据格式上已完全不能兼容老版本服务发现。
+
+* Dubbo3 应用级服务发现，以应用粒度组织地址数据
+* Dubbo2 接口级服务发现，以接口粒度组织地址数据
+
+Dubbo3 格式的 Provider 地址不能被 Dubbo2 的 Consumer 识别到，反之 Dubbo2 的消费者也不能订阅到 Dubbo3
Provider。
+* 对于新用户，我们提倡直接启用 Dubbo3 的默认行为，即启用应用级服务发现，参见《samples/应用级服务发现》；
+* 对于老用户，要面临如何平滑迁移到应用级服务发现的问题，考虑到老用户的规则如此之大，Dubbo3
默认保持了接口级地址发现的行为，这保证了老用户可以直接无感升级到 Dubbo3。
+而如果要开启应用级服务发现，则需要通过配置显示开启（双注册、双订阅），具体开启与平滑迁移过程，可参见《migration/地址发现迁移指南》。
+
+## 应用级服务发现
+概括来说，Dubbo3 引入的应用级服务发现主要有以下优势
+* 适配云原生微服务变革。云原生时代的基础设施能力不断向上释放，像 Kubernetes 等平台都集成了微服务概念抽象，Dubbo3
的应用级服务发现是适配各种微服务体系的通用模型。
+* 提升性能与可伸缩性。支持超大规模集群的服务治理一直以来都是 Dubbo
的优势，通过引入应用级服务发现模型，从本质上解决了注册中心地址数据的存储与推送压力，相应的 Consumer 侧的地址计算压力也成数量级下降；
+ 集群规模也开始变得可预测、可评估（与 RPC 接口数量无关，只与实例部署规模相关）。
+
+下图是 Dubbo2 的服务发现模型：Provider 注册服务地址，Consumer
经过注册中心协调并发现服务地址，进而对地址发起通信，这是被绝大多数微服务框架的经典服务发现流程。而 Dubbo2 的特殊之处在于，它把 “RPC
接口”的信息也融合在了地址发现过程中，而这部分信息往往是和具体的业务定义密切相关的。
+
+
+
+而在接入云原生基础设施后，基础设施融入了微服务概念的抽象，容器化微服务被编排、调度的过程即
+完成了在基础设施层面的注册。如下图所示，基础设施即承担了注册中心的职责，又完成了服务注册的动作，而 “RPC
接口”这部分信息，由于与具体的业务相关，不可能也不适合被基础设施托管。
+
+
+
+在这样的场景下，对 Dubbo3 的服务注册发现机制提出了两个要求：
+Dubbo3 需要在原有服务发现流程中抽象出通用的、与业务逻辑无关的地址映射模型，并确保这部分模型足够合理，以支持将地址的注册行为和存储委托给下层基础设施
+Dubbo3 特有的业务接口同步机制，是 Dubbo3 需要保留的优势，需要在 1 中定义的新地址模型之上，通过框架内的自有机制予以解决。
+
+这样设计的全新的服务发现模型，在架构兼容性、可伸缩性上都给 Dubbo3 带来了更大的优势。
+
+
+
+在架构兼容性上，如上文所述，Dubbo3 复用下层基础设施的服务抽象能力成为了可能；另一方面，如 Spring Cloud
等业界其它微服务解决方案也沿用这种模型，
+在打通了地址发现之后，使得用户探索用 Dubbo 连接异构的微服务体系成为了一种可能。
+
+Dubbo3 服务发现模型更适合构建可伸缩的服务体系，这点要如何理解？
+这里先举个简单的例子，来直观的对比 Dubbo2 与 Dubbo3 在地址发现流程上的数据流量变化：假设一个微服务应用定义了 100 个接口（Dubbo
中的服务），
+则需要往注册中心中注册 100 个服务，如果这个应用被部署在了 100 台机器上，那这 100 个服务总共会产生 100 * 100 = 10000
个虚拟节点；而同样的应用，
+对于 Dubbo3 来说，新的注册发现模型只需要 1 个服务（只和应用有关和接口无关）， 只注册和机器实例数相等的 1 * 100 = 100
个虚拟节点到注册中心。
+在这个简单的示例中，Dubbo 所注册的地址数量下降到了原来的 1 / 100，对于注册中心、订阅方的存储压力都是一个极大的释放。更重要的是，
+地址发现容量彻底与业务 RPC 定义解藕开来，整个集群的容量评估对运维来说将变得更加透明：部署多少台机器就会有多大负载，不会像 Dubbo2 一样，
+因为业务 RPC 重构就会影响到整个集群服务发现的稳定性。
+
+请通过以下 blog 了解更多应用级服务发现设计原则细节。
diff --git a/content/zh/docs/v3.0/concepts/traffic-management.md
b/content/zh/docs/v3.0/concepts/traffic-management.md
new file mode 100644
index 0000000..5ccff84
--- /dev/null
+++ b/content/zh/docs/v3.0/concepts/traffic-management.md
@@ -0,0 +1,9 @@
+---
+type: docs
+title: "服务流量管理"
+linkTitle: "流量管理"
+weight: 3
+description: "通过 Dubbo 定义的路由规则，实现对流量分布的控制"
+---
+
+流量控制
\ No newline at end of file
diff --git a/content/zh/docs/v3.0/examples/_index.md
b/content/zh/docs/v3.0/examples/_index.md
index a7407f3..60896c6 100644
--- a/content/zh/docs/v3.0/examples/_index.md
+++ b/content/zh/docs/v3.0/examples/_index.md
@@ -1,9 +1,7 @@
---
type: docs
-title: "示例"
-linkTitle: "快速开始"
-weight: 11
-description: "快速体验 Dubbo3。"
+title: "基本功能介绍与示例"
+linkTitle: "介绍与示例"
+weight: 20
+description: "Dubbo 基本功能的简单介绍与示例。"
---
-
-快速体验 Dubbo3。
\ No newline at end of file
diff --git a/content/zh/docs/v3.0/examples/quick-start.md
b/content/zh/docs/v3.0/examples/quick-start.md
new file mode 100644
index 0000000..30e0ddf
--- /dev/null
+++ b/content/zh/docs/v3.0/examples/quick-start.md
@@ -0,0 +1,16 @@
+---
+type: docs
+title: "快速开始"
+linkTitle: "快速开始"
+weight: 1
+description: ""
+---
+
+Dubbo 集成了多种开发模式
+* Raw API
+* Spring / Spring Boot Starter
+* 配置文件
+
+## Java
+
+## GO
diff --git a/content/zh/docs/v3.0/migration/_index.md
b/content/zh/docs/v3.0/migration/_index.md
index c612276..005990c 100755
--- a/content/zh/docs/v3.0/migration/_index.md
+++ b/content/zh/docs/v3.0/migration/_index.md
@@ -3,7 +3,7 @@
type: docs
title: "升级与兼容性"
linkTitle: "升级与兼容性"
-weight: 20
+weight: 50
description: "如果你是老版本的 Dubbo 用户，请在此了解如何升级到 Dubbo3 版本。"
---
diff --git a/content/zh/docs/v3.0/references/_index.md
b/content/zh/docs/v3.0/references/_index.md
index 980892c..e1651b9 100644
--- a/content/zh/docs/v3.0/references/_index.md
+++ b/content/zh/docs/v3.0/references/_index.md
@@ -2,7 +2,7 @@
type: docs
title: "功能参考手册"
linkTitle: "参考手册"
-weight: 12
+weight: 30
description: "面向用户的参考手册，涵盖了 Dubbo3 的所有核心功能"
---
diff --git a/static/imgs/blog/servicediscovery/arc.png
b/static/imgs/blog/servicediscovery/arc.png
new file mode 100644
index 0000000..a854784
Binary files /dev/null and b/static/imgs/blog/servicediscovery/arc.png differ
diff --git a/static/imgs/blog/servicediscovery/centers.png
b/static/imgs/blog/servicediscovery/centers.png
new file mode 100644
index 0000000..e2eb4b5
Binary files /dev/null and b/static/imgs/blog/servicediscovery/centers.png
differ
diff --git a/static/imgs/blog/servicediscovery/meta.png
b/static/imgs/blog/servicediscovery/meta.png
new file mode 100644
index 0000000..392b8cf
Binary files /dev/null and b/static/imgs/blog/servicediscovery/meta.png differ
diff --git a/static/imgs/blog/servicediscovery/metadatacenter.png
b/static/imgs/blog/servicediscovery/metadatacenter.png
new file mode 100644
index 0000000..c3a9108
Binary files /dev/null and
b/static/imgs/blog/servicediscovery/metadatacenter.png differ
diff --git a/static/imgs/blog/servicediscovery/metadataservice.png
b/static/imgs/blog/servicediscovery/metadataservice.png
new file mode 100644
index 0000000..82cffbe
Binary files /dev/null and
b/static/imgs/blog/servicediscovery/metadataservice.png differ
diff --git a/static/imgs/blog/servicediscovery/rpc-dubbo.png
b/static/imgs/blog/servicediscovery/rpc-dubbo.png
new file mode 100644
index 0000000..8cb49a2
Binary files /dev/null and b/static/imgs/blog/servicediscovery/rpc-dubbo.png
differ
diff --git a/static/imgs/blog/servicediscovery/rpc-k8s.png
b/static/imgs/blog/servicediscovery/rpc-k8s.png
new file mode 100644
index 0000000..adc766a
Binary files /dev/null and b/static/imgs/blog/servicediscovery/rpc-k8s.png
differ
diff --git a/static/imgs/blog/servicediscovery/rpc-sc.png
b/static/imgs/blog/servicediscovery/rpc-sc.png
new file mode 100644
index 0000000..17d1227
Binary files /dev/null and b/static/imgs/blog/servicediscovery/rpc-sc.png differ
diff --git a/static/imgs/blog/servicediscovery/rpc.png
b/static/imgs/blog/servicediscovery/rpc.png
new file mode 100644
index 0000000..7202b20
Binary files /dev/null and b/static/imgs/blog/servicediscovery/rpc.png differ
diff --git a/static/imgs/blog/servicediscovery/rpc1.png
b/static/imgs/blog/servicediscovery/rpc1.png
new file mode 100644
index 0000000..17d1227
Binary files /dev/null and b/static/imgs/blog/servicediscovery/rpc1.png differ
diff --git a/static/imgs/blog/servicediscovery/servicediscovery-perf.png
b/static/imgs/blog/servicediscovery/servicediscovery-perf.png
new file mode 100644
index 0000000..8c00f7f
Binary files /dev/null and
b/static/imgs/blog/servicediscovery/servicediscovery-perf.png differ
diff --git a/static/imgs/blog/servicediscovery/workflow.png
b/static/imgs/blog/servicediscovery/workflow.png
new file mode 100644
index 0000000..2b1174b
Binary files /dev/null and b/static/imgs/blog/servicediscovery/workflow.png
differ
diff --git a/static/imgs/v3/concepts/centers-config.png
b/static/imgs/v3/concepts/centers-config.png
new file mode 100644
index 0000000..bf2f918
Binary files /dev/null and b/static/imgs/v3/concepts/centers-config.png differ
diff --git a/static/imgs/v3/concepts/centers-metadata.png
b/static/imgs/v3/concepts/centers-metadata.png
new file mode 100644
index 0000000..7dba449
Binary files /dev/null and b/static/imgs/v3/concepts/centers-metadata.png differ
diff --git a/static/imgs/v3/concepts/centers-registry.png
b/static/imgs/v3/concepts/centers-registry.png
new file mode 100644
index 0000000..1a1f102
Binary files /dev/null and b/static/imgs/v3/concepts/centers-registry.png differ
diff --git a/static/imgs/v3/concepts/servicediscovery_k8s.png
b/static/imgs/v3/concepts/servicediscovery_k8s.png
new file mode 100644
index 0000000..0f76f18
Binary files /dev/null and b/static/imgs/v3/concepts/servicediscovery_k8s.png
differ
diff --git a/static/imgs/v3/concepts/servicediscovery_mem.png
b/static/imgs/v3/concepts/servicediscovery_mem.png
new file mode 100644
index 0000000..2e23878
Binary files /dev/null and b/static/imgs/v3/concepts/servicediscovery_mem.png
differ
diff --git a/static/imgs/v3/concepts/servicediscovery_old.png
b/static/imgs/v3/concepts/servicediscovery_old.png
new file mode 100644
index 0000000..b1842ac
Binary files /dev/null and b/static/imgs/v3/concepts/servicediscovery_old.png
differ
diff --git a/static/imgs/v3/concepts/threecenters.png
b/static/imgs/v3/concepts/threecenters.png
new file mode 100644
index 0000000..695a79f
Binary files /dev/null and b/static/imgs/v3/concepts/threecenters.png differ
