You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@servicecomb.apache.org by li...@apache.org on 2020/02/12 02:35:09 UTC
[servicecomb-docs] branch master updated: fix image link problem
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 4451d33 fix image link problem
4451d33 is described below
commit 4451d337638fb2f0600fcabe45e3bccfc55478d4
Author: liubao <bi...@qq.com>
AuthorDate: Wed Feb 12 10:22:22 2020 +0800
fix image link problem
---
java-chassis-reference/en_US/docs/build-provider/thread-pool.md | 2 +-
java-chassis-reference/en_US/docs/edge/by-servicecomb-sdk.md | 8 ++++----
java-chassis-reference/en_US/docs/general-development/metrics.md | 2 +-
.../en_US/docs/general-development/multienvironment.md | 8 ++++----
java-chassis-reference/en_US/docs/general-development/reactive.md | 8 ++++----
.../en_US/docs/general-development/thread-model.md | 4 ++--
.../en_US/docs/references-handlers/loadbalance.md | 2 +-
java-chassis-reference/en_US/docs/start/architecture.md | 2 +-
java-chassis-reference/en_US/docs/transports/verticle-count.md | 2 +-
.../using-java-chassis-in-spring-boot.md | 4 ++--
java-chassis-reference/en_US/mkdocs.yml | 1 +
java-chassis-reference/zh_CN/docs/build-provider/thread-pool.md | 2 +-
java-chassis-reference/zh_CN/docs/edge/by-servicecomb-sdk.md | 8 ++++----
.../zh_CN/docs/general-development/local-develop-test.md | 4 ++--
java-chassis-reference/zh_CN/docs/general-development/metrics.md | 2 +-
.../zh_CN/docs/general-development/multienvironment.md | 8 ++++----
java-chassis-reference/zh_CN/docs/general-development/reactive.md | 8 ++++----
.../zh_CN/docs/general-development/thread-model.md | 4 ++--
.../zh_CN/docs/references-handlers/loadbalance.md | 2 +-
java-chassis-reference/zh_CN/docs/start/architecture.md | 2 +-
java-chassis-reference/zh_CN/docs/transports/verticle-count.md | 2 +-
.../using-java-chassis-in-spring-boot.md | 4 ++--
java-chassis-reference/zh_CN/mkdocs.yml | 1 +
23 files changed, 46 insertions(+), 44 deletions(-)
diff --git a/java-chassis-reference/en_US/docs/build-provider/thread-pool.md b/java-chassis-reference/en_US/docs/build-provider/thread-pool.md
index 2bf4d50..8506e70 100644
--- a/java-chassis-reference/en_US/docs/build-provider/thread-pool.md
+++ b/java-chassis-reference/en_US/docs/build-provider/thread-pool.md
@@ -27,7 +27,7 @@ If the business has special requirements, you can specify to use a custom global
## ServiceComb built-in thread pool
In a general thread pool, all threads share a task queue. In this case, all network threads need to apply for the same queue to join the queue. All threads in the thread pool need to grab the task from the same queue. Throughput scenarios, which can lead to competitive conflicts and create performance bottlenecks
Therefore, in order to improve performance, ServiceComb's built-in thread pool is actually a wrapper of real thread pools, allowing multiple sets of thread pools to be configured inside, and each network thread is bound to a set of thread pools to reduce contention conflicts.
-
+
* Before version 1.2.0
diff --git a/java-chassis-reference/en_US/docs/edge/by-servicecomb-sdk.md b/java-chassis-reference/en_US/docs/edge/by-servicecomb-sdk.md
index b849ac6..30ebcae 100644
--- a/java-chassis-reference/en_US/docs/edge/by-servicecomb-sdk.md
+++ b/java-chassis-reference/en_US/docs/edge/by-servicecomb-sdk.md
@@ -58,7 +58,7 @@ servicecomb:
The workflow of the Edge Service is as follows, the blue background part is executed in the Eventloop thread, and the yellow background part:
* If working in reactive mode, execute directly in the Eventloop thread
* If working in thread pool mode, execute in the thread pool thread
-
+
## Custom routing rules
The core job of using the Edge Service is to configure routing rules. The rules are different, and the rules are different.
@@ -139,7 +139,7 @@ Through the Edge Service workflow, you can see that the Edge Service features ca
## Deployment example
-
+
## Operating mode
@@ -157,7 +157,7 @@ The Edge Service works by default in the high-performance reactive mode. This mo
The underlying Edge Service is based on netty's vertx. The above constraint is netty's reactive mode constraint.
-
+
### Thread Pool
@@ -173,7 +173,7 @@ servicecomb:
Here servicecomb.executor.groupThreadPool is the beanId of the spring bean corresponding to the default thread pool built into ServiceComb; the service can customize its thread pool and declare it as a bean whose beanId can also be configured here.
-
+
## DEMO Function Description
diff --git a/java-chassis-reference/en_US/docs/general-development/metrics.md b/java-chassis-reference/en_US/docs/general-development/metrics.md
index 12ac160..d54a409 100644
--- a/java-chassis-reference/en_US/docs/general-development/metrics.md
+++ b/java-chassis-reference/en_US/docs/general-development/metrics.md
@@ -1,6 +1,6 @@
# First, the introduction of Metrics
-
+
1. Based on [netflix spectator](https://github.com/Netflix/spectator)
2. Foundation-metrics loads all MetricsInitializer implementations via the SPI mechanism. Implementers can use the getOrder in the MetricsInitializer to plan the execution order. The smaller the order number, the earlier it will be executed.
diff --git a/java-chassis-reference/en_US/docs/general-development/multienvironment.md b/java-chassis-reference/en_US/docs/general-development/multienvironment.md
index 0741e23..e498327 100644
--- a/java-chassis-reference/en_US/docs/general-development/multienvironment.md
+++ b/java-chassis-reference/en_US/docs/general-development/multienvironment.md
@@ -6,7 +6,7 @@ When doing service discovery, developers need to understand that the microservic
To understand the isolation level between instances, you first need to understand a well-established microservice system structure defined by ServiceComb:
-
+
In the microservice system structure, the top layer is the “project”, which is divided into multiple tenants under the project. The tenant contains multiple applications, and each application contains multiple environments, that is, the test and production environments can be separated. In a particular environment of a particular application, there are multiple microservices, and one microservice can have multiple versions at the same time. The above is the scope of all static metadata. [...]
* Project corresponds to the project created under each region of Huawei cloud. Different projects are isolated from each other. If there is no new project under the region, it represents the region; for example, create a project named tianjing in North China (cn-north-1), if you want to register the microservice to the project, you can configure it in the microservice.yaml file：
@@ -29,7 +29,7 @@ In the microservice system structure, the top layer is the “project”, which
In the ServiceComb framework, an application contains multiple microservices.
The same microservice instance can be deployed as a public service to multiple applications by specifying a different APPLICATION_ID.
-
+
Different microservice instances, by default, are only allowed to call each other in the same application. When users need to call microservices between different applications, they need to enable cross-application calling.
### Configuration instructions:
@@ -65,7 +65,7 @@ hello.sayHello(“ServiceComb”);
### Function introduction
By setting the environment, the ServiceComb framework can mark microservice instances as development, testing, acceptance, and production environments, and achieve natural isolation at the instance level. When the client looks for a server instance, it can only find server instance under the same environment.
-
+
ServiceComb is strictly dependent on the contract when designing, so under normal circumstances, the contract has changed, you must modify the version of the microservice. However, if current is still development mode, then modify the interface is a very normal situation, when the modification is completed and the current service is started again, the newly generated contract and the old contract saved on the Service Center will conflict and report an error, causing the startup to fail, [...]
The ServiceComb framework supports rapid debugging of microservices in the development state by configuring the environment as development. When the interface is modified (the schema has changed), restart can be registered to the service center without modifying the version number.
@@ -86,7 +86,7 @@ Only the following enumerated values are supported: development, testing, accept
In the scenario of deploying services across regions in a three centers in two places solution, the same services exists in multiple availableZones. It is necessary to implement the application in the same AZ with priority. If there is a problem with the same AZ, it must be able to access another AZ. To ensure the reliability of the service.
ServiceComb provides data center configuration to partition and manage microservices. The data center contains three attributes: servicecomb.datacenter.name, servicecomb.datacenter.region, servicecomb.datacenter.availableZone, data center information does not provide isolation capabilities, and microservices can discover instances of other data centers. However, you can prioritize sending messages to a specified zone or zone by enabling instance affinity.
-
+
When the client is routing, the request will be forwarded to the instance with the same zone/region, and then the instance with the same region but different zones. When they are all different, select one according to the routing rules. Affinity is not logical isolation. As long as the network between the instances is interconnected, it is possible to access it; if the network is unreachable, the access will fail.
When the cloud is deployed on the Huawei cloud, the values of the region and the availableZone can be associated with the Huawei cloud region (for example, cn-north-1) and the available region. However, because the different regions on the Huawei cloud do not communicate with each other, the network is not interconnected, so it does not support cross-region access; in addition to the region value corresponding to Huawei cloud, you can also define other values by yourself, and adjust acco [...]
diff --git a/java-chassis-reference/en_US/docs/general-development/reactive.md b/java-chassis-reference/en_US/docs/general-development/reactive.md
index ab917af..f37f3bf 100644
--- a/java-chassis-reference/en_US/docs/general-development/reactive.md
+++ b/java-chassis-reference/en_US/docs/general-development/reactive.md
@@ -11,7 +11,7 @@ public String hello(@PathVariable(name = "name") String name){
The corresponding processing flow is as follows:
-
+
This is the traditional typical working model. The core idea is not to block network threads, and to put the business in a separate thread (to simplify the expression, only one thread is drawn in the executor)
@@ -36,7 +36,7 @@ public String hello(@PathVariable(name = "name") String name){
The corresponding processing flow is as follows:
-
+
According to the characteristics of this process, you can see the following results:
@@ -58,7 +58,7 @@ For the previous scenario, someone would think that throwing the "Invoke produce
Form the following process:
-
+
According to the characteristics of this process, you can see the following results:
@@ -96,7 +96,7 @@ public CompletableFuture<String> hello(@PathVariable(name = "name") String name)
The corresponding processing flow is as follows:
-
+
* Unlike traditional processes, all functions are executed in the eventloop and no thread switching is performed.
diff --git a/java-chassis-reference/en_US/docs/general-development/thread-model.md b/java-chassis-reference/en_US/docs/general-development/thread-model.md
index bdae92d..d6d167e 100644
--- a/java-chassis-reference/en_US/docs/general-development/thread-model.md
+++ b/java-chassis-reference/en_US/docs/general-development/thread-model.md
@@ -2,11 +2,11 @@
## Threading model in synchronous mode
-
+
## Threading model in reactive mode
-
+
Thread related configuration：
* [REST over Vertx](/build-provider/protocol/rest-over-vertx.md)
diff --git a/java-chassis-reference/en_US/docs/references-handlers/loadbalance.md b/java-chassis-reference/en_US/docs/references-handlers/loadbalance.md
index 58dfcf9..5155622 100644
--- a/java-chassis-reference/en_US/docs/references-handlers/loadbalance.md
+++ b/java-chassis-reference/en_US/docs/references-handlers/loadbalance.md
@@ -5,7 +5,7 @@
ServiceComb provides very powerful load balancing capabilities, which consists of two core parts. The first part DiscoveryTree, whose core part is DiscoveryFilter, groups microservice instances by their interface compatibility, data center, status, etc. The second part is the load balancing scheme based on Ribbon, which supports various load balancing policies(IRule) include random, sequential, response time-based weights, and ServerListFilterExt which is based on Invocation state.
DiscoveryTree's logic is more complex, its processing progress is as below:
-
+
Load balancing can be configured in the Consumer processing chain, the handler name is loadbalance, as follows:
diff --git a/java-chassis-reference/en_US/docs/start/architecture.md b/java-chassis-reference/en_US/docs/start/architecture.md
index a8cf3e8..167ca44 100644
--- a/java-chassis-reference/en_US/docs/start/architecture.md
+++ b/java-chassis-reference/en_US/docs/start/architecture.md
@@ -1,6 +1,6 @@
# Java Chassis Architecture
## Basic Framework
-
+
## Purpose
diff --git a/java-chassis-reference/en_US/docs/transports/verticle-count.md b/java-chassis-reference/en_US/docs/transports/verticle-count.md
index 84a5e9d..8393bac 100644
--- a/java-chassis-reference/en_US/docs/transports/verticle-count.md
+++ b/java-chassis-reference/en_US/docs/transports/verticle-count.md
@@ -18,6 +18,6 @@
## The relationship between Eventloop and verticle instances:
Assuming the CPU is 2, vertx creates 2 * CPU by default, ie 4 Eventloop threads.
Assuming the configuration server verticle count and client verticle count are both 3, then:
-
+
Because it is not allowed to perform any blocking action in the Eventloop, combined with the above figure, we can know that when the CPU is fully utilized, it is meaningless to add the verticle instance.
Users are advised to combine their actual scenarios to test and summarize the appropriate configuration values.
\ No newline at end of file
diff --git a/java-chassis-reference/en_US/docs/using-java-chassis-in-spring-boot/using-java-chassis-in-spring-boot.md b/java-chassis-reference/en_US/docs/using-java-chassis-in-spring-boot/using-java-chassis-in-spring-boot.md
index e782023..e8c4cac 100644
--- a/java-chassis-reference/en_US/docs/using-java-chassis-in-spring-boot/using-java-chassis-in-spring-boot.md
+++ b/java-chassis-reference/en_US/docs/using-java-chassis-in-spring-boot/using-java-chassis-in-spring-boot.md
@@ -18,13 +18,13 @@
* JAVA应用方式
-
+
这种集成方式相对简单，相当于直接将java chassis通过Spring Boot应用拉起，不涉及任何改造和变化。
* Web开发方式
-
+
该集成方式的本质是将Spring MVC的DispatcherServlet替换为java chassis的RestServlet。
diff --git a/java-chassis-reference/en_US/mkdocs.yml b/java-chassis-reference/en_US/mkdocs.yml
index a0c9dc7..7f9b32e 100644
--- a/java-chassis-reference/en_US/mkdocs.yml
+++ b/java-chassis-reference/en_US/mkdocs.yml
@@ -66,6 +66,7 @@ nav:
- General config: config/general-config.md
- Configuration injection: config/inject-config.md
- Service Capability Open:
+ - Intruductions: edge/open-service.md
- Using Edge Service: edge/by-servicecomb-sdk.md
- Using confd and Nginx as edge services: edge/nginx.md
- Use zuul as edge services: edge/zuul.md
diff --git a/java-chassis-reference/zh_CN/docs/build-provider/thread-pool.md b/java-chassis-reference/zh_CN/docs/build-provider/thread-pool.md
index 6d25efe..209fdab 100644
--- a/java-chassis-reference/zh_CN/docs/build-provider/thread-pool.md
+++ b/java-chassis-reference/zh_CN/docs/build-provider/thread-pool.md
@@ -27,7 +27,7 @@
## ServiceComb内置线程池
一般的线程池都是所有线程共享一个任务队列，在这种情况下，所有网络线程需要向同一个队列申请请求入队，线程池中的所有线程需要从同一个队列中抢任务执行，对于高吞吐的场景，这会导致竞争冲突，形成性能瓶颈
所以，为了提升性能，ServiceComb内置线程池实际是真正线程池的包装，允许在其内部配置多组线程池，且每个网络线程绑定一组线程池，以减小竞争冲突
-
+
* 1.2.0之前的版本
diff --git a/java-chassis-reference/zh_CN/docs/edge/by-servicecomb-sdk.md b/java-chassis-reference/zh_CN/docs/edge/by-servicecomb-sdk.md
index 9573eb4..0869b77 100644
--- a/java-chassis-reference/zh_CN/docs/edge/by-servicecomb-sdk.md
+++ b/java-chassis-reference/zh_CN/docs/edge/by-servicecomb-sdk.md
@@ -59,7 +59,7 @@ servicecomb:
Edge Service的工作流程如下，蓝色背景部分在Eventloop线程中执行，黄色背景部分：
* 如果工作于reactive模式，则直接在Eventloop线程执行
* 如果工作于线程池模式，则在线程池的线程中执行
-
+
## 定制路由规则
使用Edge Service的核心工作是配置路由规则。场景不同，规则也不同。
@@ -140,7 +140,7 @@ businessV1配置项表示的含义是将请求路径为/usr/business/v1/.*的请
## 部署示例
-
+
## 工作模式
@@ -158,7 +158,7 @@ Edge Service默认工作于高性能的reactive模式，此模式要求工作于
Edge Service的底层是基于netty的vertx，以上约束即是netty的reactive模式约束。
-
+
### 线程池
@@ -174,7 +174,7 @@ servicecomb:
这里的servicecomb.executor.groupThreadPool是ServiceComb内置的默认线程池对应的spring bean的beanId；业务可以定制自己的线程池，并声明为一个bean，其beanId也可以配置到这里。
-
+
## DEMO功能说明
diff --git a/java-chassis-reference/zh_CN/docs/general-development/local-develop-test.md b/java-chassis-reference/zh_CN/docs/general-development/local-develop-test.md
index bda27ca..d58d56f 100644
--- a/java-chassis-reference/zh_CN/docs/general-development/local-develop-test.md
+++ b/java-chassis-reference/zh_CN/docs/general-development/local-develop-test.md
@@ -9,7 +9,7 @@
* 通过设置环境信息方便本地调试
服务中心是微服务框架中的重要组件，用于服务元数据以及服务实例元数据的管理和处理注册、发现。服务中心与微服务提供/消费者的逻辑关系下图所示：
-
+
## 启动本地服务中心
@@ -120,4 +120,4 @@ service_description:
```
* 方法3：通过环境变量来指定（仅限于Windows系统），比如在Eclipse下面进行如下设置
-
+
diff --git a/java-chassis-reference/zh_CN/docs/general-development/metrics.md b/java-chassis-reference/zh_CN/docs/general-development/metrics.md
index f25f999..d925555 100644
--- a/java-chassis-reference/zh_CN/docs/general-development/metrics.md
+++ b/java-chassis-reference/zh_CN/docs/general-development/metrics.md
@@ -1,6 +1,6 @@
# 一、Metrics介绍
-
+
1. 基于[netflix spectator](https://github.com/Netflix/spectator)
2. Foundation-metrics通过SPI机制加载所有MetricsInitializer实现，实现者可以通过MetricsInitializer中的getOrder规划执行顺序，order数字越小，越先执行。
diff --git a/java-chassis-reference/zh_CN/docs/general-development/multienvironment.md b/java-chassis-reference/zh_CN/docs/general-development/multienvironment.md
index 4860d52..70e67f4 100644
--- a/java-chassis-reference/zh_CN/docs/general-development/multienvironment.md
+++ b/java-chassis-reference/zh_CN/docs/general-development/multienvironment.md
@@ -6,7 +6,7 @@
要了解实例间的隔离层次，首先需要了解ServiceComb定义的一个体系完备的微服务系统结构：
-
+
在微服务系统结构中，顶层是项目（project），项目中的应用分属于不同环境（environment），即测试和生产环境可以分开，每个环境下包含多个应用（application），在某个特定应用的特定环境中，包含多个微服务（service），一个微服务又可以同时存在多个版本（version）。
以上，是所有静态元数据的范畴，某个特定服务的特定版本则包含多个在运行时注册上来的微服务实例，因为服务实例的信息在运行时随着系统的伸缩、故障等原因是动态变化的，所以服务实例的路由信息又为动态数据。通过分层管理微服务的这些数据，也就自然而然地实现了实例之间的逻辑隔离。
@@ -30,7 +30,7 @@
在ServiceComb框架中，一个应用下包含多个微服务。
同一个微服务实例，可以作为公共服务部署到多个应用，通过指定不同的APPLICATION_ID来实现。
-
+
不同的微服务实例，默认情况下，只允许在同一个应用里相互调用，当用户需要不同应用间的微服务相互调用时，就需要开启跨应用调用功能。
### 配置说明：
@@ -66,7 +66,7 @@ hello.sayHello(“ServiceComb”);
### 功能介绍
ServiceComb框架通过设置environment，可以将微服务实例标记为开发、测试、预生产、生产环境，实现了在实例级别的天然隔离；客户端在查找服务端实例的时候，只能发现相同environment下的服务端实例。
-
+
ServiceComb在设计时，严格依赖于契约，所以正常情况下契约变了，就必须要修改微服务的版本。但是如果当前还是开发模式，那么修改接口就是很正常的情况，当修改完毕再次启动当前服务时，新生成的契约和Service Center上保存的旧契约会冲突并报错，导致启动失败，如果每次都通过修改微服务版本号，或者删除该服务在Service Center上的缓存数据来解决，显然对开发人员很不友好。
ServiceComb框架支持在开发态进行微服务的快速调试，通过将environment配置为development即可。当接口修改了（Schema发生了变化），重启就可以正常注册到服务中心，而不用修改版本号。
@@ -87,7 +87,7 @@ ServiceComb框架支持在开发态进行微服务的快速调试，通过将env
在以两地三中心的解决方案进行跨地区部署服务的场景，同一套服务存在于多个availableZone中，需要实现优先调用同一个AZ内的应用，若本AZ出现问题，要能够访问另一个AZ下的应用，从而保证服务的可靠性。
ServiceComb提供了数据中心配置，来实现对微服务的分区和管理。数据中心包含3个属性：servicecomb.datacenter.name, servicecomb.datacenter.region, servicecomb.datacenter.availableZone，数据中心信息不提供隔离能力，微服务可以发现其他数据中心的实例。但是可以通过启用实例亲和性，来优先往指定的区域或者Zone发消息。
-
+
客户端在路由的时候，会优先将请求转发到zone/region都相同的实例，然后是region相同，但zone不相同的实例，都不相同的时候，则按照路由规则选择一个。亲和性不是逻辑隔离，只要实例之间网络是联通的，那么都有可能访问到；如果网络不通，则会访问失败。
在华为云上部署时，可将region和availableZone的值与华为云的region（例如：cn-north-1）和可用区对应起来，但是因为华为云上的不同region目前网络不互通，所以此时不支持跨region访问；除了对应华为云的region值，也可以自行定义其他值，根据实际情况作相应调整，非常灵活。
diff --git a/java-chassis-reference/zh_CN/docs/general-development/reactive.md b/java-chassis-reference/zh_CN/docs/general-development/reactive.md
index dd167eb..57ca0a5 100644
--- a/java-chassis-reference/zh_CN/docs/general-development/reactive.md
+++ b/java-chassis-reference/zh_CN/docs/general-development/reactive.md
@@ -11,7 +11,7 @@ public String hello(@PathVariable(name = "name") String name){
与此对应的处理流程如下：
-
+
这是传统典型的工作模型，核心思想是不阻塞网络线程，将业务放在独立的线程中处理（为了简化表达，executor中只画一个线程）
@@ -36,7 +36,7 @@ public String hello(@PathVariable(name = "name") String name){
与此对应的处理流程如下：
-
+
根据这个流程的特点，可以看到会产生以下结果：
@@ -58,7 +58,7 @@ public String hello(@PathVariable(name = "name") String name){
形成以下流程：
-
+
根据这个流程的特点，可以看到会产生以下结果：
@@ -96,7 +96,7 @@ public CompletableFuture<String> hello(@PathVariable(name = "name") String name)
与此对应的处理流程如下：
-
+
* 与传统流程不同的是，所有功能都在eventloop中执行，并不会进行线程切换
diff --git a/java-chassis-reference/zh_CN/docs/general-development/thread-model.md b/java-chassis-reference/zh_CN/docs/general-development/thread-model.md
index 6a0fd01..f59f65a 100644
--- a/java-chassis-reference/zh_CN/docs/general-development/thread-model.md
+++ b/java-chassis-reference/zh_CN/docs/general-development/thread-model.md
@@ -6,11 +6,11 @@
## 同步模式下的线程模型
-
+
## reactive模式下的线程模型
-
+
线程相关配置：
* [REST over Vertx](/transports/rest-over-vertx.md)
diff --git a/java-chassis-reference/zh_CN/docs/references-handlers/loadbalance.md b/java-chassis-reference/zh_CN/docs/references-handlers/loadbalance.md
index bd8065b..a708347 100644
--- a/java-chassis-reference/zh_CN/docs/references-handlers/loadbalance.md
+++ b/java-chassis-reference/zh_CN/docs/references-handlers/loadbalance.md
@@ -5,7 +5,7 @@
ServiceComb提供了非常强大的负载均衡能力。它的核心包括两部分，第一部分是DiscoveryTree，通过将微服务实例根据接口兼容性、数据中心、实例状态等分组，DiscoveryFilter是其主要组成部分；第二部分是基于Ribbon的负载均衡方案，支持随机、顺序、基于响应时间的权值等多种负载均衡路由策略IRule，以及可以支持Invocation状态的ServerListFilterExt。
DiscoveryTree的逻辑比较复杂，可以通过下面的处理流程了解其处理过程。
-
+
负载均衡适用于Consumer处理链，名称为loadbalance，示例如下：
```yaml
diff --git a/java-chassis-reference/zh_CN/docs/start/architecture.md b/java-chassis-reference/zh_CN/docs/start/architecture.md
index 33c5b3a..a78d0ce 100644
--- a/java-chassis-reference/zh_CN/docs/start/architecture.md
+++ b/java-chassis-reference/zh_CN/docs/start/architecture.md
@@ -1,6 +1,6 @@
# 微服务系统架构
-## 框架概述
+## 框架概述
## **主要设计意图**
diff --git a/java-chassis-reference/zh_CN/docs/transports/verticle-count.md b/java-chassis-reference/zh_CN/docs/transports/verticle-count.md
index 711b46f..41b4c63 100644
--- a/java-chassis-reference/zh_CN/docs/transports/verticle-count.md
+++ b/java-chassis-reference/zh_CN/docs/transports/verticle-count.md
@@ -18,6 +18,6 @@
## Eventloop与verticle实例的关系：
假设CPU为2，则vertx默认创建2 * CPU， 即4个Eventloop线程
假设配置server verticle count和client verticle count均为3，则：
-
+
因为在Eventloop中不允许执行任何阻塞动作，再结合上图，我们可以知道，当充分利用了CPU之后，再增加verticle实例是没有意义的
建议使用者结合自己的实际场景，测试总结出合适的配置值
\ No newline at end of file
diff --git a/java-chassis-reference/zh_CN/docs/using-java-chassis-in-spring-boot/using-java-chassis-in-spring-boot.md b/java-chassis-reference/zh_CN/docs/using-java-chassis-in-spring-boot/using-java-chassis-in-spring-boot.md
index 2ef5dbb..be35e93 100644
--- a/java-chassis-reference/zh_CN/docs/using-java-chassis-in-spring-boot/using-java-chassis-in-spring-boot.md
+++ b/java-chassis-reference/zh_CN/docs/using-java-chassis-in-spring-boot/using-java-chassis-in-spring-boot.md
@@ -22,13 +22,13 @@
* JAVA应用方式
-
+
这种集成方式相对简单，相当于直接将java-chassis通过Spring Boot应用拉起，通过java-chassis 提供REST/RPC服务。
* Web开发方式
-
+
该集成方式的本质是将Spring MVC的DispatcherServlet替换为java chassis的RestServlet，通过java-chassis提供REST/RPC服务。
diff --git a/java-chassis-reference/zh_CN/mkdocs.yml b/java-chassis-reference/zh_CN/mkdocs.yml
index 408d330..2f14bec 100644
--- a/java-chassis-reference/zh_CN/mkdocs.yml
+++ b/java-chassis-reference/zh_CN/mkdocs.yml
@@ -66,6 +66,7 @@ nav:
- 通用配置说明: config/general-config.md
- 配置注入说明: config/inject-config.md
- 服务能力开放:
+ - 介绍: edge/open-service.md
- 使用Edge Service做边缘服务: edge/by-servicecomb-sdk.md
- 使用confd和Nginx做边缘服务: edge/nginx.md
- 使用zuul做边缘服务: edge/zuul.md