zhengyangyong commented on a change in pull request #49: Catelog dir translation URL: https://github.com/apache/incubator-servicecomb-docs/pull/49#discussion_r212792221
########## File path: java-chassis-reference/en_US/catalog/general-develop.md ########## @@ -1,81 +1,81 @@ -## 访问服务中心 -系统通过服务中心实现服务之间的发现。服务启动过程中，会向服务中心进行注册。在调用其他服务的时候，会从服务中心查询其他服务的实例信息，比如访问地址、使用的协议以及其他参数。服务中心支持使用PULL和PUSH两种模式通知实例变化。 +## Access Service Center +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. -## 使用动态配置 -ServiceComb提供了分层次的配置机制。按照优先级，分为： -• 配置中心（动态配置） -• Java System Property（-D参数） -• 环境变量 -• 配置文件，microservice.yaml。microservice.yaml文件从classpath扫描，可以允许存在很多份。通过servicecomb-config-order指定优先级。 +## Using dynamic configuration +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. -## 应用性能监控 - 一、Metrics介绍 - 二、统计项汇总 - 三、使用方法 +## Application Performance Monitoring + 1. The introduction of Metrics + 2. The summary of statistical items + 3. The usage -## 微服务调用链 -微服务架构解决了很多单体应用带来的问题，但同时也需要我们付出额外的代价。由于网络的不稳定性带来的请求处理延迟就是代价之一。 +## Micro Service Call Chain +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. -另外，随着业务的扩展服务增多，我们很难洞察数据如何在蛛网般复杂的服务结构中流转。我们如何才能有效的监控网络延迟并且可视化服务中的数据流转呢？ +In addition, 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 effectively monitor network latency for microservices and visualize data flow in microservices. -## 自定义调用链打点 -分布式调用链追踪提供了服务间调用的时序信息，但服务内部的链路调用信息对开发者同样重要，如果能将两者合二为一，就能提供更完整的调用链，更容易定位错误和潜在性能问题。 - -## 本地开发和测试 -本小节介绍如何在开发者本地进行消费者/提供者应用的开发调试。开发服务提供者请参考3 开发服务提供者章节，开发服务消费者请参考4 开发服务消费者。服务提供者和消费提供者均需要连接到在远程的服务中心，为了本地微服务的开发和调试，本小节介绍了两种搭建本地服务中心的方法进行本地微服务调试： +## Custom call chain management +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. Review comment: link call -> method call ---------------------------------------------------------------- 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
