This is an automated email from the ASF dual-hosted git repository.
liubao pushed a commit to branch master
in repository https://gitbox.apache.org/repos/asf/servicecomb-docs.git
The following commit(s) were added to refs/heads/master by this push:
new d670c95 update some typo (#320)
d670c95 is described below
commit d670c95cd5450537df75c4021b615ea07e83239d
Author: liubao68 <[email protected]>
AuthorDate: Mon Jan 22 10:58:52 2024 +0800
update some typo (#320)
---
.../zh_CN/docs/config/config-service.md | 4 ++--
.../zh_CN/docs/featured-topics/secrets.md | 2 +-
.../zh_CN/docs/featured-topics/secrets/fail-fast.md | 15 ++++++++++++---
.../zh_CN/docs/featured-topics/secrets/registries.md | 9 ++++++---
4 files changed, 21 insertions(+), 9 deletions(-)
diff --git a/java-chassis-reference/zh_CN/docs/config/config-service.md
b/java-chassis-reference/zh_CN/docs/config/config-service.md
index 25e84ff..02988ee 100644
--- a/java-chassis-reference/zh_CN/docs/config/config-service.md
+++ b/java-chassis-reference/zh_CN/docs/config/config-service.md
@@ -117,7 +117,7 @@ servicecomb:
## 使用 Apollo
->>> 注意：本实现注意作为适配 Apollo 的参考。不建议在生产环境使用。 如果在生产环境使用，建议基于 Apollo 提供的 SDK 自行扩展实现。
+>>> 注意：本实现作为适配 Apollo 的参考，整体逻辑功能和设计规格不完善，不建议在生产环境使用。 如果在生产环境使用，建议基于 Apollo 提供的
SDK 自行扩展实现。
[Apollo](https://github.com/ctripcorp/apollo) 是携程框架部门研发的分布式配置中心。
Apollo的下载安装请参考官网介绍。
@@ -149,7 +149,7 @@ apollo:
华为云CSE1.0配置中心是华为云CSE产品的一个部件，java-chassis 最早使用它作为配置中心。 对接这个配置中心的代码在 config-cc
模块实现。
-可以从[轻量化微服务引擎](https://cse-bucket.obs.myhwclouds.com/LocalCSE/Local-CSE-1.0.3.zip)下载本地使用的版本。也可以
+可以从
[轻量化微服务引擎](https://cse-bucket.obs.myhwclouds.com/LocalCSE/Local-CSE-1.0.3.zip)
下载本地使用的版本。也可以
直接访问华为云 [ServiceStage](https://console.huaweicloud.com/servicestage)
产品，使用在线的版本。
使用华为云配置中心，需要在项目中引入如下依赖：
diff --git a/java-chassis-reference/zh_CN/docs/featured-topics/secrets.md
b/java-chassis-reference/zh_CN/docs/featured-topics/secrets.md
index 8607954..41309d2 100644
--- a/java-chassis-reference/zh_CN/docs/featured-topics/secrets.md
+++ b/java-chassis-reference/zh_CN/docs/featured-topics/secrets.md
@@ -6,6 +6,6 @@
* [Java Chassis 3技术解密：熔断机制的改进路程](secrets/circuit-breaker.md)
* [Java Chassis 3技术解密：过载状态下的快速失败](secrets/fail-fast.md)
* [Java Chassis 3技术解密：应用视角的配置管理](secrets/applied-config.md)
-* [Java Chassis 3技术解密：多种注册中心支持](secrets/registries.md)
+* [Java Chassis 3技术解密：易扩展的多种注册中心支持](secrets/registries.md)
* [Java Chassis 3技术解密：与Spring Cloud的互操作](secrets/interoperability.md)
diff --git
a/java-chassis-reference/zh_CN/docs/featured-topics/secrets/fail-fast.md
b/java-chassis-reference/zh_CN/docs/featured-topics/secrets/fail-fast.md
index 5785fe4..bd90f22 100644
--- a/java-chassis-reference/zh_CN/docs/featured-topics/secrets/fail-fast.md
+++ b/java-chassis-reference/zh_CN/docs/featured-topics/secrets/fail-fast.md
@@ -51,9 +51,9 @@ servicecomb:
相比较于单位时间内请求数，
当前正在处理的请求数能够很好的反馈当前的系统繁忙程度，因为一个请求的时延增加，会导致当前正在处理的请求数增加。对于CPU密集型任务，
可以设置稍微小一点的值；对于IO密集型任务，可以设置稍微大一点的值。
-## 线程池队列
+## 线程池队列和连接池队列
-在线程池入队和出队的时候，进行快速失败，也是非常常用而且比较有效的手段。 但是这类机制不适用于edge service纯异步工作模式场景，
更加适合于微服务的同步工作模式。
+在线程池入队和出队的时候，进行快速失败，也是非常常用而且比较有效的手段。
```yaml
servicecomb:
@@ -71,7 +71,16 @@ servicecomb:
requestWaitInPoolTimeout: 1000
```
-Java Chassis在出队的时候，也会检测任务等待的时间。 如果等待时间过长， 也会立即拒绝改任务，避免额外的处理资源浪费。
+Java Chassis在出队的时候，也会检测任务等待的时间。 如果等待时间过长， 也会立即拒绝该任务，避免额外的处理资源浪费。
+
+线程池队列不适用于edge service或者采用reactive定义接口的场景，
在reactive模式，通常的竞争资源是连接池，可以通过如下配置项控制连接池等待队列：
+
+```yaml
+servicecomb:
+ rest:
+ client:
+ maxWaitQueueSize: 100
+```
## 全局的超时检测
diff --git
a/java-chassis-reference/zh_CN/docs/featured-topics/secrets/registries.md
b/java-chassis-reference/zh_CN/docs/featured-topics/secrets/registries.md
index e248970..2521fdb 100644
--- a/java-chassis-reference/zh_CN/docs/featured-topics/secrets/registries.md
+++ b/java-chassis-reference/zh_CN/docs/featured-topics/secrets/registries.md
@@ -1,4 +1,4 @@
-# Java Chassis 3技术解密：多种注册中心支持
+# Java Chassis 3技术解密：易扩展的多种注册中心支持
Java Chassis 的早期版本依赖于 Service Center，提供了很多差异化的竞争力：
@@ -7,7 +7,7 @@ Java Chassis 的早期版本依赖于 Service Center，提供了很多差异化
Java Chassis过度依赖 Service Center， 为产品的发展带来了一些瓶颈。 Java Chassis的生态推广依赖于 Service
Center的生态推广， 不利于Java Chassis被更多用户使用。 随着云的发展，
越来越多的客户也期望一套代码，能够在不同的云环境运行，有些云产商未提供Service Center运行环境，那么用户选择Java Chassis
就会存在顾虑。
-基于上述原因， Java Chassis简化了注册发现的依赖，定义了简单容易实现的接口，并基于 `Nacos` 提供了实现，未来还会提供
`zookeeper` 等实现。 Java Chassis 采用了一些列新的设计模式， 保证了在降低注册中心功能依赖的前提下，不降低应用自身的可靠性。
+基于上述原因， Java Chassis简化了注册发现的依赖，定义了简单容易实现的接口，并基于 `Nacos` 提供了实现，未来还会提供
`zookeeper` 等实现。 Java Chassis 采用了一系列新的设计模式， 保证了在降低注册中心功能依赖的前提下，不降低应用自身的可靠性。
## 接口级别转发的替代方案
@@ -136,7 +136,7 @@ public interface Registration<R extends
RegistrationInstance> extends SPIEnabled
## 注册发现的组合
-Java Chassis 3可以独立实现多个 `Discovery` 和 `Registration`,
达到向多个注册中心注册和从多个注册中心发现实例的作用。 每个实例根据实例ID唯一来标识。 如果实例ID相同， 会被认为是同一个实例， 如果不同，
则会认为是不同的实例。 在 `Java Chassis 3技术解密：注册中心分区隔离` 中聊到了， Java Chassis 要求每次实例注册（新的进程），
生成唯一的实例ID， 以解决注册分区隔离带来的实例假下线问题。
+Java Chassis 3可以独立实现多个 `Discovery` 和 `Registration`,
达到向多个注册中心注册和从多个注册中心发现实例的作用。 每个实例根据实例ID唯一来标识。 如果实例ID相同， 会被认为是同一个实例， 如果不同，
则会认为是不同的实例。 在 `Java Chassis 3技术解密：注册中心分区隔离` 中聊到了， Java Chassis 要求每次实例注册（新的进程），
生成唯一的实例ID， 以解决注册分区隔离带来的实例假下线问题。 `Discovery` 和 `Registration` 都包含了 Java Chassis
定义的基础信息。
```java
/**
@@ -217,3 +217,6 @@ public interface MicroserviceInstance {
```
+在实现注册发现的时候，需要保证该接口定义的基础信息能够注册到注册中心，查询实例的时候，能够获取到这些信息。
+
+>>>
客户故事：不把鸡蛋放到同一个篮子里面，是技术选型里面很重要的考量。解决方案的开放性和可替代性、云服务的可替代性，是很多客户都关注的问题。对于一个开源的技术框架，Java
Chassis早期的版本虽然设计上也支持不同的注册中心扩展，但是实现难度很高，不自觉的把客户使用其他注册中心替换 service
center的要求变得不可行。提供更加简化的注册发现实现，虽然减少了少量有有竞争力的功能特性，但是极大降低了客户选型的顾虑。
