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 2018/08/27 09:02:20 UTC
[incubator-servicecomb-docs] branch master updated (8a1d379 ->
d81d28e)
This is an automated email from the ASF dual-hosted git repository.
liubao pushed a change to branch master
in repository https://gitbox.apache.org/repos/asf/incubator-servicecomb-docs.git.
from 8a1d379 update java-chassis-reference/en_US/build-consumer/invoke-control.md
new bb07346 update java-chassis-reference/en_US/general-development/config.md
new f7c1da9 update java-chassis-reference/en_US/general-development/customized-tracing.md
new 4aae6e3 update java-chassis-reference/en_US/general-development/metrics.md
new 8f7af68 update java-chassis-reference/en_US/general-development/microservice-invocation-chain.md
new d81d28e update java-chassis-reference/en_US/general-development/visit-sc.md
The 5 revisions listed above as "new" are entirely new to this
repository and will be described in separate emails. The revisions
listed as "add" were already present in the repository and have only
been added to this reference.
Summary of changes:
.../en_US/general-development/config.md | 48 +++++------
.../general-development/customized-tracing.md | 49 +++++------
.../en_US/general-development/metrics.md | 98 ++++++++++------------
.../microservice-invocation-chain.md | 53 ++++++------
.../en_US/general-development/visit-sc.md | 23 +++--
5 files changed, 128 insertions(+), 143 deletions(-)
mode change 100644 => 100755 java-chassis-reference/en_US/general-development/config.md
mode change 100644 => 100755 java-chassis-reference/en_US/general-development/customized-tracing.md
mode change 100644 => 100755 java-chassis-reference/en_US/general-development/metrics.md
mode change 100644 => 100755 java-chassis-reference/en_US/general-development/microservice-invocation-chain.md
mode change 100644 => 100755 java-chassis-reference/en_US/general-development/visit-sc.md
[incubator-servicecomb-docs] 05/05: update
java-chassis-reference/en_US/general-development/visit-sc.md
Posted by li...@apache.org.
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/incubator-servicecomb-docs.git
commit d81d28ee25f7c51c4b6f598f72878c5a498fa550
Author: DeanLee <li...@huawei.com>
AuthorDate: Mon Aug 27 11:22:37 2018 +0800
update java-chassis-reference/en_US/general-development/visit-sc.md
---
.../en_US/general-development/visit-sc.md | 23 ++++++++++------------
1 file changed, 10 insertions(+), 13 deletions(-)
diff --git a/java-chassis-reference/en_US/general-development/visit-sc.md b/java-chassis-reference/en_US/general-development/visit-sc.md
old mode 100644
new mode 100755
index 5c9265a..bc4d5a0
--- a/java-chassis-reference/en_US/general-development/visit-sc.md
+++ b/java-chassis-reference/en_US/general-development/visit-sc.md
@@ -1,22 +1,19 @@
-## 概念阐述
+## Concept Description
-系统通过服务中心实现服务之间的发现。服务启动过程中，会向服务中心进行注册。在调用其他服务的时候，会从服务中心查询其他服务的实例信息，比如访问地址、使用的协议以及其他参数。服务中心支持使用PULL和PUSH两种模式通知实例变化。
+The system realizes the discovery between services through the service center. During the service startup process, the service center is registered. When calling other services, the service center will query the instance information of other services, such as the access address, the protocol used, and other parameters. The service center supports the use of PULL and PUSH modes to notify instance changes.
-## 配置说明
+## Configuration instructions
-### 表1-1访问配置中心常用的配置项
+### Table 1-1 Accessing Common Configuration Items in the Configuration Center
-| 配置项 | 参考/默认值 | 取值范围 | 是否必选 | 含义 | 注意 |
+| Configuration Item | Reference / Default | Value Range | Required | Meaning |
| :--- | :--- | :--- | :--- | :--- | :--- |
-| servicecomb.service.registry.address | http://127.0.0.1:30100 | | 是 | 服务中心的地址信息，可以配置多个，用逗号分隔。 | |
-| servicecomb.service.registry.instance.watch | true | | 否 | 是否采用PUSH模式监听实例变化。为false的时候表示使用PULL模式。 | |
-| servicecomb.service.registry.autodiscovery | false | | 否 | 是否自动发现服务中心的地址。当需要配置部分地址，其他地址由配置的服务中心实例发现的时候，开启这个配置。 | |
-| servicecomb.service.registry.instance.healthCheck.interval | 30 | | 否 | 心跳间隔。 | |
-| servicecomb.service.registry.instance.healthCheck.times | 3 | | 否 | 允许的心跳失败次数。interval \* times决定了实例被自动注销的时间。如果服务中心等待这么长的时间没有收取到心跳，会注销实例。 | |
-
-
-
+| servicecomb.service.registry.address | http://127.0.0.1:30100 | | Yes | Service center address information, you can configure multiple, separated by commas. | |
+| servicecomb.service.registry.instance. Watch | true | | No | Whether to monitor instance changes in PUSH mode. When it is false, it means using PULL mode. | |
+| servicecomb.service.registry. Autodiscovery | false | | No | Whether to automatically discover the address of the service center. This configuration is enabled when a partial address needs to be configured, and other addresses are discovered by the configured service center instance. | |
+| servicecomb.service.registry.instance.healthCheck.interval | 30 | | No | Heartbeat interval. | |
+| servicecomb.service.registry.instance.healthCheck.times | 3 | | No | Number of allowed heartbeat failures. Interval \* times determines when the instance is automatically logged out. If the service center waits for such a long time and does not receive a heartbeat, the instance will be logged off. | |
[incubator-servicecomb-docs] 04/05: update
java-chassis-reference/en_US/general-development/microservice-invocation-chain.md
Posted by li...@apache.org.
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/incubator-servicecomb-docs.git
commit 8f7af682230bad21b4dd787034969e0fdd387eac
Author: DeanLee <li...@huawei.com>
AuthorDate: Mon Aug 27 11:22:29 2018 +0800
update java-chassis-reference/en_US/general-development/microservice-invocation-chain.md
---
.../microservice-invocation-chain.md | 53 ++++++++++------------
1 file changed, 25 insertions(+), 28 deletions(-)
diff --git a/java-chassis-reference/en_US/general-development/microservice-invocation-chain.md b/java-chassis-reference/en_US/general-development/microservice-invocation-chain.md
old mode 100644
new mode 100755
index ce2301c..5e9193a
--- a/java-chassis-reference/en_US/general-development/microservice-invocation-chain.md
+++ b/java-chassis-reference/en_US/general-development/microservice-invocation-chain.md
@@ -1,62 +1,59 @@
-## 概念阐述
+## Concept Description
-微服务架构解决了很多单体应用带来的问题，但同时也需要我们付出额外的代价。由于网络的不稳定性带来的请求处理延迟就是代价之一。
+The microservices architecture solves the problems of many single applications, but it also requires us to pay extra. Request processing latency due to network instability is one of the costs.
-在单体应用中，所有模块都在同一个进程中运行，所以并没有模块间互通的问题。但微服务架构中，服务间通过网络沟通，因此我们不得不处理和网络有关的 问题，例如：延迟、超时、网络分区等。
+In a single application, all modules run in the same process, so there is no inter-module interworking problem. However, in the micro-service architecture, services communicate through the network, so we have to deal with network-related issues such as delays, timeouts, network partitions, and so on.
-另外，随着业务的扩展服务增多，我们很难洞察数据如何在蛛网般复杂的服务结构中流转。我们如何才能有效的监控网络延迟并且可视化服务中的数据流转呢？
+Also, as the business expands its services, it is difficult to see how data flows through a spider-like complex service structure. How can we effectively monitor network latency and visualize data flow in services?
-**分布式调用链追踪**用于有效地监控微服务的网络延时并可视化微服务中的数据流转。
+**Distributed Call Chain Tracking** is used to monitor network latency for microservices effectively and visualize data flow in microservices.
## Zipkin
-> [Zipkin](http://zipkin.io/)是一个分布式调用链追踪系统。 它能帮助用户收集时序数据用以定位微服务中的延迟问题，它同时管理追踪数据的收集 和查询。Zipkin 的设计基于 Google [Dapper paper](http://research.google.com/pubs/pub36356.html)。
+> [Zipkin] (http://zipkin.io/) is a distributed call chain tracking system. It helps users collect time series data to locate latency issues in microservices, and it also manages the collection and query of trace data. Zipkin's design is based on Google [Dapper paper] (http://research.google.com/pubs/pub36356.html).
-ServiceComb 集成了 Zipkin 提供自动调用链追踪能力，如此一来用户只需要专注实现其业务需求。
+ServiceComb integrates Zipkin to provide automatic call chain tracking capabilities so that users only need to focus on their business needs.
-## 使用步骤:
+## Steps for usage:
-### 添加依赖
+### Adding dependencies
-基于 ServiceComb Java Chassis 的微服务只需要添加如下依赖到 pom.xml：
+Microservices based on ServiceComb Java Chassis only need to add the following dependency to pom.xml:
```xml
-<dependency>
+<dependency>
<groupId>org.apache.servicecomb</groupId>
<artifactId>handler-tracing-zipkin</artifactId>
</dependency>
```
-如果微服务是基于 Spring Cloud + Zuul 的 API 网关，例如 workshop demo 中的 manager service ，我们还需要加入如下的额外依赖：
+If the microservice is based on Spring Cloud + Zuul's API gateway, such as the manager service in the workshop demo, we also need to add the following additional dependencies:
```xml
-<dependency>
+<dependency>
<groupId>org.apache.servicecomb</groupId>
<artifactId>spring-cloud-zuul-zipkin</artifactId>
</dependency>
```
-### 配置追踪处理和数据收集 {#配置追踪处理和数据收集}
+### Configuring Tracking Processing and Data Collection {#Configuration Tracking Processing and Data Collection}
-在microservice.yaml文件中设置追踪处理器和数据收集服务地址
+Set the tracking processor and data collection service address in the microservice.yaml file
```yaml
- servicecomb:
- handler:
- chain:
- Consumer:
+ servicecomb:
+ handler:
+ chain:
+ Consumer:
default: tracing-consumer
- Provider:
+ Provider:
default: tracing-provider
- servicecomb:
- tracing:
- collector:
+ servicecomb:
+ tracing:
+ collector:
address: http://zipkin.servicecomb.io:9411
```
-就这样，在加了两个配置项，没改动一行代码的情况下，我们启动了基于 Zipkin 和 Java chassis 的分布式调用链追踪的功能。
-
-**注意 **如果项目中的其他依赖也引入了 zipkin （例如 Spring Cloud），可能导致 zipkin 版本不一致而运行出错，这时需要在项目 pom 中声明 zipkin 版本。
-
-
+In this way, with the addition of two configuration items and no changes to one line of code, we started the distributed call chain tracking function based on Zipkin and Java chassis.
+**Note **If other dependencies in the project also introduce a zipkin (such as Spring Cloud), which may cause the zipkin version to be inconsistent and run incorrectly, you need to declare the zipkin version in the project pom.
[incubator-servicecomb-docs] 02/05: update
java-chassis-reference/en_US/general-development/customized-tracing.md
Posted by li...@apache.org.
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/incubator-servicecomb-docs.git
commit f7c1da9266bda7c19970583945e4b952fe6d1142
Author: DeanLee <li...@huawei.com>
AuthorDate: Mon Aug 27 11:22:06 2018 +0800
update java-chassis-reference/en_US/general-development/customized-tracing.md
---
.../general-development/customized-tracing.md | 49 ++++++++++------------
1 file changed, 23 insertions(+), 26 deletions(-)
diff --git a/java-chassis-reference/en_US/general-development/customized-tracing.md b/java-chassis-reference/en_US/general-development/customized-tracing.md
old mode 100644
new mode 100755
index 78e8ad6..905fdcc
--- a/java-chassis-reference/en_US/general-development/customized-tracing.md
+++ b/java-chassis-reference/en_US/general-development/customized-tracing.md
@@ -1,25 +1,25 @@
-## 概念阐述
+## Concept Description
-分布式调用链追踪提供了服务间调用的时序信息，但服务内部的链路调用信息对开发者同样重要，如果能将两者合二为一，就能提供更完整的调用链，更容易定位错误和潜在性能问题。
+Distributed call chain tracking provides timing information for calls between services, but the link call information inside the service is equally important to the developer. If you can combine the two into one, you can provide a more complete call chain, which is easier to locate. Errors and potential performance issues.
-## 前提条件
+## Prerequisites
-* 使用自定义打点功能需要首先配置并启用Java Chassis微服务调用链。
+* Using the custom dot function requires first configuring and enabling the Java Chassis microservice call chain.
-## 注意事项
+## Precautions
-* 使用`@Span`注释的自定义打点功能只支持和Java Chassis调用请求同一线程的方法调用。
-* 添加`@Span`注释的方法必须是Spring管理的Bean，否则需要按这里[提到的方法](https://stackoverflow.com/questions/41383941/load-time-weaving-for-non-spring-beans-in-a-spring-application)配置。
+* The custom dot function using the `@Span` annotation only supports method calls that are requesting the same thread as the Java Chassis call.
+* The method to add the `@Span` annotation must be a Spring-managed bean, otherwise you need to press the [Methods mentioned] (https://stackoverflow.com/questions/41383941/load-time-weaving-for-non-spring -beans-in-a-spring-application) configuration.
-## 自定义调用链打点
+## Custom call chain management
-该功能集成了Zipkin，提供`@Span`注释为需要追踪的方法自定义打点。Java Chassis将自动追踪所有添加`@Span`注释的方法，把每个方法的本地调用信息与服务间调用信息连接起来。
+This feature integrates Zipkin and provides the `@Span` annotation for custom tracking of methods that need to be tracked. Java Chassis will automatically track all methods that add `@Span` annotations, linking the local call information of each method to the call information between services.
-## 使用步骤:
+## Steps for usage:
-### 添加依赖
+### Adding dependencies
-基于 ServiceComb Java Chassis 的微服务只需要添加如下依赖到 pom.xml：
+Microservices based on ServiceComb Java Chassis only need to add the following dependency to pom.xml:
```xml
<dependency>
@@ -28,9 +28,9 @@
</dependency>
```
-### 启用自定义打点功能 {#配置追踪处理和数据收集}
+### Enable custom management function {#Configure tracking processing and data collection}
-在应用入口或Spring配置类上添加`@EnableZipkinTracing`注释：
+Add the `@EnableZipkinTracing` annotation to the application portal or Spring configuration class:
```java
@SpringBootApplication
@@ -42,9 +42,9 @@ public class ZipkinSpanTestApplication {
}
```
-### 定制打点
+### Customized management
-在需要定制打点的方法上添加`@Span`注释：
+Add the `@Span` annotation to the method that requires custom management:
```java
@Component
@@ -63,23 +63,23 @@ public class SlowRepoImpl implements SlowRepo {
}
```
-就这样，通过使用`@Span`注释，我们启动了基于 Zipkin 的自定义打点功能。
+In this way, by using the `@Span` annotation, we started the Zipkin-based custom management function.
-## 定制上报的数据
+## Customized reported data
-通过自定义打点上报的调用链包含两条数据：
+The call chain that is escalated by custom management contains two pieces of data:
-* **span name** 默认为当前注释的方法全名。
-* **call.path** 默认为当前注释的方法签名。
+* **span name** defaults to the full name of the method currently being annotated.
+* **call.path** defaults to the method signature of the current annotation.
-例如，上述例子`SlowRepoImp`里上报的数据如下：
+For example, the data reported in the above example `SlowRepoImp` is as follows:
| key | value |
| :--- | :--- |
| span name | crawl |
| call.path | public abstract java.lang.String org.apache.servicecomb.tests.tracing.SlowRepo.crawl\(\) throws java.lang.InterruptedException |
-如果需要定制上报的数据内容，可以传入自定义的参数：
+If you need to customize the reported data content, you can pass in the custom parameters:
```java
public static class CustomSpanTask {
@@ -89,6 +89,3 @@ public class SlowRepoImpl implements SlowRepo {
}
}
```
-
-
-
[incubator-servicecomb-docs] 01/05: update
java-chassis-reference/en_US/general-development/config.md
Posted by li...@apache.org.
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/incubator-servicecomb-docs.git
commit bb0734625bc461401a0b12b9b3b4310a944897b3
Author: DeanLee <li...@huawei.com>
AuthorDate: Mon Aug 27 11:21:58 2018 +0800
update java-chassis-reference/en_US/general-development/config.md
---
.../en_US/general-development/config.md | 48 +++++++++++-----------
1 file changed, 24 insertions(+), 24 deletions(-)
diff --git a/java-chassis-reference/en_US/general-development/config.md b/java-chassis-reference/en_US/general-development/config.md
old mode 100644
new mode 100755
index 279297f..d925904
--- a/java-chassis-reference/en_US/general-development/config.md
+++ b/java-chassis-reference/en_US/general-development/config.md
@@ -1,38 +1,38 @@
-# 使用动态配置
+# Using dynamic configuration
-ServiceComb提供了分层次的配置机制。按照优先级，分为：
-* 配置中心（动态配置）
-* Java System Property（-D参数）
-* 环境变量
-* 配置文件，microservice.yaml。microservice.yaml文件从classpath扫描，可以允许存在很多份。通过servicecomb-config-order指定优先级。
+ServiceComb provides a hierarchical configuration mechanism. According to the priority, it is divided into:
+* Configuration Center (dynamic configuration)
+* Java System Property (-D parameter)
+* Environmental variables
+* Configuration file, microservice.yaml. The microservice.yaml file is scanned from the classpath and can be allowed to exist in many copies. Specify the priority by servicecomb-config-order.
-配置文件默认是classpath下的microservice.yaml, 但是可以通过环境变量传入其他文件，可以设置的环境变量为：
+The configuration file defaults to microservice.yaml under the classpath, but can be passed to other files through environment variables. The environment variables that can be set are:
-|变量|描述|
+|Variable|Description|
|---|---|
-|servicecomb.configurationSource.additionalUrls|配置文件的列表，以,分隔的多个包含具体位置的完整文件名|
-|servicecomb.configurationSource.defaultFileName|默认配置文件名|
+|servicecomb.configurationSource.additionalUrls|List of configuration files, separated by multiple full file names containing specific locations |
+|servicecomb.configurationSource.defaultFileName|Default configuration file name|
-动态配置的默认实现是config-cc客户端，对接配置中心，配置项如下：
+The default implementation of the dynamic configuration is the config-cc client, which is connected to the configuration center. The configuration items are as follows:
-|变量|描述|
+|Variable|Description|
|---|---|
-|servicecomb.config.client.refreshMode|应用配置的刷新方式，0为config-center主动push，1为client周期pull，默认为0|
-|servicecomb.config.client.refreshPort|config-center推送配置的端口|
-|servicecomb.config.client.tenantName|应用的租户名称|
-|servicecomb.config.client.serverUri|config-center访问地址，http(s)://{ip}:{port}，以,分隔多个地址(可选，当cse.config.client.regUri配置为空时该配置项才会生效)|
+|servicecomb.config.client.refreshMode|Application configuration refresh mode, 0 is config-center active push, 1 is client cycle pull, default is 0|
+|servicecomb.config.client.refreshPort|config-center push configured port|
+|servicecomb.config.client.tenantName|Application tenant name|
+|servicecomb.config.client.serverUri|config-center access address, http(s)://{ip}:{port}, to separate multiple addresses (optional, when cse.config.client.regUri is configured as This configuration item will take effect when empty))|
-## 在程序中获取配置信息
+## Get configuration information in the program
-开发者使用一致的API获取配置，不区分配置的存储路径：
+Developers use a consistent API to get the configuration, regardless of the configured storage path:
```
DynamicDoubleProperty myprop = DynamicPropertyFactory.getInstance().getDoubleProperty("trace.handler.sampler.percent", 0.1);
```
-具体方法可参考[API DOC](https://netflix.github.io/archaius/archaius-core-javadoc/com/netflix/config/DynamicPropertyFactory.html)
+For details, please refer to [API DOC] (https://netflix.github.io/archaius/archaius-core-javadoc/com/netflix/config/DynamicPropertyFactory.html)
-## 处理配置变更
-可以注册callback处理配置变更：
+## Handling configuration changes
+You can register for a callback to handle configuration changes:
```
myprop.addCallback(new Runnable() {
public void run() {
@@ -41,8 +41,8 @@ DynamicDoubleProperty myprop = DynamicPropertyFactory.getInstance().getDoublePro
});
```
-## 进行配置项映射
-有些情况下，我们要屏蔽我们使用的一些开源组件的配置并给用户提供我们自己的配置项。在这种情况下，可以通过classpath下的config.yaml进行映射定义：
+## Performing configuration item mapping
+In some cases, we want to block the configuration of some of the open source components we use and provide our users with their own configuration items. In this case, you can define the mapping through config.yaml under the classpath:
```
registry:
client:
@@ -50,4 +50,4 @@ registry:
defaultZone: eureka.client.serviceUrl.defaultZone
```
-定义映射后，在配置装载的时候框架会默认进行映射，把以我们定义的配置项映射为开源组件可以认的配置项。
+After the mapping is defined, the framework maps by default when the configuration is loaded, and the configuration items defined by us are mapped to the configuration items that the open source component can recognize.
[incubator-servicecomb-docs] 03/05: update
java-chassis-reference/en_US/general-development/metrics.md
Posted by li...@apache.org.
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/incubator-servicecomb-docs.git
commit 4aae6e377372d32c43ea1acff77989986eeee3f8
Author: DeanLee <li...@huawei.com>
AuthorDate: Mon Aug 27 11:22:18 2018 +0800
update java-chassis-reference/en_US/general-development/metrics.md
---
.../en_US/general-development/metrics.md | 98 ++++++++++------------
1 file changed, 46 insertions(+), 52 deletions(-)
diff --git a/java-chassis-reference/en_US/general-development/metrics.md b/java-chassis-reference/en_US/general-development/metrics.md
old mode 100644
new mode 100755
index 5efab37..b9e3883
--- a/java-chassis-reference/en_US/general-development/metrics.md
+++ b/java-chassis-reference/en_US/general-development/metrics.md
@@ -1,51 +1,51 @@
-# 一、Metrics介绍
+# First, the introduction of Metrics
-1. 基于[netflix spectator](https://github.com/Netflix/spectator)
-2. Foundation-metrics通过SPI机制加载所有MetricsInitializer实现，实现者可以通过MetricsInitializer中的getOrder规划执行顺序，order数字越小，越先执行。
-3. Metrics-core实现3类MetricsInitializer：
- 1. DefaultRegistryInitializer: 实例化并注册spectator-reg-servo，设置较小的order，保证比下面2类MetricsInitializer先执行
- 2. Meters Initializer: 实现TPS、时延、线程池、jvm资源等等数据的统计
- 3. Publisher: 输出统计结果，内置了日志输出，以及通过RESTful接口输出
-4. Metrics-prometheus提供与prometheus对接的能力
+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.
+3. Metrics-core implements 3 types of MetricsInitializer:
+ 1. DefaultRegistryInitializer: Instantiate and register spectator-reg-servo, set a smaller order, and ensure that it is executed before the following two types of MetricsInitializer
+ 2. Meters Initializer: Statistics of data such as TPS, delay, thread pool, jvm resources, etc.
+ 3. Publisher: Output statistics, built-in log output, and output via RESTful interface
+ 4. Metrics-prometheus provides the ability to interface with prometheus
-# 二、统计项汇总
+# Second, the summary of statistical items
<table border="1" style="font-size: 8px">
<tr>
<th>Name</th>
<th>Tag keys</th>
<th>Tag values</th>
- <th style="min-width: 450px">含义</th>
+ <th style="min-width: 450px">meaning</th>
</tr>
<tr>
<td rowspan="11">servicecomb.invocation</td>
<td>role</td>
<td>CONSUMER、PRODUCER</td>
- <td>是CONSUMER还是PRODUCER端的统计</td>
+ <td>Is the CONSUMER or the statistics of the PRODUCER side?</td>
</tr>
<tr>
<td>operation</td>
<td>${microserviceName}.${schemaId}.${operationName}</td>
- <td>调用的方法名</td>
+ <td>Method name</td>
</tr>
<tr>
<td>transport</td>
- <td>highway或rest</td>
- <td>调用是在哪个传输通道上发生的</td>
+ <td>highway or rest</td>
+ <td>On which transmission channel the call occurs</td>
</tr>
<tr>
<td rowspan="3">stage</td>
<td>total</td>
- <td>全流程的统计</td>
+ <td>Full process statistics</td>
</tr>
<tr>
<td>queue</td>
- <td>仅在producer端使用线程池时有意义表示调用在producer线程池中排队的统计</td>
+ <td>It only makes sense to call the statistics queued in the producer thread pool when using the thread pool on the producer side.</td>
</tr>
<tr>
<td>execution</td>
- <td>仅在producer端有意义表示业务逻辑执行的统计</td>
+ <td>Statistically representing the execution of business logic only on the producer side</td>
</tr>
<tr>
<td>status</td>
@@ -55,55 +55,54 @@
<tr>
<td rowspan="4">statistic</td>
<td>count</td>
- <td>平均每秒调用次数，即TPS<br>count=统计周期内的调用次数/周期（秒）</td>
+ <td>Average number of calls per second, ie TPS<br>count=Number of calls/cycles in the statistical period (seconds)</td>
</tr>
<tr>
<td>totalAmount</td>
- <td>单位为秒<br>totalAmount=统计周期内的调用耗时总时长/周期（秒）<br>totalAmount除以count即可得到平均时延</td>
+ <td> in seconds<br>totalAmount=Total timeout/cycle (in seconds) for calls in the statistical period<br>totalAmount divided by count to get the average delay</td>
</tr>
<tr>
<td>totalOfSquares </td>
- <td>totalOfSquares=统计周期内的每一个调用耗时的平方之和/周期（秒）</td>
+ <td>totalOfSquares=sum of squares of each call in the statistical period/cycle (seconds)</td>
</tr>
<tr>
<td>max</td>
- <td>统计周期内最大的调用耗时，单位为秒</td>
+ <td>The maximum call time in the statistical period, in seconds</td>
</tr>
<tr>
<td>threadpool.taskCount</td>
<td rowspan="7">id</td>
<td rowspan="7">${threadPoolName}</td>
- <td>统计周期内平均每秒提交的任务数<br>taskCount=（completed + queue + active）/周期（秒）</td>
+ <td>Average number of tasks submitted per second during the statistical period<br>taskCount=(completed + queue + active)/period (seconds)</td>
</tr>
<tr>
<td>threadpool.completedTaskCount </td>
- <td>统计周期内平均每秒完成的任务数<br>completedTaskCount=completed/周期（秒）</td>
+ <td>The average number of tasks completed per second during the statistical period<br>completedTaskCount=completed/cycle (seconds)</td>
</tr>
<tr>
<td>threadpool.currentThreadsBusy </td>
- <td>当前的活动线程数，即当前正在执行的任务数</td>
- </tr>
+ <td>The current number of active threads, ie the number of tasks currently being executed</td>
<tr>
<td>threadpool.maxThreads </td>
- <td>最大允许的线程数</td>
+ <td>Maximum number of threads allowed</td>
</tr>
<tr>
<td>threadpool.poolSize </td>
- <td>当前实际线程数</td>
+ <td>The current actual number of threads</td>
</tr>
<tr>
<td>threadpool.corePoolSize </td>
- <td>最小线程数</td>
+ <td>Minimum number of threads</td>
</tr>
<tr>
<td>threadpool.queueSize </td>
- <td>当前正在排队的任务数</td>
+ <td>Number of tasks currently queued</td>
</tr>
</table>
-# 三、使用方法
+# Third, how to use.
-1.Maven依赖
+1.Maven dependence.
```
<dependency>
@@ -113,18 +112,18 @@
</dependency>
```
-_注：请将version字段修改为实际版本号；如果版本号已经在dependencyManagement中声明，则这里不必写版本号_
+_Note: Please change the version field to the actual version number; if the version number has been declared in the dependencyManagement, then you do not have to write the version number here_
-2.配置说明
+2. Configuration instructions
-| 配置项 | 默认值 | 含义 |
+| Configuration Item | Default | Meaning |
| :--- | :--- | :--- |
-| Servicecomb.metrics.window\_time | 60000 | 统计周期，单位为毫秒TPS、时延等等周期性的数据，每周期更新一次，在周期内获取到的值，实际是上一周期的值 |
-| servicecomb.metrics.publisher.defaultLog.enabled | false | 是否输出默认的统计日志 |
+| Servicecomb.metrics.window\_time | 60000 | Statistical period, in milliseconds TPS, delay, etc. Periodic data, updated once per cycle, the value obtained in the cycle, actually the value of the previous cycle |
+| servicecomb.metrics.publisher.defaultLog.enabled | false | Whether to output the default statistics log |
-3.通过RESTful访问
-只要微服务开放了rest端口，则使用浏览器访问http://ip:port/metrics 即可，
-将会得到下面格式的json数据：
+3. Access via RESTful
+As long as the microservices open the rest port, use a browser to access http://ip:port/metrics.
+will get json data in the following format:
```
{
@@ -174,20 +173,15 @@ _注：请将version字段修改为实际版本号；如果版本号已经在dep
```
-# 四、业务定制
-
-因为ServiceComb已经初始化了servo的registry，所以业务不必再创建registry
-
-实现MetricsInitializer接口，定义业务级的Meters，或实现定制的Publisher，再通过SPI机制声明自己的实现即可。
-
-1.Meters:
- 创建Meters能力均由spectator提供，可查阅[netflix spectator](https://github.com/Netflix/spectator)文档
-
-2.Publisher:
-周期性输出的场景，比如日志场景，通过eventBus订阅org.apache.servicecomb.foundation.metrics.PolledEvent，PolledEvent.getMeters()即是本周期的统计结果
-非周期性输出的场景，比如通过RESTful接口访问，通过globalRegistry.iterator()即可得到本周期的统计结果
-
+# Fourth, business customization
+Because ServiceComb has initialized the registry's registry, the business no longer has to create a registry.
+Implement the MetricsInitializer interface, define the business-level Meters, or implement a custom Publisher, and then declare your implementation through the SPI mechanism.
+1.Meters:
+Creating Meters capabilities is provided by spectator, available in the [netflix spectator] (https://github.com/Netflix/spectator) documentation
+2.Publisher:
+Periodically output scenarios, such as log scenarios, subscribe to org.apache.servicecomb.foundation.metrics.PolledEvent via eventBus, PolledEvent.getMeters() is the statistical result of this cycle.
+Non-periodic output scenarios, such as access through the RESTful interface, the statistical results of this cycle can be obtained through globalRegistry.iterator()