You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@servicecomb.apache.org by ni...@apache.org on 2017/12/25 01:15:47 UTC
[incubator-servicecomb-website] branch master updated: SCB-109
develop service provider translation for website (#5)
This is an automated email from the ASF dual-hosted git repository.
ningjiang pushed a commit to branch master
in repository https://gitbox.apache.org/repos/asf/incubator-servicecomb-website.git
The following commit(s) were added to refs/heads/master by this push:
new b61ffcb SCB-109 develop service provider translation for website (#5)
b61ffcb is described below
commit b61ffcb88cab8fe3d54da03f50de436be0467692
Author: churandexinghuo <47...@qq.com>
AuthorDate: Mon Dec 25 09:15:45 2017 +0800
SCB-109 develop service provider translation for website (#5)
---
_users/application-boot-process.md | 22 ++---
_users/communicate-protocol.md | 150 ++++++++++++++---------------
_users/define-service-contract.md | 62 ++++++------
_users/develop-with-jax-rs.md | 70 +++++++-------
_users/develop-with-springmvc.md | 64 ++++++-------
_users/develop-with-transparent-rpc.md | 52 +++++------
_users/service-configurations.md | 161 ++++++++++++++++----------------
_users/service-definition.md | 56 +++++------
_users/service-heartbeat.md | 20 ++--
_users/service-interface-constraints.md | 50 +++++-----
assets/images/thread-model-en.png | Bin 0 -> 28527 bytes
11 files changed, 349 insertions(+), 358 deletions(-)
diff --git a/_users/application-boot-process.md b/_users/application-boot-process.md
index c379dcf..3917ee3 100644
--- a/_users/application-boot-process.md
+++ b/_users/application-boot-process.md
@@ -1,27 +1,27 @@
---
-title: "程序启动逻辑"
+title: "Application Boot-up Process"
lang: en
ref: application-boot-process
permalink: /users/application-boot-process/
-excerpt: "程序启动逻辑"
+excerpt: "Application Boot-up Process"
last_modified_at: 2017-08-15T15:01:43-04:00
redirect_from:
- /theme-setup/
---
-服务提供者的启动过程分为初始化Log4j、bean加载（包括配置加载）和服务注册三部分。
+The starup process of a service provider includes initializing Log4j, loading bean(including its parameters), and registering service.
-* 初始化Log4j
+* Initialize Log4j:
- `Log4jUtils`默认会从`classpath\*:config/base/log4j.properties`和`classpath\*:config/log4j.properties`两个路径读取log4j配置并合并，将其传递给Log4j的`PropertyConfigurator`方法初始化Log4j。如果优先级最高的配置文件是在磁盘上，且其所在目录有写权限，则将合并的配置输出到该目录，以便于维护时观察生效的参数。
+ By default, `Log4jUtils` obtains the configuration of log4j from the `classpath\*:config/base/log4j.properties` and `classpath\*:config/log4j.properties` files. combines them, and transfer them to PropertyConfigurator of log4j to initialize log4j. If the configuration file having the highest priority is stored on the disk and its directory has write permission, save the combined configuration to this directory to view which parameters take effect during maintenance.
-* bean加载
+* Load the bean.
- `BeanUtils`默认会从`classpath\*:META-INF/spring/\*.bean.xml`路径加载配置文件，并将其传递给Spring框架的`ClassPathXmlApplicationContext`完成应用上下文加载。在这个过程中会加载foundation-config模块的bean，完成配置加载。
+ By default `BeanUtils` loads the configuration file from the `classpath\*:META-INF/spring/\*.bean.xml` path and transfer the configuration to `ClassPathXmlApplicationContext` of the Spring framework to load the context. In this process, ```BeanUtils``` loads the bean of foundation-config module.
-* 服务注册
+* Register the microservice.
- 在Spring context加载完成后，`io.servicecomb.core.CseApplicationListener`会加载handler配置、加载provider的schema信息，最后将微服务信息注册到服务中心。
+ After Spring context has been loaded, `io.servicecomb.core.CseApplicationListener` will configure the handler, load the information about the provider schema, and the register microservice to service center.
-> **说明：**
-> ServiceComb的配置项分为三个层次：配置中心、环境变量、本地文件，三者优先级依次递减，高优先级中的配置项覆盖低优先级同名配置项。存放在配置中心的配置项可以在运行时修改。
+> **NOTE:**
+> The three level of configuration items for ServiceComb are the configuration center, environment variables, and local files, listed in a descending order by priority. If configuration items with the same name exist, the one in the highest level overwrites others. Configuration items stored in the configuration center can be modified during running.
diff --git a/_users/communicate-protocol.md b/_users/communicate-protocol.md
index 136f882..30d3934 100644
--- a/_users/communicate-protocol.md
+++ b/_users/communicate-protocol.md
@@ -1,49 +1,49 @@
---
-title: "通信协议"
+title: "Communication Protocol"
lang: en
ref: communicate-protocol
permalink: /users/communicate-protocol/
-excerpt: "通信协议"
+excerpt: "Communication Protocol"
last_modified_at: 2017-08-15T15:01:43-04:00
redirect_from:
- /theme-setup/
---
{% include toc %}
-## 通信协议
-### 概念阐述
+## Communication Protocol
+### Concept Description
-ServiceComb实现了两种网络通道，包括REST和Highway，均支持TLS加密传输。其中，REST网络通道将服务以标准RESTful形式发布，调用端兼容直接使用http client使用标准RESTful形式进行调用。
+ServiceComb uses two network channels, REST and Highway, both supporting encrypted Transport Layer Security (TLS) transmission. The REST channel releases services in the standard RESTful form. The consumer can send requests using http client.
-### 注意事项
+### Precautions
-参数和返回值的序列化：
+Serialization of parameters and the returned values:
-当前REST通道的body参数只支持application/json序列化方式，如果要向服务端发送form类型的参数，那么需要在调用端构造好application/json格式的body，不能直接以multipart/form-data格式传递form类型参数。
+Currently, the body parameters of the REST channel support only the application/json serialization. To send form-type parameters to the server, construct a body of the application/json format at the consumer end. Do not send the form type parameters in multipart/form-data format.
-当前REST通道返回值支持application/json和text/plain两种格式，服务提供者通过produces声明可提供序列化能力，服务消费者通过请求的Accept头指明返回值序列化方式，默认返回application/json格式的数据。
+Currently, the REST channel supports the application/json and text/plain serialization. A provider uses produces to declare that it has the serialization capability. The consumer specifies the serialization mode of the returned values by setting parameters regarding the requested Accept header. Data serialized in application/json serialization mode is returned by default.
-## 线程模型
-### 概念阐述
+## Thread Model
+### Concept Description
-本小节主要介绍ServiceComb微服务的完整线程模型，介绍IO线程和业务线程之间的关系
+This section describes the thread model for ServiceComb microservices and the relationship between the I/O and service threads.
-### 完整线程
+### Thread Model
-ServiceComb微服务的完整线程模型如下图所示：
+The complete thread model of CSE is shown in the following figure.
-
+
-> 1. 业务线程在第一次调用时会绑定某一个网络线程,避免在不同网络线程之间切换,无谓地增加线程冲突的概率
-> 2. 业务线程绑定网络线程后,会再绑定该网络线程内部的某个连接,同样是为了避免线程冲突
+> 1. When a service thread is called for the first time, it binds to a network thread to avoid thread conflicts caused by switching among different network threads.
+> 2. After the service thread bound to a network thread, it will bind to a connection of the network to avoid thread conflicts.
-* 客户端和服务器都可以配置多个网络线程\(eventloop\)，默认为CPU核数的两倍，每个网络线程可以配置多个连接，默认为1，支持Rest和Highway两种网络通道，具体配置请查看如下章节：
+* Multiple network threads (eventloop) can be bound to both the client and the server. The number of network threads is two times the quantity of the CPU cores by default. Multiple connections can be configured for each network thread, and the default number is 1. The Rest and Highway network channels are supported. For details about these configurations, see following sections:
* [REST over Servlet](/users/communicate-protocol#rest-over-servlet)
* [REST over Vertx](/users/communicate-protocol/#rest-over-vertx)
- * [Highway RPC协议](/users/communicate-protocol/#highway-rpc协议)
-* 客户端可配置业务线程池executor，线程粒度可细化至schemaId:operation，配置如下：
+ * [Highway RPC Protocol](/users/communicate-protocol/#highway-rpc协议)
+* You can configure the service thread pool executor for the client, and the thread granularity can be schemaId: operation.
-在microservice.yaml中添加executors配置，为schemaId:operation配置单独的业务线程池：
+Add the executors in the microservice.yaml file and configure an independent service thread pool for schemaId: operation:
```yaml
cse:
@@ -53,13 +53,13 @@ cse:
```
## REST over Servlet
-### 配置说明
+### Configuration
- REST over Servlet对应使用web容器模式部署运行，需要新建一个servlet工程将微服务包装起来，加载到web容器中启动运行，包装微服务的方法有两种，一种完全使用web.xml配置文件配置，另一种仅在web.xml文件中配置listener，在microservice.yaml文件中配置urlPattern，两种方式如下所示：
+ REST over Servlet is deployed and runs using a web container. You need to create a servlet project to pack the microservice, load it to the web container, and then start it. To pack a microservice, you can either fully configure it in the web.xml, or configure its listener and urlPattern in the web.xml and microservice.yaml files, respectively.
-* 在web.xml文件中完成全部配置
+* Configure the microservice in the web.xml file.
- web.xml文件配置在项目的src/main/webapp/WEB\_INF目录，配置内容如下：
+ The web.xml file is under the src/main/webapp/WEB\_INF directory of the project, and its content is as follows:
```xml
<web-app xmlns="http://java.sun.com/xml/ns/javaee" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/web-app_3_0.xsd" version="3.0">
@@ -83,7 +83,7 @@ cse:
</web-app>
```
-* 在web.xml文件中仅配置listener，在microservice.yaml文件中配置urlPattern
+* Configure the listener in the web.xml file and urlPattern in the microservice.yaml file.
```xml
<web-app xmlns="http://java.sun.com/xml/ns/javaee" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/web-app_3_0.xsd" version="3.0">
@@ -97,13 +97,13 @@ cse:
</web-app>
```
- 在microservice.yaml文件中需要增加一行配置来指定urlPattern：
+ In the microservice.yaml file, add a row to specify the urlPattern：
```yaml
servicecomb.rest.servlet.urlPattern: /rest/*
```
-以上两种方式是等效的，两种方式都需要在maven pom文件中添加如下依赖：
+The two method are equivalent, and they both require that the following dependencies be added in the pox.xml file:
```xml
<dependency>
@@ -112,21 +112,21 @@ cse:
</dependency>
```
-REST over Servlet在microservice.yaml文件中的配置项见下表：
+Configuration items that need to be set in the microservice.yaml file are described in Table 1:
-表1 REST over Servlet配置项说明
+Table 1 Configuration items of REST over Servlet
-| 配置项 | 默认值 | 取值范围 | 是否必选 | 含义 | 注意 |
-| :--- | :--- | :--- | :--- | :--- | :--- |
-| cse.rest.address | 0.0.0.0:8080 | - | 否 | 服务监听地址 | - |
-| cse.rest.timeout | 3000 | - | 否 | 超时时间 | 单位为毫秒 |
-| cse.request.timeout | 30000 | - | 否 | 请求超时时间 | 同REST over Vertx的配置 |
-| cse.references.\[服务名\].transport | rest | | 否 | 访问的transport类型 | 同REST over Vertx的配置 |
-| cse.references.\[服务名\].version-rule | latest | - | 否 | 访问实例的版本号 | 同REST over Vertx的配置 |
+| Configuration Item | Default Value | Value Range | Mandatory | Description | Remark |
+| :---------------------------------- | :------------ | :---------- | :-------- | :--------------------------------------- | :--------------------------------------- |
+| cse.rest.address | 0.0.0.0:8080 | - | No | Specifies the server listening IP address. | - |
+| cse.rest.timeout | 3000 | - | No | Specifies the timeout duration | The unit is ms. |
+| cse.request.timeout | 30000 | - | No | Specifies the request timeout duration. | The configuration of this parameter for REST over Servlet is the same as that for REST over Vertx. |
+| cse.references.\[服务名\].transport | rest | | No | Specifies the accessed transport type. | The configuration of this parameter for REST over Servlet is the same as that for REST over Vertx. |
+| cse.references.\[服务名\].version-rule | latest | - | No | Specifies the version of the accessed instance. | The configuration of this parameter for REST over Servlet is the same as that for REST over Vertx. |
-### 示例代码
+### Sample Code
-microservice.yaml文件中的配置示例如下：
+The following is an example of the configuration in the microservice.yaml file for REST over Servlet:
```yaml
cse:
@@ -136,9 +136,9 @@ cse:
```
## REST over Vertx
-### 配置说明
+### Configuration
-REST over Vertx通信通道对应使用standalone部署运行模式，可直接通过main函数拉起。main函数中需要初始化日志和加载服务配置，代码如下：
+The REST over Vertx communication channel uses the standalone running mode that can be started using the main function. In the main function, you need to initialize logs and load service configuration. The code is as follow:
```java
import io.servicecomb.foundation.common.utils.BeanUtils;
@@ -146,13 +146,13 @@ import io.servicecomb.foundation.common.utils.Log4jUtils;
public class MainServer {
public static void main(String[] args) throws Exception {
- Log4jUtils.init();//日志初始化
- BeanUtils.init(); // Spring bean初始化
+ Log4jUtils.init();//Log initialization
+ BeanUtils.init(); // Spring bean initialization
}
}
```
-使用REST over Vertx网络通道需要在maven pom文件中添加如下依赖：
+To use the REST over Vertx communication channel, you need to add the following dependencies in the maven pom.xml file:
```xml
<dependency>
@@ -161,23 +161,23 @@ public class MainServer {
</dependency>
```
-REST over Vertx通道在microservice.yaml文件中有以下配置项：
+Configuration items that need to be set in the microservice.yaml file are described as follows:
-表2 REST over Vertx配置项说明
+Table 2 Configuration items of REST over Vertx
-| 配置项 | 默认值 | 取值范围 | 是否必选 | 含义 | 注意 |
-| :--- | :--- | :--- | :--- | :--- | :--- |
-| cse.rest.address | 0.0.0.0:8080 | - | 否 | 服务监听地址 | 仅服务提供者需要配置 |
-| cse.rest.server.thread-count | 1 | - | 否 | 服务端线程数 | 仅服务提供者需要配置 |
-| cse.rest.client.thread-count | 1 | - | 否 | 客户端网络线程数 | 仅服务消费者需要配置 |
-| cse.rest.client.connection-pool-per-thread | 1 | - | 否 | 客户端每个网络线程中的连接池的个数 | 仅服务消费者需要配置 |
-| cse.request.timeout | 30000 | - | 否 | 请求超时时间 | |
-| cse.references.\[服务名\].transport | rest | | 否 | 访问的transport类型 | 仅服务消费者需要配置 |
-| cse.references.\[服务名\].version-rule | latest | - | 否 | 访问实例的版本号 | 仅服务消费者需要配置支持latest，1.0.0+，1.0.0-2.0.2，精确版本。详细参考服务中心的接口描述。 |
+| Configuration Item | Default Value | Value Range | Mandatory | Description | Remark |
+| :--------------------------------------- | :------------ | :---------- | :-------- | :--------------------------------------- | :--------------------------------------- |
+| cse.rest.address | 0.0.0.0:8080 | - | No | Specifies the server listening IP address. | Only service providers require this parameter. |
+| cse.rest.server.thread-count | 1 | - | No | Specifies the number of server threads. | Only service providers require this parameter. |
+| cse.rest.client.thread-count | 1 | - | No | Specifies the number of client network threads. | Only service consumers require this parameter. |
+| cse.rest.client.connection-pool-per-thread | 1 | - | No | Specifies the number of connection pools in each client thread. | Only service consumers require this parameter. |
+| cse.request.timeout | 30000 | - | No | Specifies the request timeout duration. | |
+| cse.references.\[服务名\].transport | rest | | No | Specifies the accessed transport type. | Only service consumers require this parameter. |
+| cse.references.\[服务名\].version-rule | latest | - | No | Specifies the version of the accessed instance. | Only service consumers require this parameter. You can set it to latest, a version range such as 1.0.0+ or 1.0.0-2.0.2, or a specific version number. For details, see the API description of the service center. |
-### 示例代码
+### Sample Code
-microservice.yaml文件中的配置示例：
+An example of the configuration in the microservice.yaml file for REST over Vertx is as follows:
```yaml
cse:
@@ -190,14 +190,14 @@ cse:
version-rule: 0.0.1
```
-## Highway RPC协议
-### 概念阐述
+## Highway RPC Protocol
+### Concept Description
-Highway是ServiceComb的高性能私有协议，用户可在有特殊性能需求的场景下选用。
+Highway is a high-performance proprietary protocol of ServiceComb, and you can use it in scenarios having special performance requirements.
-### 配置说明
+### Configuration
-使用Highway网络通道需要在maven pom文件中添加如下依赖：
+To use the Highway communication channel, you need to add the following dependencies in the maven pom.xml file:
```xml
<dependency>
@@ -206,23 +206,23 @@ Highway是ServiceComb的高性能私有协议，用户可在有特殊性能需
</dependency>
```
-Highway通道在microservice.yaml文件中的配置项如下表所示：
+Configuration items that need to be set in the microservice.yaml file are described as follows:
-表3 Highway配置项说明
+Table 3 Configuration items of Highway
-| 配置项 | 默认值 | 取值范围 | 是否必选 | 含义 | 注意 |
-| :--- | :--- | :--- | :--- | :--- | :--- |
-| cse.highway.address | 0.0.0.0:7070 | - | 否 | 服务监听地址 | - |
-| cse.highway.server.thread-count | 1 | - | 否 | 服务端网络线程个数 | - |
-| cse.highway.client.thread-count | 1 | - | 否 | 客户端网络线程个数 | - |
-| cse.highway.client.connection-pool-per-thread | 1 | - | 否 | 客户端每个网络线程的连接池个数 | - |
-| cse.request.timeout | 30000 | - | 否 | 请求超时时间 | 同REST over Vertx的配置 |
-| cse.references.\[服务名\].transport | rest | | 否 | 访问的transport类型 | 同REST over Vertx的配置 |
-| cse.references.\[服务名\].version-rule | latest | - | 否 | 访问实例的版本号 | 同REST over Vertx的配置 |
+| Configuration Item | Default Value | Value Range | Mandatory | Description | Remark |
+| :--------------------------------------- | :------------ | :---------- | :-------- | :--------------------------------------- | :--------------------------------------- |
+| cse.highway.address | 0.0.0.0:7070 | - | No | Specifies the server listening IP address. | - |
+| cse.highway.server.thread-count | 1 | - | No | Specifies the number of server network threads. | - |
+| cse.highway.client.thread-count | 1 | - | No | Specifies the number of client network threads. | - |
+| cse.highway.client.connection-pool-per-thread | 1 | - | No | Specifies the number of connection pools in each client thread. | - |
+| cse.request.timeout | 30000 | - | No | Specifies the request timeout duration. | The configuration of this parameter for Highway is the same as that for REST over Vertx. |
+| cse.references.\[服务名\].transport | rest | | No | Specifies the accessed transport type. | The configuration of this parameter for Highway is the same as that for REST over Vertx. |
+| cse.references.\[服务名\].version-rule | latest | - | No | Specifies the version of the accessed instance. | The configuration of this parameter for Highway is the same as that for REST over Vertx. |
-### 示例代码
+###
-microservice.yaml文件中的配置示例：
+An example of the configuration in the microservice.yaml file for Highway is as follows:
```yaml
cse:
diff --git a/_users/define-service-contract.md b/_users/define-service-contract.md
index 1620492..afd5f79 100644
--- a/_users/define-service-contract.md
+++ b/_users/define-service-contract.md
@@ -1,43 +1,43 @@
---
-title: "服务契约"
+title: "Service Contract"
lang: en
ref: service-contract
permalink: /users/service-contract/
-excerpt: "服务契约"
+excerpt: "Service Contract"
last_modified_at: 2017-08-15T15:01:43-04:00
redirect_from:
- /theme-setup/
---
{% include toc %}
-## 概念阐述
+## Concept Description
-服务契约，指基于OpenAPI规范的微服务接口契约，是服务端与消费端对于接口的定义。
+The API of provider and consumer microservice is defined based on OpenAPI regulations.
-## 场景描述
+## Scenario
-服务契约用于服务端和消费端的解耦，服务端围绕契约进行服务的实现，消费端根据契约进行服务的调用，可支持服务端和消费端采用不同的编程语言实现。
+The API definition decouples providers and consumers, which allows the two parties to use different programming languages, Providers provide services and consumers call them based on the API definition.
-## 显式契约
+## Explicit API Definition
-### 配置说明
+### Configuration
-ServiceComb使用yaml文件格式定义服务契约，推荐使用[Swagger Editor](http://editor.swagger.io/#/)工具来编写契约，可检查语法格式及自动生成API文档。详细的契约文件格式请参考[OpenAPI官方文档](https://github.com/OAI/OpenAPI-Specification/blob/master/versions/2.0.md)。
+ServiceComb defines API in a .yaml faile. You are advised to use [Swagger Editor](http://editor.swagger.io/#/) to write an API definition. This tool can check syntax and automaticlly generate an API document. For details about the API definition file format, see [ Official OpenAPI documentation](https://github.com/OAI/OpenAPI-Specification/blob/master/versions/2.0.md)。
-契约文件放置在"resources/microservices"或者"resources/applications"目录下，目录结构如下所示。
+The API definition file is located in "resources/microservices" or "resources/applications" directory. The directory structure is as follows:
```txt
resources
- microservices
- - serviceName #微服务名
- - schemaId.yaml #schema接口的契约
+ - serviceName #Microservice name
+ - schemaId.yaml #schema API definition
- applications
- - appId #应用ID
- - serviceName #微服务名
- - schemaId.yaml #schema接口的契约
+ - appId #Application ID
+ - serviceName #Service name
+ - schemaId.yaml #Schema API definition
```
-### 示例代码
+### Sample Code
```yaml
swagger: '2.0'
@@ -60,11 +60,11 @@ paths:
type: string
responses:
200:
- description: 正确返回
+ description: returned for a correct result
schema:
type: string
default:
- description: 默认返回
+ description: returned for a default result
schema:
type: string
/sayhello:
@@ -78,11 +78,11 @@ paths:
$ref: "#/definitions/Person"
responses:
200:
- description: 正确返回
+ description: returned for a correct result
schema:
type: string
default:
- description: 默认返回
+ description: returned for a default result
schema:
type: string
definitions:
@@ -96,21 +96,21 @@ definitions:
name: "Person"
```
-> **注意**：
-- 根据swagger标准，basePath配置的路径需要包括web server的webroot。
-- info.x-java-interface需要标明具体的接口路径，根据项目实际情况而定。
+> **NOTE**：
+- According to Swagger specifications, the path specified by basePath should contain the webroot of the web server.
+- info.x-java-interface requires a specific API path. Set it as needed.
-## 隐式契约
-### 概念阐述
+## Implicit API Definition
+### Concept Description
- 隐式契约是指ServiceComb根据服务实现类自动生成的服务契约。
+ The inplicit API definition is automatically generated by ServiceComb based on the service implementation class.
-### 场景描述
+### Scenario
- 用户通过隐式契约功能，可以不预先定义契约和接口，直接定义实现类，在服务启动时，根据实现类自动生成契约，并注册到服务中心。
+ By using the implicit API definition you can define the implementation class without pre-defining APIs. When the service is started, an API is automatically generated and registered to the service center.
-### 涉及API
+### Involved API
- 隐式契约可用于Spring MVC、JAX-RS、透明RPC三种开发模式，具体使用参见[用SpringMVC开发微服务](/users/develop-with-springmvc/)、[用JAX-RS开发微服务](/users/develop-with-jax-rs/)和[用透明RPC开发微服务](/users/develop-with-transparent-rpc/)。
+ Implicit API definitions can be used for Spring MVC, JAX-RS, and transparent RPC development modes, For details, see [Development Style-SpringMVC](/users/develop-with-springmvc/), [Development Stype-JAX-RS](/users/develop-with-jax-rs/) and [Development Style-Transparent RPC](/users/develop-with-transparent-rpc/).
- 使用透明RPC模式开发微服务时，由于从代码上无法分辨微服务开发人员期望如何定义契约，所以生成的契约全是POST方法，所有method的入参被包装为一个class，作为body参数传递，所以建议使用隐式契约开发provider时，选择SpringMVC或JAX-RS开发模式，可以得到完整的RESTful声明。
+ When you develop a microservice in transparent RPC mode, the code does not show how you want to define an API, and all generated APIs are POST methods, The input parameters of all the methods will be packaged as a class and transferred as body parameters. Therefore, if you develop providers using implicit APIs, you are advised to choose Spring MVC or JAX-RS mode to obtain complete RESTful statements.
\ No newline at end of file
diff --git a/_users/develop-with-jax-rs.md b/_users/develop-with-jax-rs.md
index ff6b374..0e16f84 100644
--- a/_users/develop-with-jax-rs.md
+++ b/_users/develop-with-jax-rs.md
@@ -1,9 +1,9 @@
---
-title: "用JAX-RS开发微服务"
+title: "Development Style-JAX-RS"
lang: en
ref: develop-with-jax-rs
permalink: /users/develop-with-jax-rs/
-excerpt: "用JAX-RS开发微服务"
+excerpt: "Development Style-JAX-RS"
last_modified_at: 2017-08-15T15:01:43-04:00
redirect_from:
- /theme-setup/
@@ -11,15 +11,13 @@ redirect_from:
{% include toc %}
-## 概念阐述
+## Concept Description
-ServiceComb支持开发者使用JAX-RS注解，使用JAX-RS模式开发服务。
+ServiceComb supports developers in developing services in JAX-RS mode by using JAX-RS.
-## 开发示例
+## Development Example
-* **步骤 1** 定义服务接口。
-
- 根据开发之前定义好的契约，编写Java业务接口，代码如下：
+* **Steps 1** Define a service API. Compile the Java API definition based on the API definition defined before development. The code is as follows:
```java
public interface Hello {
@@ -28,12 +26,10 @@ ServiceComb支持开发者使用JAX-RS注解，使用JAX-RS模式开发服务。
}
```
- > **说明**：
- 该接口的位置需要与契约中x-java-interface所指定的路径一致。
-
-* **步骤 2** 实现服务。
+ > **NOTE**：
+ > The location of the API must be the same as the path specified by x-java-interface in the API definition.
- 使用JAX-RS注解开发业务代码，Hello的服务实现如下：
+* **Step 2** Implement the service. JAX-RS is used to describe the development of service code. The implementation of the Hello service is as follows:
```java
import javax.ws.rs.POST;
@@ -62,9 +58,7 @@ ServiceComb支持开发者使用JAX-RS注解，使用JAX-RS模式开发服务。
}
```
-* **步骤 3** 发布服务。
-
- 在服务的实现类上打上注解`@RestSchema`，指定schemaId，表示该实现作为当前微服务的一个schema发布，代码如下：
+* **Step 3** Release the service. Add ```@RestSchema``` as the annotation of the service implementation class and specify schemaID, which indicates that the implementation is released as a schema of the current microservice. The code is as follows:
```java
import io.servicecomb.provider.rest.common.RestSchema;
@@ -75,7 +69,7 @@ ServiceComb支持开发者使用JAX-RS注解，使用JAX-RS模式开发服务。
}
```
- 然后在resources/META-INF/spring目录下创建jaxrsHello.bean.xml文件，配置spring进行服务扫描的base-package，文件内容如下：
+ Create the jaxrsHello.bean.xml file in the resources/META-INF/spring directory and configure base-package that performs scanning. The content of the file is as follows:
```xml
<?xml version="1.0" encoding="UTF-8"?>
@@ -84,28 +78,28 @@ ServiceComb支持开发者使用JAX-RS注解，使用JAX-RS模式开发服务。
xmlns:cse=" http://www.huawei.com/schema/paas/cse/rpc "
xmlns:context=" http://www.springframework.org/schema/context "
xsi:schemaLocation=" http://www.springframework.org/schema/beans classpath:org/springframework/beans/factory/xml/spring-beans-3.0.xsd http://www.springframework.org/schema/context http://www.springframework.org/schema/context/spring-context-3.0.xsd http://www.huawei.com/schema/paas/cse/rpc classpath:META-INF/spring/spring-paas-cse-rpc.xsd">
-
+
<context:component-scan base-package="io.servicecomb.samples.jaxrs.provider"/>
</beans>
```
-## 涉及API
-
-JAX-RS开发模式当前支持如下注解，所有注解的使用方法参考[JAX-RS官方文档](https://jax-rs-spec.java.net/nonav/2.0-rev-a/apidocs/index.html)。
-
-| 注解 | 位置 | 描述 |
-| :--- | :--- | :--- |
-| javax.ws.rs.Path | schema/operation | URL路径 |
-| javax.ws.rs.Produces | schema/operation | 方法支持的编解码能力 |
-| javax.ws.rs.DELETE | operation | http method |
-| javax.ws.rs.GET | operation | http method |
-| javax.ws.rs.POST | operation | http method |
-| javax.ws.rs.PUT | operation | http method |
-| javax.ws.rs.QueryParam | parameter | 从query string中获取参数 |
-| javax.ws.rs.PathParam | parameter | 从path中获取参数，必须在path中定义该参数 |
-| javax.ws.rs.HeaderParam | parameter | 从header中获取参数 |
-| javax.ws.rs.CookieParam | parameter | 从cookie中获取参数 |
-
-> **说明**：
-- 当方法参数没有注解，且不为HttpServletRequest类型参数时，默认为body类型参数，一个方法只支持最多一个body类型参数。
-- 打在参数上面的注解建议显式定义出value值，否则将直接使用契约中的参数名，例如应该使用`@QueryParam\("name"\) String name`，而不是`@QueryParam String name`。
+## Involved APIs
+
+Currently, the JAX-RS development mode supports the following annotation. For details about how to use JAX-RS, see [JAX-RS official documentation](https://jax-rs-spec.java.net/nonav/2.0-rev-a/apidocs/index.html)。
+
+| Remarks | Location | Description |
+| :---------------------- | :--------------- | :--------------------------------------- |
+| javax.ws.rs.Path | schema/operation | URL path |
+| javax.ws.rs.Produces | schema/operation | Coding/decoding capability supported by the method |
+| javax.ws.rs.DELETE | operation | http method |
+| javax.ws.rs.GET | operation | http method |
+| javax.ws.rs.POST | operation | http method |
+| javax.ws.rs.PUT | operation | http method |
+| javax.ws.rs.QueryParam | parameter | Obtain parameters from query string |
+| javax.ws.rs.PathParam | parameter | Obtain parameters from path, This parameter must be defined in path. |
+| javax.ws.rs.HeaderParam | parameter | Obtain parameters from header. |
+| javax.ws.rs.CookieParam | parameter | Obtain parameters from cookie. |
+
+> **NOTE**：
+- When the method parameter has no annotation and is not an HttpServletRequest parameter, the parameter is of the body type by default. One method supports a maximum of one body-typed parameter.
+- You are advised to explicitly define the value of the parameter. Otherwise, the parameter name in the API definition is used, such as `@QueryParam\("name"\) String name` String name instead of `@QueryParam String name`.
diff --git a/_users/develop-with-springmvc.md b/_users/develop-with-springmvc.md
index 7559aa7..25cb280 100644
--- a/_users/develop-with-springmvc.md
+++ b/_users/develop-with-springmvc.md
@@ -1,24 +1,22 @@
---
-title: "用SpringMVC开发微服务"
+title: "Development Style-Spring MVC"
lang: en
ref: develop-with-springmvc
permalink: /users/develop-with-springmvc/
-excerpt: "用SpringMVC开发微服务"
+excerpt: "Development Style-Spring MVC"
last_modified_at: 2017-08-15T15:01:43-04:00
redirect_from:
- /theme-setup/
---
{% include toc %}
-## 概念阐述
+## Concept Description
-ServiceComb支持SpringMVC注解，允许使用SpringMVC风格开发微服务。
+ServiceComb supports Spring MVC remark and allows you to develop microservices in Spring MVC mode.
-## 开发示例
+## Development Example
-* **步骤 1** 定义服务接口。
-
- 根据开发之前定义好的契约，编写Java业务接口，代码如下：
+* **Step 1** Define a service API., Compile the Java API definition based on the API definition defined before development. The code is as follow:
```java
public interface Hello {
@@ -27,11 +25,9 @@ ServiceComb支持SpringMVC注解，允许使用SpringMVC风格开发微服务。
}
```
- 该接口的位置需要与契约中x-java-interface所指定的路径一致。
-
-* **步骤 2** 实现服务。
+ The location of the API must be the same as the path specified by x-java-interface in the API definition.
- 使用Spring MVC注解开发业务代码，Hello的服务实现如下：
+* **Step 2** Implement the services. Spring MVC is used to describe the development of service code. The implementation of the Hello service is as follow:
```java
import javax.ws.rs.core.MediaType;
@@ -41,7 +37,7 @@ ServiceComb支持SpringMVC注解，允许使用SpringMVC风格开发微服务。
import org.springframework.web.bind.annotation.RequestParam;
import io.servicecomb.samples.common.schema.Hello;
import io.servicecomb.samples.common.schema.models.Person;
-
+
@RequestMapping(path = "/springmvchello", produces = MediaType.APPLICATION_JSON)
public class SpringmvcHelloImpl implements Hello {
@Override
@@ -58,9 +54,7 @@ ServiceComb支持SpringMVC注解，允许使用SpringMVC风格开发微服务。
}
```
-* **步骤 3** 发布服务
-
- 在服务的实现类上打上注解@RestSchema，指定schemaId，表示该实现作为当前微服务的一个schema发布，代码如下：
+* **Step 3** Release the service. Add @RestSchema as the annotation of the service implementation class and specify schemaId, which indicates that the implementation is released as a schema of the current microservice. The code is as follows:
```java
import io.servicecomb.provider.rest.common.RestSchema;
@@ -71,34 +65,34 @@ ServiceComb支持SpringMVC注解，允许使用SpringMVC风格开发微服务。
}
```
- 然后在`resources/META-INF/spring`目录下创建`springmvcHello.bean.xml`文件，命名规则为`\*.bean.xml`，配置spring进行服务扫描的base-package，文件内容如下：
+ Create the ```springmvcHello.bean.xml``` file(the file name format is *.bean.xml) in the ``` resources/META-INF/spring``` directory and configure base-package that performs scanning. The content of the file is as follows:
```xml
<?xml version="1.0" encoding="UTF-8"?>
-
+
<beans xmlns="http://www.springframework.org/schema/beans"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:context="http://www.springframework.org/schema/context"
xsi:schemaLocation="http://www.springframework.org/schema/beans classpath:org/springframework/beans/factory/xml/spring-beans-3.0.xsd
http://www.springframework.org/schema/context http://www.springframework.org/schema/context/spring-context-3.0.xsd">
-
+
<context:component-scan base-package="io.servicecomb.samples.springmvc.provider"/>
</beans>
```
-## 涉及API
-
-Spring MVC开发模式当前支持org.springframework.web.bind.annotation包下的如下注解，所有注解的使用方法参考[Spring MVC官方文档](https://docs.spring.io/spring/docs/current/spring-framework-reference/html/mvc.html)。
-
-| 注解 | 位置 | 描述 |
-| :--- | :--- | :--- |
-| RequestMapping | schema/operation | 支持标注path/method/produces三种数据，operation默认继承schema上的produces |
-| GetMapping | schema/operation | 支持标注path/produces两种数据，operation默认继承schema上的produces |
-| PutMapping | schema/operation | 支持标注path/produces两种数据，operation默认继承schema上的produces |
-| PostMapping | schema/operation | 支持标注path/produces两种数据，operation默认继承schema上的produces |
-| DeleteMapping | schema/operation | 支持标注path/produces两种数据，operation默认继承schema上的produces |
-| PatchMapping | schema/operation | 支持标注path/produces两种数据，operation默认继承schema上的produces |
-| PathVariable | parameter | 从path中获取参数 |
-| RequestParam | parameter | 从query中获取参数 |
-| RequestHeader | parameter | 从header中获取参数 |
-| RequestBody | parameter | 从body中获取参数，每个operation只能有一个body参数 |
+## Involved APIs
+
+Currently, the Spring MVC development mode supports the following annotations in the org.springframework.web.bind.annotation package. For details about how to use the annotations, see [Spring MVC official documentation](https://docs.spring.io/spring/docs/current/spring-framework-reference/html/mvc.html)。
+
+| Remarks | Location | Description |
+| :------------- | :--------------- | :--------------------------------------- |
+| RequestMapping | schema/operation | Data of path, method or produces is allowed. By default, an operation inherits produces from a schema. |
+| GetMapping | schema/operation | Data of path or produces is allowed. By default, an operation inherits produces from a schema. |
+| PutMapping | schema/operation | Data of path or produces is allowed, an operation inherits produces from a schema. |
+| PostMapping | schema/operation | Data of path or produces is allowed, an operation inherits produces from a schema. |
+| DeleteMapping | schema/operation | Data of path or produces is allowed, an operation inherits produces from a schema. |
+| PatchMapping | schema/operation | Data of path or produces is allowed, an operation inherits produces from a schema. |
+| PathVariable | parameter | Obtain parameters from path. |
+| RequestParam | parameter | Obtain parameters from query. |
+| RequestHeader | parameter | Obtain parameters from header. |
+| RequestBody | parameter | Obtain parameters from body. Each operation can have only one body parameter. |
diff --git a/_users/develop-with-transparent-rpc.md b/_users/develop-with-transparent-rpc.md
index 9363409..4525dc8 100644
--- a/_users/develop-with-transparent-rpc.md
+++ b/_users/develop-with-transparent-rpc.md
@@ -1,26 +1,24 @@
---
-title: "用透明RPC开发微服务"
+title: "Development Style-Transparent RPC"
lang: en
ref: develop-with-transparent-rpc
permalink: /users/develop-with-transparent-rpc/
-excerpt: "用透明RPC开发微服务"
+excerpt: "Development Style-RPC"
last_modified_at: 2017-08-15T15:01:43-04:00
redirect_from:
- /theme-setup/
---
{% include toc %}
-## 概念阐述
+## Concept Description
-透明RPC开发模式是一种基于接口和接口实现的开发模式，服务的开发者不需要使用Spring MVC和JAX-RS注解。
+The transparent remote procedure call(RPC) development mode is a development mode based on API and API implementation. The service developer does not need to use the description of Spring MVC and JAX-RS.
-## 开发示例
+## Development Example
-透明RPC开发模式支持Spring xml配置和注解配置两种服务发布方式，通过Spring xml配置的方式如下：
+The transparent RPC development mode supports two service release mode: Spring XML configuration and annotation configuration. The Spring XML configuration mode is as follows:
-* **步骤 1** 定义服务接口。
-
- 根据开发之前定义好的契约，编写Java业务接口，代码如下：
+* **Step 1** Define a service API. Compile the Java API definition based on the API definition defined before development. The code is as follows:
```java
public interface Hello {
@@ -29,12 +27,10 @@ redirect_from:
}
```
- > **说明**：
- > 该接口的位置需要与契约中x-java-interface所指定的路径一致。
-
-* **步骤 2** 实现服务
+ > **NOTE**：
+ > The location of the API must be the same as the path specified by x-java-interface in the API definition.
- Hello的服务实现如下：
+* **Step 2** implement the service. The implementation of the Hello service is as follows:
```java
import io.servicecomb.samples.common.schema.Hello;
@@ -53,9 +49,7 @@ redirect_from:
}
```
-* **步骤 3** 发布服务
-
- 在resources/META-INF/spring目录下创建pojoHello.bean.xml文件，在文件中声明schema，文件内容如下：
+* **Step 3** Release the service. Create the pojoHello.bean.xml file in the resources/META-INF/spring directory and declare the schema in the file. The content of the file is as follows:
```xml
<?xml version="1.0" encoding="UTF-8"?>
@@ -64,19 +58,21 @@ redirect_from:
xmlns:cse=" http://www.huawei.com/schema/paas/cse/rpc "
xmlns:context=" http://www.springframework.org/schema/context "
xsi:schemaLocation=" http://www.springframework.org/schema/beans classpath:org/springframework/beans/factory/xml/spring-beans-3.0.xsd http://www.springframework.org/schema/context http://www.springframework.org/schema/context/spring-context-3.0.xsd http://www.huawei.com/schema/paas/cse/rpc classpath:META-INF/spring/spring-paas-cse-rpc.xsd">
-
+
<cse:rpc-schema schema-id="pojoHello" implementation="io.servicecomb.samples.pojo.provider.PojoHelloImpl"/>
</beans>
```
- > **说明**：
- > 每一个服务接口都需要定义一个schema声明。
+ > **NOTE**：
+ > A schema statement must be defined for each service API.
-## 通过注解配置的开发方式
+## The Develop Method by Configure Remarks
-1. 定义服务接口，与使用Spring xml的方式相同。
-2. 实现服务，与使用Spring xml的方式相同。
-3. 发布服务。在接口Hello的实现类上使用@RpcSchema注解定义schema，代码如下：
+1. Define a service API, which is the same as the Spring XML mode.
+
+2. Implement the service in the same way as using Spring XML.
+
+3. Release the service. @RpcSchema is used to define schema during the API Hello implementation. The code is as followss:
```java
import io.servicecomb.provider.pojo.RpcSchema;
@@ -87,7 +83,7 @@ redirect_from:
}
```
- 在resources/META-INF/spring目录下的pojoHello.bean.xml文件中，配置Spring进行服务扫描的base-package，文件内容如下：
+ In the pojoHello.bean.xml file of resources/META-INF/spring directory, configure base-package that performs scanning. The content of the file is as follows:
```xml
<?xml version="1.0" encoding="UTF-8"?>
@@ -96,10 +92,10 @@ redirect_from:
xmlns:cse=" http://www.huawei.com/schema/paas/cse/rpc "
xmlns:context=" http://www.springframework.org/schema/context "
xsi:schemaLocation=" http://www.springframework.org/schema/beans classpath:org/springframework/beans/factory/xml/spring-beans-3.0.xsd http://www.springframework.org/schema/context http://www.springframework.org/schema/context/spring-context-3.0.xsd http://www.huawei.com/schema/paas/cse/rpc classpath:META-INF/spring/spring-paas-cse-rpc.xsd">
-
+
<context:component-scan base-package="io.servicecomb.samples.pojo.provider"/>
</beans>
```
-> **说明**：
-> 与Spring MVC开发模式和JAX-RS开发模式不同的是，透明RPC开发模式使用的注解是`@RpcSchema`而非`@RestSchema`。
+> **NOTE**:
+> Different from the Spring MVC and JAX-RS development modes, the transparent RPC development mode used `@RpcSchema` instead of `@RestSchema`.
diff --git a/_users/service-configurations.md b/_users/service-configurations.md
index aafdbde..2ac3c56 100644
--- a/_users/service-configurations.md
+++ b/_users/service-configurations.md
@@ -1,46 +1,46 @@
---
-title: "服务配置"
+title: "Service Configurations"
lang: en
ref: service-configurations
permalink: /users/service-configurations/
-excerpt: "服务配置"
+excerpt: "Service Configurations"
last_modified_at: 2017-08-15T15:01:43-04:00
redirect_from:
- /theme-setup/
---
{% include toc %}
-## 负载均衡策略
-### 场景描述
+## Load Balancing Policy
+### Scenario
- ServiceComb提供了基于Ribbon的负载均衡方案，用户可以通过配置文件配置负载均衡策略，当前支持随机、顺序、基于响应时间的权值等多种负载均衡路由策略。
+ ServiceComb provides a Ribbon-based load balancing solution. You can configure a load balancing policy in the configuration file. Currently, a load balancing routing policy can be random, sequential, or based on response time weight.
-### 配置说明
+### Configuration
- 负载均衡策略在microservice.yaml文件中配置，配置项为`cse.loadbalance.[MicroServiceName].[property name]`，其中若省略MicroServiceName，则为全局配置；若指定MicroServiceName，则为针对特定微服务的配置。
+ Load balancing policies are configured by setting the parameter `cse.loadbalance.[MicroServiceName].[property name]` in the microservice.yaml fiel. If MicroServiceName is not set, the configuration is set for all microservices. Otherwise, the configuration is set for a specific microservice.
- **表1 配置项说明**
+ **Table 1 Configuration items of load balancing policy**
-| 配置项 | 默认值 | 取值范围 | 是否必选 | 含义 | 注意 |
-| :--- | :--- | :--- | :--- | :--- | :--- |
-| cse.loadbalance.NFLoadBalancerRuleClassName | com.netflix.loadbalancer.RoundRobinRule | com.netflix.loadbalancer.RoundRobinRule（轮询）com.netflix.loadbalancer.RandomRule（随机）com.netflix.loadbalancer.WeightedResponseTimeRule（服务器响应时间权值）io.servicecomb.loadbalance.SessionStickinessRule（会话保持） | 否 | 负载均衡路由策略 | - |
-| cse.loadbalance.SessionStickinessRule.sessionTimeoutInSeconds | 30 | Integer | 否 | 客户端闲置时间，超过限制后选择后面的服务器。 | 暂不支持微服务配置。e.g. cse.loadbalance.SessionStickinessRule.sessionTimeoutInSeconds，不能配置为cse.loadbalance.DemoService.SessionStickinessRule.sessionTimeoutInSeconds |
-| cse.loadbalance.SessionStickinessRule.successiveFailedTimes | 5 | Integer | 否 | 客户端失败次数，超过后会切换服务器 | 暂不支持微服务配置 |
-| cse.loadbalance.retryEnabled | FALSE | Boolean | 否 | 负载均衡捕获到服务调用异常，是否进行重试 | - |
-| cse.loadbalance.retryOnNext | 0 | Integer | 否 | 尝试新的服务器的次数 | - |
-| cse.loadbalance.retryOnSame | 0 | Integer | 否 | 同一个服务器尝试的次数 | - |
-| cse.loadbalance.isolation.enabled | FALSE | Boolean | 否 | 是否开启故障实例隔离功能 | - |
-| cse.loadbalance.isolation.enableRequestThreshold | 20 | Integer | 否 | 当实例的调用总次数达到该值时开始进入隔离逻辑门槛 | - |
-| cse.loadbalance.isolation.errorThresholdPercentage | 20 | Integer，区间为\(0,100\] | 否 | 实例故障隔离错误百分比 | - |
-| cse.loadbalance.isolation.singleTestTime | 10000 | Integer | 否 | 故障实例单点测试时间 | 单位为ms |
-| cse.loadbalance.transactionControl.policy | io.servicecomb.loadbalance.filter.SimpleTransactionControlFilter | - | 否 | 动态路由分流策略 | 框架提供了简单的分流机制，开发者也可以实现自定义的分流过滤策略 |
-| cse.loadbalance.transactionControl.options | - | key/value pairs | 否 | 针对SimpleTransactionControlFilter分流策略的配置项，可添加任意项过滤标签 | - |
+| Configuration Items | Default Value | Value Range | Mandatory | Description | Remarks |
+| :--------------------------------------- | :--------------------------------------- | :--------------------------------------- | :-------- | :--------------------------------------- | :--------------------------------------- |
+| cse.loadbalance.NFLoadBalancerRuleClassName | com.netflix.loadbalancer.RoundRobinRule | com.netflix.loadbalancer.RoundRobinRule（polling）com.netflix.loadbalancer.RandomRule（random）com.netflix.loadbalancer.WeightedResponseTimeRule（server response time weight）io.servicecomb.loadbalance.SessionStickinessRule（session stickiness） | No | Specifiles the load balancing policy | - |
+| cse.loadbalance.SessionStickinessRule.sessionTimeoutInSeconds | 30 | Integer | No | Specifies the idle time of a client. If the idle time exceeds the set value, ServiceComb will select another server. | Currently, this parameter cannot be set for a certain microservice. For example, cse.loadbalance.SessionStickinessRule.sessionTimeoutInSeconds cannot be set to cse.loadbalance.DemoService.SessionStickinessRule [...]
+| cse.loadbalance.SessionStickinessRule.successiveFailedTimes | 5 | Integer | No | Specifies the number of failed requests from the client. If the number exceeds the set value, ServiceComb will switch to another server | Currently, this parameter cannot be set for a certain microservice. |
+| cse.loadbalance.retryEnabled | FALSE | Boolean | No | Specifies whether to call a service again when a exception is captured by the load balance. | - |
+| cse.loadbalance.retryOnNext | 0 | Integer | No | Specifies the number of attempts to connect to another server. | - |
+| cse.loadbalance.retryOnSame | 0 | Integer | No | Specifies the number of attempts to connect to the same server. | - |
+| cse.loadbalance.isolation.enabled | FALSE | Boolean | No | Specifies whether to enable faulty instance isolation. | - |
+| cse.loadbalance.isolation.enableRequestThreshold | 20 | Integer | No | Specifies the threshold number of instance calls. If this value is reached, isolation is enabled. | - |
+| cse.loadbalance.isolation.errorThresholdPercentage | 20 | Integer，\(0,100\] | No | Specifies the error percentage. Instance fault isolation is enabled when the set value is reached. | - |
+| cse.loadbalance.isolation.singleTestTime | 10000 | Integer | No | Specifies the duration of a faulty instance test on a single node. | This unit is ms. |
+| cse.loadbalance.transactionControl.policy | io.servicecomb.loadbalance.filter.SimpleTransactionControlFilter | - | No | Specifies the offload policies for dynamic routing. | The framework provides simple offload mechanisms. You can also customize offload policies. |
+| cse.loadbalance.transactionControl.options | - | key/value pairs | No | Specifies the parameter configured for the SimpleTransactionControlFilter offload policy. You can add any filtration tag for this item. | - |
-### 示例代码
+### Sample Code
- 负载均衡策略配置在src/main/resources/microservice.yaml文件中。
+ in the src/main/resources/microservice.yaml file, configure a load balancing policy.
- 配置处理链：
+ Configure a processing link：
```yaml
cse:
@@ -52,7 +52,7 @@ cse:
# other configurations omitted
```
- 增加路由策略：
+ Add a routing policy:
```yaml
cse：
@@ -62,31 +62,30 @@ cse：
# other configurations omitted
```
-## 自定义路由策略
+## Customizing Routing Policies
- 用户可以在ServiceComb提供的路由策略框架下根据业务需要，通过编程的方式来开发路由策略。实施步骤如下：
+ Based on the routing policy framework provided by ServiceComb, you can program to customize routing policies as required. Perform the following steps:
-* 实现接口`com.netflix.loadbalancer.IRule`中定义的接口方法。
-路由选择逻辑在public Server choose\(Object key\)方法中实现。LoadBalancerStats是一个封装了负载均衡器当前运行状态的一个结构。通过获取stats中各个实例的运行指标，在choose方法中，判定将当前请求路由到哪个实例上进行处理。处理风格可以参照`io.servicecomb.loadbalance.SessionStickinessRule`。
+* Encode using the API method defined in the `com.netflix.loadbalancer.IRule` API. Encode in the public Server choose(Object key) method. LoadBalancerStats is a structure that encapsulates the running state of the load balancer. Determine on which instance the current routing request will be processed based on the running indexes of each instance by using the Server choose(Object key) method. Use method `io.servicecomb.loadbalance.SessionStickinessRule`for instance processing.
-* 编译开发的策略，保证生成的class在classpath下。
+* Compile the developed policy and ensure that the generated class is under classpath.
-* 通过SDK配置该路由策略，假如是`AbcRule`。则配置如下： `cse.loadbalance.NFLoadBalancerRuleClassName=io.servicecomb.ribbon.rule.AbcRule`
-
-## 限流策略
-### 场景描述
+* Use the software development kit(SDK) to configure the routing policy. Use AbcRule as a routing policy example. The configuration is as follows: `cse.loadbalance.NFLoadBalancerRuleClassName=io.servicecomb.ribbon.rule.AbcRule`
-用户在provider端使用限流策略，可以限制指定微服务向其发送请求的频率，达到限制每秒钟最大请求数量的效果。
+## Rate Limiting Policy
+### Scenario
-### 注意事项
+Users at the provider end can use the rate limiting policy to limit the maximum number of requests sent from a specified microservice per second.
-1. 限流策略的控制并不是绝对精确的，可能会有少量误差。
-2. provider端的流量控制是业务层面的功能，不是安全意义上的流量控制，如需防止DDoS攻击，需要结合其他的一系列措施。
-3. 流量控制是微服务级的，不是进程级的。
+### Precautions
-### 配置说明
+1. There may be a small different between the rate limit and actual traffic.
+2. The rate limit function at the provider end is for service rather than security purpose. To prevent distributed denial of service(DDos) attacks, you need to take other measures.
+3. Traffic control is a microservice-level rather than process-level function.
- 限流策略配置在microservice.yaml文件中，相关配置项见下表。要开启服务提供者端的限流策略，还需要在处理链中配置服务端限流handler，配置示例如下：
+### Configuration
+
+ Rate limiting policies are configured in the microservice.yaml file. For related configuration items, see Table 2. To enable the rate limiting policy at the provider end, you also need to configure the rate limiting handler on the server in the processing chain and add dependencies in the pom.xml file. An example of microservice.yaml file configuration is as follows:
```yaml
cse:
@@ -96,55 +95,58 @@ cse:
default: qps-flowcontrol-provider
```
- **表2 QPS流控配置项说明**
+ **Table2 Configuration items of the QPS rate limit**
+
+| Configuration Item | Default Value | Value Range | Mandatory | Description | Remarks |
+| :--------------------------------------- | :------------------ | :----------------------- | :-------- | :--------------------------------------- | :--------------------------------------- |
+| cse.flowcontrol.Provider.qps.enabled | true | true/false | No | Specifies whether to enable traffic control at the provider end. | - |
+| cse.flowcontrol.Provider.qps.limit.\[ServiceName\] | 2147483647（max int） | \(0,2147483647\]，Integer | No | Specifies the number of requests allowed per second. | This parameter can only be configured for microservice |
+| cse.flowcontrol.Provider.qps.global.limit | 2147483647（max int） | (0,2147483647\]，Integer | No | Specifies the total number of requests allowed per second at the provider end | If no configuration is set for any specific microservices, this parameter takes effect |
+
+##
+## Fallback Policy
-| 配置项 | 默认值 | 取值范围 | 是否必选 | 含义 | 注意 |
-| :--- | :--- | :--- | :--- | :--- | :--- |
-| cse.flowcontrol.Provider.qps.enabled | true | true/false | 否 | 是否启用Provider流控 | - |
-| cse.flowcontrol.Provider.qps.limit.\[ServiceName\] | 2147483647（max int） | \(0,2147483647\]，整形 | 否 | 每秒钟允许的请求数 | 仅支持microservice一个级别的配置 |
-| cse.flowcontrol.Provider.qps.global.limit | 2147483647（max int） | (0,2147483647\]，整形 | 否 | provider接受请求流量的全局配置 | 没有具体到微服务的配置时，此配置生效 |
+### Concept Description
-## 降级策略
-### 概念阐述
+A fallback policy is used when a service request is abnormal.
-降级策略是当服务请求异常时，微服务所采用的异常处理策略。降级策略有三个相关的技术概念：“隔离”、“熔断”、“容错”：
+There are three key concepts in fallback: isolation, fallbreak, and fault tolerance:
-降级策略有三个相关的技术概念：“隔离”、“熔断”、“容错”：
-* “隔离”是一种异常检测机制，常用的检测方法是请求超时、流量过大等。一般的设置参数包括超时时间、同时并发请求个数等。
-* “熔断”是一种异常反应机制，“熔断”依赖于“隔离”。熔断通常基于错误率来实现。一般的设置参数包括统计请求的个数、错误率等。
-* “容错”是一种异常处理机制，“容错”依赖于“熔断”。熔断以后，会调用“容错”的方法。一般的设置参数包括调用容错方法的次数等。
+* Isolation is an exception detection mechanism. Two common items that need to be detected are timeout duration and the number of concurrent requests.
+* Fallbreak is an exception response mechanism, and it depends on isolation. Fallbreak is triggered based on the error rate. Two common items need to set are the number of requests to collect and error rate.
+* Fault tolerance is an exception handling mechanism that depends on fallbreak. Fault tolerance is called after a fallbreak. For fault tolerance, you need to set the number of fault tolerance call items.
-把这些概念联系起来：当"隔离"措施检测到N次请求中共有M次错误的时候，"熔断"不再发送后续请求，调用"容错"处理函数。这个技术上的定义，是和Netflix Hystrix一致的，通过这个定义，非常容易理解它提供的配置项，参考：[https://github.com/Netflix/Hystrix/wiki/Configuration](https://github.com/Netflix/Hystrix/wiki/Configuration)。当前ServiceComb提供两种容错方式，分别为返回null值和抛出异常。
+During fallback, if M(the threshold) errors are detected in N requests, the consumer will no longer send requests and the fault tolerance mechanism will be enabled. The preceding fallback process is accepted in Netflix Hystrix and helps you configure the parameters. Obtain information about the parameter configuration at [https://github.com/Netflix/Hystrix/wiki/Configuration](https://github.com/Netflix/Hystrix/wiki/Configuration). Currently, ServiceComb provides two types of fault toler [...]
-### 场景描述
+### Scenario
-用户通过配置降级策略，可以设置微服务的异常处理策略。
+By configuring a fallback policy, you can handler microservice exceptions.
-### 配置说明
+### Configuration
- 配置项如表所示。
+ Configuration items of fallback policies are as follows:
- **表3 降级策略相关配置项说明**
+ **Table 3 Configuration items of the fallback policy**
-| 配置项 | 默认值 | 取值范围 | 是否必选 | 含义 | 注意 |
-| :--- | :--- | :--- | :--- | :--- | :--- |
-| cse.isolation.timeout.enabled | FALSE | - | 否 | 是否启用超时检测 | |
-| cse.isolation.timeoutInMilliseconds | 30000 | - | 否 | 超时时间阈值 | |
-| cse.isolation.maxConcurrentRequests | 10 | - | 否 | 最大并发数阈值 | |
-| cse.circuitBreaker.enabled | TRUE | - | 否 | 是否启用熔断措施 | |
-| cse.circuitBreaker.forceOpen | FALSE | - | 否 | 不管失败次数，都进行熔断 | |
-| cse.circuitBreaker.forceClosed | FALSE | - | 否 | 任何时候都不熔断 | 当与forceOpen同时配置时，forceOpen优先。 |
-| cse.circuitBreaker.sleepWindowInMilliseconds | 15000 | - | 否 | 熔断后，多长时间恢复 | 恢复后，会重新计算失败情况。注意：如果恢复后的调用立即失败，那么会立即重新进入熔断。 |
-| cse.circuitBreaker.requestVolumeThreshold | 20 | - | 否 | 10s内统计错误发生次数阈值，超过阈值则触发熔断 | 由于10秒还会被划分为10个1秒的统计周期，经过1s中后才会开始计算错误率，因此从调用开始至少经过1s，才会发生熔断。 |
-| cse.circuitBreaker.errorThresholdPercentage | 50 | - | 否 | 错误率阈值，达到阈值则触发熔断 | |
-| cse.fallback.enabled | TRUE | - | 否 | 是否启用出错后的故障处理措施 | |
-| cse.fallback.maxConcurrentRequests | 10 | - | 否 | 并发调用容错处理措施（cse.fallbackpolicy.policy）的请求数，超过这个值则不再调用处理措施，直接返回异常 | |
-| cse.fallbackpolicy.policy | throwexception | returnnulll \| throwexception | 否 | 出错后的处理策略 | |
+| Configuration Item | Default value | Value Range | Mandatory | Description | Remarks |
+| :--------------------------------------- | :------------- | :---------------------------- | :-------- | :--------------------------------------- | :--------------------------------------- |
+| cse.isolation.timeout.enabled | FALSE | - | No | Specifies whether to enable timeout detection. | |
+| cse.isolation.timeoutInMilliseconds | 30000 | - | No | Specifies the timeout duration threshold. | |
+| cse.isolation.maxConcurrentRequests | 10 | - | No | Specifies the maximum number of concurrent requests. | |
+| cse.circuitBreaker.enabled | TRUE | - | No | Specifies whether to enable fallbreak. | |
+| cse.circuitBreaker.forceOpen | FALSE | - | No | Specifies that fallbreak is enable regardless of the number of failed requests or the error rate. | |
+| cse.circuitBreaker.forceClosed | FALSE | - | No | Specifies that fallbreak can be implemented at any time. | If this parameter and cse.circuitBreaker.forceOpen both need to be configured, cse.circuitBreaker.forceOpen has priority. |
+| cse.circuitBreaker.sleepWindowInMilliseconds | 15000 | - | No | Specifies the duration needed to recover from fallbreak. | After the recovery, the number of failed requests will be recalculated. Not: If the consumer fails to send a request to the provider after the recovery, fallbreak is enabled again. |
+| cse.circuitBreaker.requestVolumeThreshold | 20 | - | No | Specifies the threshold of failed requests sent within 10 seconds. If the threshold is reached, fallbreak is triggered. | Ten seconds will be divided into ten 1 seconds, and the error rate is calculated 1 second later after an error occurred. Therefore, fallbreak can be implemented at least 1 second after the call. |
+| cse.circuitBreaker.errorThresholdPercentage | 50 | - | No | Specifies the threshold of error rate. If the threshold is reached, fallbreak is triggered. | |
+| cse.fallback.enabled | TRUE | - | No | Specifies whether to enable troubleshooting measures after an error occurred. | |
+| cse.fallback.maxConcurrentRequests | 10 | - | No | Specifies the number of fault tolerance(cse.fallbackpolicy.policy) requests concurrently called. If the value exceeds 10, the measures will no longer be called, and exception are returned. | |
+| cse.fallbackpolicy.policy | throwexception | returnnulll \| throwexception | No | Specifies the error handling policies after an error occurred. | |
-**注意：** 谨慎使用cse.isolation.timeout.enabled=true。因为系统处理链都是异步执行，中间处理链的返回，会导致后面处理链的逻辑处理效果丢失。尽可能将cse.isolation.timeout.enabled保持默认值false，并且正确设置网络层超时时间cse.request.timeout=30000。
+**NOTE:** Be cautions when setting cse.isolation.timeout.enabled to TRUE, All processes are asynchronously processed in the system, and any error value returned by an intermediate process because the set timeout duration is reached can cause failure of the follow-up processes. Therefore, you are advised to keep the default value FALSE for cse.isolation.timeout.enabled. For timeout duration from the network aspect, you are advised to set cse.request.timeout=30000.
{: .notice--warning}
-## 示例代码
+## Sample Code
```yaml
cse:
@@ -165,5 +167,6 @@ cse:
policy: throwexception
```
-> **说明：**
-> 降级策略需要启用服务治理能力，对应的服务提供者的handler是`bizkeeper-provider`，服务消费者的handler是`bizkeeper-consumer`。
+> **NOTE:**
+>
+> You need to enable service governance for fallback, The provider handler is bizkeeper-provider, and the consumer handler is bizkeeper-consumer.
diff --git a/_users/service-definition.md b/_users/service-definition.md
index ae6afe2..6f8914d 100644
--- a/_users/service-definition.md
+++ b/_users/service-definition.md
@@ -1,55 +1,55 @@
---
-title: "服务定义"
+title: "Service Definition"
lang: en
ref: service-definition
permalink: /users/service-definition/
-excerpt: "服务定义"
+excerpt: "Service Definition"
last_modified_at: 2017-08-15T15:01:43-04:00
redirect_from:
- /theme-setup/
---
{% include toc %}
-## 概念阐述
+## Concept Description
-服务定义信息是微服务的身份标识，它定义了服务从属于哪个应用，以及名字和版本。服务定义信息中也可以有扩展信息，用于定义服务的属性元数据。
+A service definition identifies a microservice. It defines the service name, version, and the application that the service belongs to. The service definition can also contain extended information defining the attribute metadata of a service.
-## 场景描述
+## Scenario
-当用户定义新的微服务或修改微服务的基本信息时，会涉及到服务定义信息的创建和修改操作。
+To define a new microservice or modify its basic information, you may need to create and modify service definitions.
-## 配置说明
+## Configuration
-介绍涉及microservice.yaml文件的以下配置项，文件在项目中的存放路径为src/main/resources/microservice.yaml。
+This section describe the following configration items related to the microservice.yaml file in the src\main\resources\ directory.
-| 配置项 | 默认值 | 取值范围 | 是否必选 | 含义 | 注意 |
-| :--- | :--- | :--- | :--- | :--- | :--- |
-| APPLICATION\_ID | - | - | 是 | 应用名 | - |
-| service\_description.name | - | - | 是 | 微服务名 | 应确保app内部唯一。微服务名支持数字、大小写字母和"-"、"\_"、"."三个特殊字符，但是不能以特殊字符作为首尾字符，命名规范为：^\[a-zA-Z0-9\]+$\|^\[a-zA-Z0-9\]\[a-zA-Z0-9\_-.\]\*\[a-zA-Z0-9\]$。 |
-| service\_description.version | - | - | 是 | 微服务版本号 | - |
-| service\_description.properties | - | - | 否 | 微服务元数据配置（通过microservice.yaml文件进行配置） | - |
-| service\_description.propertyExtendedClass | - | - | 否 | 微服务元数据配置（通过实现接口PropertyExtended进行配置） | 接口返回的配置会覆盖配置文件中key相同的配置。 |
-| instance\_description.properties | - | - | 否 | 服务实例元数据配置（通过microservice.yaml文件进行配置） | |
-| instance\_description.propertyExtendedClass | - | - | 否 | 微服务元数据配置（通过实现接口PropertyExtended进行配置） | 同service\_description.propertyExtendedClass |
+| Configuration on Item | Default | Range | Mandatory | Description | Remarks |
+| :--------------------------------------- | :------ | :---- | :-------- | :--------------------------------------- | :--------------------------------------- |
+| APPLICATION\_ID | - | - | Yes | Indicates an application name. | - |
+| service\_description.name | - | - | Yes | Indicates a microservice name | The microservice name should be unique within an application. The name can contain digits, uppercase and lowercase letters, hyphens(-), underscores(_), and periods(.); and can neither start nor end with punctuations. The naming rule is as follows: ^\[a-zA-Z0-9\]+$\|^\[a-zA-Z0-9\]\[a-zA-Z0-9\_-.\]\*\[a-zA-Z0-9\]$. |
+| service\_description.version | - | - | Yes | Indicates a service version. | - |
+| service\_description.properties | - | - | No | Configures microservice metadata(in the microservice.yaml file). | - |
+| service\_description.propertyExtendedClass | - | - | No | Configures microservice metadata(through the PropertyExtended API). | The configurations returned through the API will overwrite those with the same keys in the configuration file. |
+| instance\_description.properties | - | - | No | Configures instance metadata(in the microservice.yaml file) | |
+| instance\_description.propertyExtendedClass | - | - | No | Configures microservice metadata(through the PropertyExtended API). | The configurations returned through the API will overwrite thos with the same keys in the configuration file. |
-> 说明：
-- 服务的元数据会随服务一同注册到服务中心，如需修改，则要连同服务version一起变更。若想保持服务version不变，则需要通过服务管理中心统一变更元数据。
-- 默认情况下，微服务只支持同一个app内部的服务调用。可在微服务的properties中配置allowCrossApp=true属性，开启可被跨app访问权限。
+> NOTE：
+- The metadata of a service is registered to the service center with the service. It is changed together with the service version. Changing metadata in the service center will keep the version unchanged.
+- By default, one microservice can be called by only one APPLICATION_ID. You can set allowCrossApp=true in microservice properties to access a microservice acroos APPLICATION_ID.
-## 示例代码
+## Sample Code
```yaml
-APPLICATION_ID: helloTest #应用名
-service_description: #服务描述
- name: helloServer #微服务名称
- version: 0.0.1 #服务版本号
- properties: #元数据
+APPLICATION_ID: helloTest #Application name
+service_description: #Service description
+ name: helloServer #Microservice name
+ version: 0.0.1 #Service version
+ properties: #Metadata
allowCrossApp: false
key1: value1
key2: value2
propertyExtentedClass: io.servicecomb.serviceregistry.MicroServicePropertyExtendedStub
-instance_description: #实例描述
- properties: #元数据
+instance_description: #Instance description
+ properties: #Metadata
key3: value3
propertyExtentedClass: io.servicecomb.serviceregistry.MicroServicePropertyExtendedStub
```
diff --git a/_users/service-heartbeat.md b/_users/service-heartbeat.md
index e5a5ae6..2a776a1 100644
--- a/_users/service-heartbeat.md
+++ b/_users/service-heartbeat.md
@@ -1,31 +1,29 @@
---
-title: "服务心跳"
+title: "Service Heartbeat"
lang: en
ref: service-heartbeat
permalink: /users/service-heartbeat/
-excerpt: "服务心跳"
+excerpt: "Service Heartbeat"
last_modified_at: 2017-08-15T15:01:43-04:00
redirect_from:
- /theme-setup/
---
{% include toc %}
-## 场景描述
+## Scenario
-当微服务实例注册到服务中心后，微服务需要定时向服务中心发送心跳。若服务中心在一定时间内没有收到心跳信息，则会注销此实例。
+After a microservice instance is registered in the service center, the microservice need to periodically send heartbeats to the service center. If the service center receives no heartbeat within a specific period, the instance will be registered.
-## 涉及API
+## Involved APIs
-* `io.servicecomb.serviceregistry.client.ServiceRegistryClient`：服务中心客户端
+* `io.servicecomb.serviceregistry.client.ServiceRegistryClient` is the service client.
-## 配置说明
-
-`ServiceRegistryClient`提供了发送心跳的方法`heartbeat`，用户直接调用即可，示例代码如下：
+`ServiceRegistryClient` provides heartbeat to send heartbeats. You can call it as required. The sample code is as follows:
```java
public static void main(String[] args) throws Exception {
- // 首先需要注册微服务和实例
- // 发送心跳，不然实例会消失
+ // Register the microservice and the instance first
+ // Send the heartbeats. Otherwise, the instances will be lost.
while (true) {
System.out.println("heartbeat sended:" + client.heartbeat(service2.getServiceId(), instance.getInstanceId()));
Thread.sleep(3000);
diff --git a/_users/service-interface-constraints.md b/_users/service-interface-constraints.md
index 9b812f4..8aded14 100644
--- a/_users/service-interface-constraints.md
+++ b/_users/service-interface-constraints.md
@@ -1,17 +1,21 @@
---
-title: "服务接口约束"
+title: "API Constraints"
lang: en
ref: service-interface-constraints
permalink: /users/service-interface-constraints/
-excerpt: "服务接口约束"
+excerpt: "API Constraints"
last_modified_at: 2017-08-15T15:01:43-04:00
redirect_from:
- /theme-setup/
---
{% include toc %}
-## 接口约束说明
-Java Chassis对于接口的使用约束建立在一个简单的原则上：接口定义即接口使用说明，不用通过查看代码实现，就能识别如何调用这个接口。举个例子：
+## API Constraints
+A Java Chassis API constraints is that an API definition should describe its usage. You can identify how to call the API without checking the code.
+
+As developers, we aim at making our APIs easy to be called. However, developers have different understanding about this aim.
+
+For example:
```java
public Person query(String id);
@@ -19,9 +23,9 @@ public Object query(String id);
public class Person {String name;}
```
-显然如果调用接口一，我们知道要传递一个String类型的id参数，返回值是一个Person类型，Person里面存在String类型的name等参数。如果调用接口二，我们不知道怎么处理返回值，必须参考服务提供者的文档说明。可以看出，我们是站在使用者视角这边的，以更容易被使用作为参考。
+Obviously, if API 1 is called, we know that an ID parameter of String type needs to be transferred. The returned value is of Person type, which contains a string-typed name parameter. If API 2 is called, we do not know how to process the returned value, and need to refer to documents provided by the service provider. API 2 is developed in the perspective of RPC developers.
-当我们要将接口发布为REST接口的时候，可以通过使用swagger文件，指定id使用RequestParam或者PathVariable或者RequestBody进行传递，也可以使用SpringMVC或者JAX RS提供的标签来描述。
+To release an API as a REST API, we can use the swagger file; specify the ID to be transmitted using RequestParam, PathVariable, or RequestBody; or use the label provided by SpringMVC or JAX-RS.
```java
public Person query(@RequestParam String id);
@@ -29,38 +33,40 @@ public Person query(@PathVariable String id);
public Person query(@RequestBody String id);
```
-通常，我们会将简单的数据类型，比如String, int等在RequestParam或者PathVariable传递，而把复杂的数据类型使用JSON编码以后在RequestBody传递，以减少HTTP协议限制可能给开发者带来的各种问题。
-## 详细的约束列表
-开发者不能在接口定义的时候使用如下类型：
-* 比较抽象的数据结构: java.lang.Object, net.sf.json.JsonObject等
-* 接口或者抽象类
+Generally , simple data types, such as String and int, are transmitted in RequestParam or PathVariable, and complex data types are transmitted in RequestBody after being coded using JSON, to reduce problems cause by HTTP protocol restrictions on developers.
+
+## Detailed Constraint List
+Developers cannot use the following types to define APIs:
+
+* Abstract data structures, such as java.lang.Object, net.sf.json.JsonObject
+* API or abstract class
```java
public interface IPerson {...}
public abstract class AbstractPerson {...}
```
-* 泛型
+* Generic type
```java
public class PersonHolder<T> {...}
```
-* 上述类型的集合类型或者没指定类型的集合，比如：`List<IPerson>, Map<String, PersonHolder<?>>, List, Map`等。 `List<String>, List<Person>`这些具体类型是支持的。
+* A collection type of the preceding types or a set without a specified type, such as `List<IPerson>, Map<String, PersonHolder<?>>, List, Map`. such as `List<String>, List<Person>` are supported.
-* 包含上述类型作为属性的类型
```java
public class GroupOfPerson {IPerson master ...}
```
-开发者不用担心记不住这些约束，程序会在启动的时候检查不支持的类型，并给与错误提示。
-## 协议上的差异
-尽管ServiceComb-Java-Chassis实现了不同协议之间开发方式的透明，受限于底层协议的限制，不同的协议存在少量差异。
+Developers do not need to worry about the constraints. The program automatically checks them when it is started, and displays types as properties.
+
+## Protocol Difference
+Although ServiceComb-Java-Chassis implements transparent transmission between protocols, there are slight differences between protocols due to the limitations of the underlying protocols:
-* map，key只支持string
+* Map, The key supports only string.
-* highway (protobuf限制)
- 1. 不支持在网络上传递null，包括Collection、array中的元素，map的value
- 2. 长度为0的数组、list，不会在网络上传递，接收端解码出来就是默认值
+* highway (protobuf restriction)
+ 1. Null values cannot be transmitted over the network, including elements in Collection and array, and value in map.
+ 2. The array and list with the length of 0 are not transmitted over the network. The receiver obtains the default value after decoding them.
* springmvc
- 1. 不支持Date作为path、query参数。 因为springmvc直接将Date做toString放在path、query中，与swagger的标准不匹配。
+ 1. Date cannot be used for the path or query parameter. Spring MVC stores toString in path and query, which does not match the swagger standard.
diff --git a/assets/images/thread-model-en.png b/assets/images/thread-model-en.png
new file mode 100644
index 0000000..952899e
Binary files /dev/null and b/assets/images/thread-model-en.png differ
--
To stop receiving notification emails like this one, please contact
['"commits@servicecomb.apache.org" <co...@servicecomb.apache.org>'].