This is an automated email from the ASF dual-hosted git repository.
songxiaosheng 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 fff153570d4 Markdown error (#2967)
fff153570d4 is described below
commit fff153570d44693bb2e021929d162f9b972ad434
Author: 王聪洋 <56506697+wcy666...@users.noreply.github.com>
AuthorDate: Sun Apr 28 21:45:27 2024 +0800
Markdown error (#2967)
* Update multiple-protocols-registries.md
* Update 1-指标样本的收集与存储.md
* Update 2-指标收集器的指标采集流程.md
* Update 1-指标样本的收集与存储.md
* Update 3-指标监听注册梳理.md
* Update dubbo-async-client.md
* Update dubbo-supporting-grpc-http2-and-protobuf.md
* Update dubbo-stub-mock.md
* Update dubbo-rest.md
* Update connect-heterogeneous-microservices.md
* Update introduction-to-dubbo-spi-2.md
* Update dubbo-consistent-hash-implementation.md
* Update dubbo-k8s.md
* fix c i
---
...\266\351\233\206\344\270\216\345\255\230\345\202\250.md" | 6 +++---
...\207\351\207\207\351\233\206\346\265\201\347\250\213.md" | 2 +-
...\254\346\263\250\345\206\214\346\242\263\347\220\206.md" | 8 ++++----
.../blog/java/demos/connect-heterogeneous-microservices.md | 13 ++++++++-----
content/zh-cn/blog/java/demos/dubbo-async-client.md | 2 +-
.../blog/java/demos/dubbo-consistent-hash-implementation.md | 2 +-
content/zh-cn/blog/java/demos/dubbo-k8s.md | 2 +-
content/zh-cn/blog/java/demos/dubbo-rest.md | 4 ++--
content/zh-cn/blog/java/demos/dubbo-stub-mock.md | 2 +-
.../java/demos/dubbo-supporting-grpc-http2-and-protobuf.md | 4 ++--
.../zh-cn/blog/java/demos/introduction-to-dubbo-spi-2.md | 6 +++---
.../zh-cn/blog/java/demos/multiple-protocols-registries.md | 2 +-
12 files changed, 28 insertions(+), 25 deletions(-)
diff --git
"a/content/zh-cn/blog/java/codeanalysis/metrics/1-\346\214\207\346\240\207\346\240\267\346\234\254\347\232\204\346\224\266\351\233\206\344\270\216\345\255\230\345\202\250.md"
"b/content/zh-cn/blog/java/codeanalysis/metrics/1-\346\214\207\346\240\207\346\240\267\346\234\254\347\232\204\346\224\266\351\233\206\344\270\216\345\255\230\345\202\250.md"
index 3583850702e..34e953f7aa8 100644
---
"a/content/zh-cn/blog/java/codeanalysis/metrics/1-\346\214\207\346\240\207\346\240\267\346\234\254\347\232\204\346\224\266\351\233\206\344\270\216\345\255\230\345\202\250.md"
+++
"b/content/zh-cn/blog/java/codeanalysis/metrics/1-\346\214\207\346\240\207\346\240\267\346\234\254\347\232\204\346\224\266\351\233\206\344\270\216\345\255\230\345\202\250.md"
@@ -59,7 +59,7 @@ description: "Dubbo 指标模块源码分析-指标样本的收集与存储"
对于以上四个聚合器，他们的职责就是存储某一类型的采样样本。
-** 基本数据聚合器 （BaseStatComposite）**
对这三个子聚合器的操作进行了简单整合，统一提供给外界。**而混合指标收集器（CombMetricsCollector）**
也基本保留了内部基本数据聚合器的所有操作，将其封装为 `increment`、`setNum`、`addRt
`三个方法（及它们的重载，分别收集应用级数据和服务级数据）向上提供。外部组件可以直接调用这些收集器完成指标更新操作。
+**基本数据聚合器 （BaseStatComposite）**
对这三个子聚合器的操作进行了简单整合，统一提供给外界。**而混合指标收集器（CombMetricsCollector）**
也基本保留了内部基本数据聚合器的所有操作，将其封装为 `increment`、`setNum`、`addRt
`三个方法（及它们的重载，分别收集应用级数据和服务级数据）向上提供。外部组件可以直接调用这些收集器完成指标更新操作。
**当调用元数据中心指标收集器、注册中心指标收集器的 collect
方法时，最终会调用`BaseStatComposite.export(MetricsCategory category)` ,
该方法会收集内部三个聚合器的指标并返回。**
@@ -82,13 +82,13 @@ private final Map<ConfigCenterMetric, AtomicLong>
updatedMetrics = new Concurren
**DefaultMetricsCollector 默认指标采集器：**
-它不直接存储采样数据，而是通过收集其下**指标采样器（MetricsSampler）**的样本来完成采样工作。这些采样器包括：
+它不直接存储采样数据，而是通过收集其下**指标采样器（MetricsSampler）** 的样本来完成采样工作。这些采样器包括：
* 方法采样器
* 应用采样器
* 线程池采样器
-这些采样器完成采样后，还会利用采集器中的**事件多播器（Multicaster）**将指标事件发布出去，可以被其它监听器处理。详细流程将在后文中探讨。
+这些采样器完成采样后，还会利用采集器中的**事件多播器（Multicaster）** 将指标事件发布出去，可以被其它监听器处理。详细流程将在后文中探讨。
**HistogramMetricsCollector 直方图指标采集器：**
diff --git
"a/content/zh-cn/blog/java/codeanalysis/metrics/2-\346\214\207\346\240\207\346\224\266\351\233\206\345\231\250\347\232\204\346\214\207\346\240\207\351\207\207\351\233\206\346\265\201\347\250\213.md"
"b/content/zh-cn/blog/java/codeanalysis/metrics/2-\346\214\207\346\240\207\346\224\266\351\233\206\345\231\250\347\232\204\346\214\207\346\240\207\351\207\207\351\233\206\346\265\201\347\250\213.md"
index bcdfd422b6e..fcc4d6b490e 100644
---
"a/content/zh-cn/blog/java/codeanalysis/metrics/2-\346\214\207\346\240\207\346\224\266\351\233\206\345\231\250\347\232\204\346\214\207\346\240\207\351\207\207\351\233\206\346\265\201\347\250\213.md"
+++
"b/content/zh-cn/blog/java/codeanalysis/metrics/2-\346\214\207\346\240\207\346\224\266\351\233\206\345\231\250\347\232\204\346\214\207\346\240\207\351\207\207\351\233\206\346\265\201\347\250\213.md"
@@ -17,7 +17,7 @@ description: "Dubbo 指标模块源码分析-指标收集器的指标采集流
-* **DefaultMetricsCollector
默认指标收集器**，它的样本不仅来自于指标事件，还来自其下**采样器（Sampler）**中，用于Dubbo核心模块的采样。
+* **DefaultMetricsCollector 默认指标收集器**，它的样本不仅来自于指标事件，还来自其下**采样器（Sampler）**
中，用于Dubbo核心模块的采样。
* **HistogramMetricsCollector 直方图指标收集器**，由于采样数据的特殊性，它的样本直接以 Map 存储在内部。
diff --git
"a/content/zh-cn/blog/java/codeanalysis/metrics/3-\346\214\207\346\240\207\347\233\221\345\220\254\346\263\250\345\206\214\346\242\263\347\220\206.md"
"b/content/zh-cn/blog/java/codeanalysis/metrics/3-\346\214\207\346\240\207\347\233\221\345\220\254\346\263\250\345\206\214\346\242\263\347\220\206.md"
index 57d658f9759..f842e4a99d6 100644
---
"a/content/zh-cn/blog/java/codeanalysis/metrics/3-\346\214\207\346\240\207\347\233\221\345\220\254\346\263\250\345\206\214\346\242\263\347\220\206.md"
+++
"b/content/zh-cn/blog/java/codeanalysis/metrics/3-\346\214\207\346\240\207\347\233\221\345\220\254\346\263\250\345\206\214\346\242\263\347\220\206.md"
@@ -247,7 +247,7 @@ AbstractDirectory 在修改 Invoker 状态相关的操作完成后都会通过
该事件最终会由 RegistryMetricsCollector 中的 RegistryMetricsDispatcher
转发到关系该事件的监听器中。**事件和监听器之间通过 MetricsKey匹配** 。
-最终，MetricsKey 为 `**DIRECTORY_METRIC_NUM_VALID**` 的监听器会处理这个事件，并更新 Collector中的计数。
+最终，MetricsKey 为 `**DIRECTORY_METRIC_NUM_VALID** ` 的监听器会处理这个事件，并更新
Collector中的计数。
```java
//DIRECTORY_METRIC_NUM_VALID 对应的 Listener。
@@ -349,7 +349,7 @@ public void
onChange(com.ctrip.framework.apollo.model.ConfigChangeEvent changeEv
}
```
-当Apollo配置中心的配置发生变化时，它的 `onChange` 方法会被触发，并在最后发布一个
ConfigCenterEvent。该事件最终转发到ConfigCenterMetricsCollector 中，同样增加
**CONFIGCENTER_METRIC_TOTAL **的计数。
+当Apollo配置中心的配置发生变化时，它的 `onChange` 方法会被触发，并在最后发布一个
ConfigCenterEvent。该事件最终转发到ConfigCenterMetricsCollector 中，同样增加
**CONFIGCENTER_METRIC_TOTAL** 的计数。
@@ -367,7 +367,7 @@ public void
onChange(com.ctrip.framework.apollo.model.ConfigChangeEvent changeEv
}
```
-当Nacos配置中心的配置发生变化时，它的 `innerReceive` 方法被触发，发布一个 ConfigCenterEvent。它的处理流程和
ApolloDynamicConfiguration 一致，最终增加 **CONFIGCENTER_METRIC_TOTAL **的计数。
+当Nacos配置中心的配置发生变化时，它的 `innerReceive` 方法被触发，发布一个 ConfigCenterEvent。它的处理流程和
ApolloDynamicConfiguration 一致，最终增加 **CONFIGCENTER_METRIC_TOTAL** 的计数。
@@ -418,4 +418,4 @@ private void storeProviderMetadataTask(MetadataIdentifier
providerMetadataIdenti
在前文中，我们提到 MetricsEventBus.post 的第二个参数是实际要进行的业务操作，第三个参数则是根据业务操作返回值判断操作是否成功的逻辑。
-此处的业务操作是尝试存储目标服务的元数据。执行操作之前，会先发布事件，最终增加 **STORE_PROVIDER_METADATA**
（尝试存储服务元数据次数）的计数。如果产生异常，会增加 **STORE_PROVIDER_METADATA_ERROR** （存储服务元数据失败）
的计数，否则增加**STORE_PROVIDER_METADATA_SUCCEED**（存储服务元数据成功） 的计数。
\ No newline at end of file
+此处的业务操作是尝试存储目标服务的元数据。执行操作之前，会先发布事件，最终增加 **STORE_PROVIDER_METADATA**
（尝试存储服务元数据次数）的计数。如果产生异常，会增加 **STORE_PROVIDER_METADATA_ERROR** （存储服务元数据失败）
的计数，否则增加**STORE_PROVIDER_METADATA_SUCCEED**（存储服务元数据成功） 的计数。
diff --git
a/content/zh-cn/blog/java/demos/connect-heterogeneous-microservices.md
b/content/zh-cn/blog/java/demos/connect-heterogeneous-microservices.md
index fa35e61a062..acb5945564a 100644
--- a/content/zh-cn/blog/java/demos/connect-heterogeneous-microservices.md
+++ b/content/zh-cn/blog/java/demos/connect-heterogeneous-microservices.md
@@ -48,7 +48,7 @@ public void doSayHello(String name) {
**1. 异构微服务体系共存**
-我们很容易想到的一个挑战是：**不同的体系间通常是使用不同的 RPC
通信协议、部署独立的注册中心集群，面对这种多协议、多注册中心集群的场景，要如何实现相互之间透明的地址发现和透明的 RPC
调用？**如果我们什么都不做，那么每个微服务体系就只能感知到自己体系内的服务状态，流量也在各自的体系内封闭。而要做到从体系 A 平滑的迁移到体系
B，或者想长期的保持公司内部多个体系的共存，则解决不同体系间的互联互通，实现流量的透明调度将是非常重要的环节。
+我们很容易想到的一个挑战是：**不同的体系间通常是使用不同的 RPC
通信协议、部署独立的注册中心集群，面对这种多协议、多注册中心集群的场景，要如何实现相互之间透明的地址发现和透明的 RPC 调用？**
如果我们什么都不做，那么每个微服务体系就只能感知到自己体系内的服务状态，流量也在各自的体系内封闭。而要做到从体系 A 平滑的迁移到体系
B，或者想长期的保持公司内部多个体系的共存，则解决不同体系间的互联互通，实现流量的透明调度将是非常重要的环节。
@@ -61,7 +61,7 @@ public void doSayHello(String name) {
* Dubbo
体系内部另一个常出现的问题是，在大规模分布式部署的场景下，微服务系统会做跨区域、跨注册中心的部署，这个时候就会出现多集群间地址同步和流量调度的问题。
-总结起来，**不论是同构体系还是异构体系，都面临对多协议通信、多注册中心集群地址发现的问题。**Dubbo
目前是支持多协议、多注册中心的，可以说就是为解决我们上面分析的 Dubbo
同构体系内的场景而设计的，因此下面我们从同构体系的多协议、多注册中心场景讲起，先了解 Dubbo
多协议、多注册中心的基本支持情况以及它们是如何工作的。而在后面的一章再进一步探索怎么扩展这个能力来支持异构微服务体系的互联互通。
+总结起来，**不论是同构体系还是异构体系，都面临对多协议通信、多注册中心集群地址发现的问题。** Dubbo
目前是支持多协议、多注册中心的，可以说就是为解决我们上面分析的 Dubbo
同构体系内的场景而设计的，因此下面我们从同构体系的多协议、多注册中心场景讲起，先了解 Dubbo
多协议、多注册中心的基本支持情况以及它们是如何工作的。而在后面的一章再进一步探索怎么扩展这个能力来支持异构微服务体系的互联互通。
## Dubbo 体系内的多协议、多注册中心机制
@@ -109,7 +109,8 @@ public void doSayHello(String name) {
3. 消费端应用 C
```xml
-<dubbo:reference protocol="grpc"
interface="org.apache.dubbo.samples.basic.api.DemoService3"/>
<dubbo:reference protocol="grpc"
interface="org.apache.dubbo.samples.basic.api.DemoService4"/>
+<dubbo:reference protocol="grpc"
interface="org.apache.dubbo.samples.basic.api.DemoService3"/>
+<dubbo:reference protocol="grpc"
interface="org.apache.dubbo.samples.basic.api.DemoService4"/>
<dubbo:reference protocol="dubbo"
interface="org.apache.dubbo.samples.basic.api.DemoService0"/>
@@ -157,7 +158,8 @@ Dubbo 目前所支持的协议包括 Dubbo、REST、Thrift、gRPC、JsonRPC、He
1. 服务提供端，双注册中心发布
```xml
-<dubbo:registry id="beijingRegistry"
address="zookeeper://${zookeeper.address1}" default="false"/>
<dubbo:registry
id="shanghaiRegistry" address="zookeeper://${zookeeper.address2}" />
+<dubbo:registry id="beijingRegistry"
address="zookeeper://${zookeeper.address1}" default="false"/>
+<dubbo:registry id="shanghaiRegistry"
address="zookeeper://${zookeeper.address2}" />
<dubbo:service
interface="org.apache.dubbo.samples.multi.registry.api.HelloService"
ref="helloService" registry="shanghaiRegistry,beijingRegistry"/>
<dubbo:service
interface="org.apache.dubbo.samples.multi.registry.api.DemoService"
ref="demoService" registry="shanghaiRegistry,beijingRegistry"/>
@@ -167,7 +169,8 @@ Dubbo 目前所支持的协议包括 Dubbo、REST、Thrift、gRPC、JsonRPC、He
2. 服务消费端，根据消费需求做单/双注册中心订阅
```xml
-<dubbo:registry id="beijingRegistry"
address="zookeeper://${zookeeper.address1}" default="false" preferred="true"
weight="100"/>
<dubbo:registry id="shanghaiRegistry"
address="zookeeper://${zookeeper.address2}" default="true" weight="20"/>
+<dubbo:registry id="beijingRegistry"
address="zookeeper://${zookeeper.address1}" default="false" preferred="true"
weight="100"/>
+<dubbo:registry id="shanghaiRegistry"
address="zookeeper://${zookeeper.address2}" default="true" weight="20"/>
<dubbo:reference
interface="org.apache.dubbo.samples.multi.registry.api.DemoService"/>
diff --git a/content/zh-cn/blog/java/demos/dubbo-async-client.md
b/content/zh-cn/blog/java/demos/dubbo-async-client.md
index 29bbcf4723c..9cf5eed993a 100644
--- a/content/zh-cn/blog/java/demos/dubbo-async-client.md
+++ b/content/zh-cn/blog/java/demos/dubbo-async-client.md
@@ -86,4 +86,4 @@ public class NotifyImpl implements Notify{
### 小结
* 客户端异步的出发点就是请求发出和响应处理本身为两个不同的独立事件，响应如何被处理和在哪个线程中处理等都是不需要和请求发出事件的业务逻辑线程做耦合绑定。
-*
响应事件回调的处理逻辑在哪个线程中做处理是需要根据情况来选择。建议，如果回调逻辑比较简单，建议直接在IO线程中；如果包含了远程访问或者DB访问等IO型的__同步__操作，建议在独立的线程池做处理。
+* 响应事件回调的处理逻辑在哪个线程中做处理是需要根据情况来选择。建议，如果回调逻辑比较简单，建议直接在IO线程中；如果包含了远程访问或者DB访问等IO型的
__同步__ 操作，建议在独立的线程池做处理。
diff --git
a/content/zh-cn/blog/java/demos/dubbo-consistent-hash-implementation.md
b/content/zh-cn/blog/java/demos/dubbo-consistent-hash-implementation.md
index 5ca49df9e27..69c13f87c33 100644
--- a/content/zh-cn/blog/java/demos/dubbo-consistent-hash-implementation.md
+++ b/content/zh-cn/blog/java/demos/dubbo-consistent-hash-implementation.md
@@ -103,7 +103,7 @@
dubbo:service、dubbo:reference、dubbo:provider、dubbo:consumer、dubbo:method
Dubbo实现的是客户端负载均衡。关于服务接口代理类的实现，这里不做详细描述，可以参考官网：
-> 服务引入：/zh-cn/docs/source_code_guide/refer-service.html。
+> 服务引入：/zh-cn/docs/source_code_guide/refer-service.html
在接口代理类生成、并且装配好后，服务的调用基本是这样一个流程：proxy -> MockClusterInvoker ->
集群策略（如：FailoverClusterInvoker） -> 初始化负载均衡策略 -> 根据选定的负载均衡策略确定Invoker。
diff --git a/content/zh-cn/blog/java/demos/dubbo-k8s.md
b/content/zh-cn/blog/java/demos/dubbo-k8s.md
index f4a6e91808f..4abc17e035c 100644
--- a/content/zh-cn/blog/java/demos/dubbo-k8s.md
+++ b/content/zh-cn/blog/java/demos/dubbo-k8s.md
@@ -50,7 +50,7 @@ Kubernetes是天然可作为微服务的地址注册中心，类似于Zookeeper
- 每个Service都有一个唯一的名字，及对应IP。IP是kubernetes自动分配的，名字是开发者自己定义的。
- Service的IP有几种表现形式，分别是ClusterIP，NodePort,LoadBalance,Ingress。
ClusterIP主要用于集群内通信；NodePort，Ingress，LoadBalance用于暴露服务给集群外的访问入口。
-乍一看，Kubernetes的service都是唯一的IP，在原有的Dubbo/HSF固定思维下：Dubbo/HSF的service是由整个服务集群的IP聚合而成，貌似是有本质区别的，细想下来差别不大，因为Kubernetes下的唯一IP只是一个VIP，背后挂在了多个endpoint，那才是事实上的处理节点。此处只讨论集群内的Dubbo服务在同一个kubernetes集群内访问；至于kubernetes外的consumer访问kubernetes内的provider，涉及到网络地址空间的问题，一般需要GateWay/loadbalance来做映射转换，不展开讨论。针对Kubernetes内有两种方案可选：
：
+乍一看，Kubernetes的service都是唯一的IP，在原有的Dubbo/HSF固定思维下：Dubbo/HSF的service是由整个服务集群的IP聚合而成，貌似是有本质区别的，细想下来差别不大，因为Kubernetes下的唯一IP只是一个VIP，背后挂载了多个endpoint，那才是事实上的处理节点。此处只讨论集群内的Dubbo服务在同一个kubernetes集群内访问；至于kubernetes外的consumer访问kubernetes内的provider，涉及到网络地址空间的问题，一般需要GateWay/Loadbalance来做映射转换，不展开讨论。针对Kubernetes内有两种方案可选：
：
1. DNS： 默认Kubernetes的service是靠DNS插件(最新版推荐是coreDNS)，
Dubbo上有个proposal是关于这个的。我的理解是static resolution的机制是最简单最需要支持的一种service
discovery机制，具体也可以参考Envoy在此的观点，由于HSF/Dubbo一直突出其软负载的地址发现能力，反而忽略Static的策略。同时蚂蚁的SOFA一直是支持此种策略，那一个SOFA工程的工程片段做一个解释。这样做有两个好处，1）当软负载中心crash不可用造成无法获取地址列表时，有一定的机制Failover到此策略来处理一定的请求。
2）在LDC/单元化下，蚂蚁的负载中心集群是机房/区域内收敛部署的，首先保证软负载中心的LDC化了进而稳定可控，当单元需要请求中心时，此VIP的地址发现就排上用场了。
diff --git a/content/zh-cn/blog/java/demos/dubbo-rest.md
b/content/zh-cn/blog/java/demos/dubbo-rest.md
index aab82bdaa3b..0728cfd2f26 100644
--- a/content/zh-cn/blog/java/demos/dubbo-rest.md
+++ b/content/zh-cn/blog/java/demos/dubbo-rest.md
@@ -34,7 +34,7 @@ REST 是 Roy Thomas Fielding [^1] 在 2000 年他的博士论文 [^2] “架构
-其中的思路是利用 HTTP 协议的标准方法 POST、DELETE、PUT、GET 来表达对于一个资源的增删改查 (CRUD) 操作，利用 URL
来表示一个资源的唯一标识。对资源访问的错误码也复用 HTTP 协议的状态码。返回结果通常由 json 或 XML 来表示，如果其中包换了对关联资源的访问方式
(所谓的表现层状态迁移) ，这种类型的 RESTful 应用可以进一步的称之为 *hypermedia as the engine of
application state* (HATEOAS) 应用 [^3]。
+其中的思路是利用 HTTP 协议的标准方法 POST、DELETE、PUT、GET 来表达对于一个资源的增删改查 (CRUD) 操作，利用 URL
来表示一个资源的唯一标识。对资源访问的错误码也复用 HTTP 协议的状态码。返回结果通常由 json 或 XML 来表示，如果其中包括了对关联资源的访问方式
(所谓的表现层状态迁移) ，这种类型的 RESTful 应用可以进一步的称之为 *hypermedia as the engine of
application state* (HATEOAS) 应用 [^3]。
@@ -52,7 +52,7 @@ REST 是 Roy Thomas Fielding [^1] 在 2000 年他的博士论文 [^2] “架构
### 背景
-随着微服务的流行以及多语言互操作诉求日益增多，在 Dubbo 中暴露 REST 服务变成了一个不容忽视的诉求。为了在 Dubbo 中暴露 REST
服务，通常有两种做法，一种是直接依赖 Sprng REST 或者其他 REST 框架来直接暴露，另一种是通过 Dubbo 框架内置的 REST
能力暴露。两种做法各有优缺点，主要体现在前者与微服务体系中的服务发现组件能够更好的工作，而后者可以无缝的享受到 Dubbo
体系中的服务发现以及服务治理的能力。本文关注的是如何使用后者来暴露 REST 服务。
+随着微服务的流行以及多语言互操作诉求日益增多，在 Dubbo 中暴露 REST 服务变成了一个不容忽视的诉求。为了在 Dubbo 中暴露 REST
服务，通常有两种做法，一种是直接依赖 Spring REST 或者其他 REST 框架来直接暴露，另一种是通过 Dubbo 框架内置的 REST
能力暴露。两种做法各有优缺点，主要体现在前者与微服务体系中的服务发现组件能够更好的工作，而后者可以无缝的享受到 Dubbo
体系中的服务发现以及服务治理的能力。本文关注的是如何使用后者来暴露 REST 服务。
diff --git a/content/zh-cn/blog/java/demos/dubbo-stub-mock.md
b/content/zh-cn/blog/java/demos/dubbo-stub-mock.md
index 05a9fabfd82..006aaf0f8fc 100644
--- a/content/zh-cn/blog/java/demos/dubbo-stub-mock.md
+++ b/content/zh-cn/blog/java/demos/dubbo-stub-mock.md
@@ -313,7 +313,7 @@ Caused by: org.apache.dubbo.remoting.TimeoutException:
Waiting server-side respo
[^stub-samples]:
https://github.com/apache/dubbo-samples/tree/master/2-advanced/dubbo-samples-stub
[^mock-samples]:
https://github.com/apache/dubbo-samples/tree/master/2-advanced/dubbo-samples-mock
-[^mock]: /zh-cn/docsv2.7/user/examples/local-mock/
+[^mock]: https://cn.dubbo.apache.org/zh-cn/docsv2.7/user/examples/local-mock/
diff --git
a/content/zh-cn/blog/java/demos/dubbo-supporting-grpc-http2-and-protobuf.md
b/content/zh-cn/blog/java/demos/dubbo-supporting-grpc-http2-and-protobuf.md
index 251deec7261..4fba2d8bd7a 100644
--- a/content/zh-cn/blog/java/demos/dubbo-supporting-grpc-http2-and-protobuf.md
+++ b/content/zh-cn/blog/java/demos/dubbo-supporting-grpc-http2-and-protobuf.md
@@ -28,7 +28,7 @@ description: >
相比于直接构建与 TPC 传输层的私有 RPC 协议，构建于 HTTP 之上的远程调用解决方案会有更好的通用性，如WebServices 或 REST
架构，使用 HTTP + JSON 可以说是一个事实标准的解决方案。
-之所有选择构建在 HTTP 之上，我认为有两个最大的优势：
+之所以选择构建在 HTTP 之上，我认为有两个最大的优势：
1. HTTP 的语义和可扩展性能很好的满足 RPC 调用需求。
2. 通用性，HTTP 协议几乎被网络上的所有设备所支持，具有很好的协议穿透性。
@@ -385,7 +385,7 @@ public static void main(String[] args) throws IOException {
// ...
GreeterGrpc.IGreeter greeter = (GreeterGrpc.IGreeter)
context.getBean("greeter");
ListenableFuture<HelloReply> future =
-
greeter.sayHAsyncello(HelloRequest.newBuilder().setName("world!").build());
+
greeter.sayHelloAsync(HelloRequest.newBuilder().setName("world!").build());
// ...
}
```
diff --git a/content/zh-cn/blog/java/demos/introduction-to-dubbo-spi-2.md
b/content/zh-cn/blog/java/demos/introduction-to-dubbo-spi-2.md
index 1b19b144eac..e768a03a2f0 100644
--- a/content/zh-cn/blog/java/demos/introduction-to-dubbo-spi-2.md
+++ b/content/zh-cn/blog/java/demos/introduction-to-dubbo-spi-2.md
@@ -153,7 +153,7 @@ private Map<String, Class<?>> loadExtensionClasses() {
* `META-INF/services`
2. 使用反射创建扩展实例
- 这个过程很简单，使用`clazz.newInstance())`来完成。创建的扩展实例的属性都是空值。
+ 这个过程很简单，使用`clazz.newInstance()`来完成。创建的扩展实例的属性都是空值。
3. 扩展实例自动装配
在实际的场景中，类之间都是有依赖的。扩展实例中也会引用一些依赖，比如简单的Java类，另一个Dubbo的扩展或一个Spring
Bean等。依赖的情况很复杂，Dubbo的处理也相对复杂些。我们稍后会有专门的章节对其进行说明，现在，我们只需要知道，Dubbo可以正确的注入扩展点中的普通依赖，Dubbo扩展依赖或Spring依赖等。
4. 扩展实例自动包装
@@ -191,7 +191,7 @@ private ExtensionLoader(Class<?> type) {
objectFactory = (type == ExtensionFactory.class ? null :
ExtensionLoader.getExtensionLoader(ExtensionFactory.class).getAdaptiveExtension());
}
```
-objectFacory本身也是一个扩展，通过`ExtensionLoader.getExtensionLoader(ExtensionFactory.class).getAdaptiveExtension())`来获取。
+objectFacory本身也是一个扩展，通过`ExtensionLoader.getExtensionLoader(ExtensionFactory.class).getAdaptiveExtension()`来获取。
@@ -229,7 +229,7 @@ public class AdaptiveExtensionFactory implements
ExtensionFactory {
}
}
```
-AdaptiveExtensionLoader类有@Adaptive注解。前面提到了，Dubbo会为每一个扩展创建一个自适应实例。如果扩展类上有@Adaptive，会使用该类作为自适应类。如果没有，Dubbo会为我们创建一个。所以`ExtensionLoader.getExtensionLoader(ExtensionFactory.class).getAdaptiveExtension())`会返回一个AdaptiveExtensionLoader实例，作为自适应扩展实例。
+AdaptiveExtensionLoader类有@Adaptive注解。前面提到了，Dubbo会为每一个扩展创建一个自适应实例。如果扩展类上有@Adaptive，会使用该类作为自适应类。如果没有，Dubbo会为我们创建一个。所以`ExtensionLoader.getExtensionLoader(ExtensionFactory.class).getAdaptiveExtension()`会返回一个AdaptiveExtensionLoader实例，作为自适应扩展实例。
AdaptiveExtensionLoader会遍历所有的ExtensionFactory实现，尝试着去加载扩展。如果找到了，返回。如果没有，在下一个ExtensionFactory中继续找。Dubbo内置了两个ExtensionFactory，分别从Dubbo自身的扩展机制和Spring容器中去寻找。由于ExtensionFactory本身也是一个扩展点，我们可以实现自己的ExtensionFactory，让Dubbo的自动装配支持我们自定义的组件。比如，我们在项目中使用了Google的guice这个
IOC 容器。我们可以实现自己的GuiceExtensionFactory，让Dubbo支持从guice容器中加载扩展。
## Dubbo SPI高级用法之 AOP
diff --git a/content/zh-cn/blog/java/demos/multiple-protocols-registries.md
b/content/zh-cn/blog/java/demos/multiple-protocols-registries.md
index a1dba8b8fc3..399d8aa6af1 100644
--- a/content/zh-cn/blog/java/demos/multiple-protocols-registries.md
+++ b/content/zh-cn/blog/java/demos/multiple-protocols-registries.md
@@ -61,7 +61,7 @@ public void doSayHello(String name) {
* Dubbo
体系内部另一个常出现的问题是，在大规模分布式部署的场景下，微服务系统会做跨区域、跨注册中心的部署，这个时候就会出现多集群间地址同步和流量调度的问题。
-总结起来，**不论是同构体系还是异构体系，都面临对多协议通信、多注册中心集群地址发现的问题。**Dubbo
目前是支持多协议、多注册中心的，可以说就是为解决我们上面分析的 Dubbo
同构体系内的场景而设计的，因此下面我们从同构体系的多协议、多注册中心场景讲起，先了解 Dubbo
多协议、多注册中心的基本支持情况以及它们是如何工作的。而在后面的一章再进一步探索怎么扩展这个能力来支持异构微服务体系的互联互通。
+总结起来，**不论是同构体系还是异构体系，都面临对多协议通信、多注册中心集群地址发现的问题。** Dubbo
目前是支持多协议、多注册中心的，可以说就是为解决我们上面分析的 Dubbo
同构体系内的场景而设计的，因此下面我们从同构体系的多协议、多注册中心场景讲起，先了解 Dubbo
多协议、多注册中心的基本支持情况以及它们是如何工作的。而在后面的一章再进一步探索怎么扩展这个能力来支持异构微服务体系的互联互通。
## Dubbo 体系内的多协议、多注册中心机制
