zhengyangyong commented on a change in pull request #37: update
question-and-answer translation
URL:
https://github.com/apache/incubator-servicecomb-docs/pull/37#discussion_r211164540
##########
File path: java-chassis-reference/en_US/question-and-answer/question_answer.md
##########
@@ -197,79 +196,79 @@ public String sayHello(@RequestBody Person person){
}
```
-# 问题描述： body Model部分暴露
+# Problem: Partial exposure of body Model
-** 解决方法：**
+** Solution:**
-一个接口对应的body对象中，可能有一些属性是内部的，不想开放出去，生成schema的时候不要带出去，使用：
+In the body object corresponding to an interface, there may be some attributes
that are internal. Do not want to open it. Do not bring it out when generating
the schema. Use:
```java
@ApiModelProperty(hidden = true)
```
-# 问题描述：框架获取远端consumer的地址
+# Problem: The framework obtains the address of the remote consumer
-** 解决方法：**
+** Solution:**
-如果使用http rest方式（使用transport-rest-vertx依赖）可以用下面这种方式获取：
+If you use the http rest method (using the transport-rest-vertx dependency)
you can get it in the following way:
```java
HttpServletRequest request = (HttpServletRequest)
invocation.getHandlerContext().get(RestConst.REST_REQUEST);
String host = request.getRemoteHost();
```
-实际场景是拿最外层的地址，所以应该是LB传入到edgeservice，edgeService再放到context外下传递。
+The actual scene is to take the external address, so it should be LB passed to
edgeservice, and edgeService is then passed to the context and passed.
-# 问题描述：对handler描述
+# Problem: Description of the handler
-** 解决方法：**
+** Solution:**
-consumer默认的handler是simpleLB，没有配置的时候handler链会使用这个，如果配置了handler，里面一定要包含lb的handler，否则调用报错，需要在文档里面进行说明。
+Consumer default handler is simpleLB, and the handler chain will use this when
there is no configuration, if the handler is configured, it must contain the lb
handler. Otherwise the call error, need to be described in the document.
-# 问题描述：netty版本问题
+# Problem: Netty version problem
-** 解决方法：**
+** Solution:**
-netty3和netty4是完全不同的三方件，因为坐标跟package都不相同，所以可以共存，但是要注意小版本问题，小版本必须使用的版本。
+Netty3 and netty4 are completely different tripartites because the coordinates
are not the same as the package, so they can coexist, but pay attention to the
minor version problem, the version that the small version must use.
-# 问题描述：服务超时设置
+# Problem: Service Timeout Settings
-** 解决方法：**
+** Solution:**
-在微服务描述文件（microservice.yaml）中添加如下配置：
+Add the following configuration to the microservice description file
(microservice.yaml):
```
servicecomb:
request:
timeout: 30000
```
-# 问题描述：服务治理的处理链顺序是否有要求？
+# Problem: Is there a requirement for the processing chain of service
governance?
-**解决方法：**
+**Solution:**
-处理链的顺序不同，那么系统工作行为也不同。 下面列举一下常见问题。
+The order of the processing chains is different, and the system works
differently. List the common questions below.
-1、loadbalance和bizkeeper-consumer
+1, loadbalance and bizkeeper-consumer
-这两个顺序可以随机组合。但是行为是不一样的。
+These two sequences can be combined randomly. But the behavior is different.
-当loadbalance在前面的时候，那么loadbalance提供的重试功能会在bizkeeper-consumer抛出异常时发生，比如超时等。但是如果已经做了fallbackpolicy配置，比如returnnull，那么loadbalance则不会重试。
+When loadbalance is in the front, the retry function provided by loadbalance
will occur when bizkeeper-consumer throws an exception, such as timeout. But if
you have done a fallback policy configuration, such as return null, then
loadbalance will not retry.
-如果loadbalance在后面，那么loadbalance的重试会延长超时时间，即使重试成功，如果bizkeeper-consumer设置的超时时间不够，那么最终的调用结果也是失败。
+If loadbalance is behind, the retry will extend the timeout. Even if the retry
is successful, if the timeout period set by bizkeeper-consumer is not enough,
the final call result will also fail.
-2、tracing-consumer，sla-consumer，tracing-provider，sla-provider
+2, tracing-consumer, sla-consumer, tracing-provider, sla-provider
-这些处理链建议放到处理链的最开始位置，保证成功、失败的情况都可以记录日志（由于记录日志需要IP等信息，对于消费者，只能放到loadbalance后面）。
+These processing chains are recommended to be placed at the very beginning of
the processing chain to ensure that the success and failure of the log can be
recorded (because the log requires IP and other information, for consumers, can
only be placed behind the loadbalance).
-如果不需要记录客户端返回的异常，则可以放到末尾，只关注网络层返回的错误。但是如果bizkeeper-consumer等超时提前返回的话，则可能不会记录日志。
+If you do not need to record the exception returned by the client, you can put
it to the end and only pay attention to the error returned by the network
layer. However, if the bizkeeper-consumer timeout returns earlier, the log may
not be logged.
-3、建议的顺序
+3. Suggested order
Consumer: loadbalance, tracing-consumer, sla-consumer, bizkeeper-consumer
Provider: tracing-provider, sla-provider, bizkeeper-provider
-这种顺序能够满足大多数场景，并且不容易出现不可理解的错误。
+This order is sufficient for most scenarios and is not prone to
incomprehensible errors.
Review comment:
is not prone to incomprehensible errors ...
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
[email protected]
With regards,
Apache Git Services
