Docs: optimize english documents (#51)

Author: hzlushiliang

docs/en/admin_service.md

@@ -2,7 +2,7 @@
 
 # Overview
 
-The tRPC-Cpp comes with a built-in management service based on the HTTP protocol, providing a set of operational management interfaces for users to view and modify the status of the service. Users can invoke these management commands through a web browser or by constructing HTTP requests manually.
+The tRPC-Cpp comes with a built-in management service based on HTTP protocol, providing a set of operation and management interfaces for users to view and modify the status of services. Users can invoke these management commands through a web browser or by constructing HTTP requests manually.
 
 This document introduces the usage of the management service, where developers can learn the following topics:
 
@@ -34,13 +34,13 @@ server:
 
 The framework provides a set of built-in management commands that allow users to conveniently view and modify the service status.
 
-## The way to access
+## The ways to access
 
 The framework's built-in management commands can be invoked in two ways.
 
-### Access via a web browser
+### Access via web browser
 
-Users can enter `http://admin_ip:admin_port` in a web browser to access the web homepage of the tRPC-Cpp management service. From there, you can click on the corresponding links for each module to perform operations.
+Users can enter `http://admin_ip:admin_port` in a web browser to access the web homepage of the tRPC-Cpp management service. From there, users can click on the corresponding links for each module to perform operations.
 
 ![main page](../images/admin_main_page.png)
 
@@ -53,9 +53,9 @@ The functionality of each module on the homepage is described as follows.
 | heap | View the memory usage. |
 | logs | View and modify the log level of the framework. |
 | stats | View the server-side statistics such as connection count, request count, latency information, etc. |
-| sysvars | View the system resource information, such as CPU configuration, load, IO, and memory usage of current process, etc. |
+| sysvars | View the system resource information, such as CPU configuration, load, IO and memory usage of current process, etc. |
 
-### Invoke by constructing HTTP requests manually
+### Access via constructing HTTP requests manually
 
 Users can construct HTTP requests manually to invoke the management commands provided by the framework, for example, by using the curl tool. The list of available management commands for invocation is as follows.
 
@@ -277,7 +277,7 @@ The statistical variables currently provided by the framework are as follows.
 
 #### The way to enable
 
-**By default, tRPC-Cpp does not allow CPU and memory usage information to be collected through management commands. If you need to collect related information, you need to add the "TRPC_ENABLE_PROFILER" macro definition and link "tcmalloc_and_profiler" when compiling the program.**
+**By default, tRPC-Cpp does not allow CPU and memory usage information to be collected through management commands. If related information needs to be collected, users need to add the "TRPC_ENABLE_PROFILER" macro definition and link "tcmalloc_and_profiler" when compiling the program.**
 
 Below, we will introduce the ways to enable this feature in Bazel and CMake, respectively.
 
@@ -298,14 +298,14 @@ Below, we will introduce the ways to enable this feature in Bazel and CMake, res
 
     Using this compilation option will automatically define the "TRPC_ENABLE_PROFILER" macro, but users need to manually link "libtcmalloc_and_profiler".
 
-    For example, if the user's "libtcmalloc_and_profiler.so" is located in the "/user-path/lib" directory, you can add the compilation option in the .bazelrc file like this:
+    For example, if the user's "libtcmalloc_and_profiler.so" is located in the "/user-path/lib" directory, add the compilation option in the .bazelrc file like this:
 
     ```sh
     # In the .bazelrc file
     build --define trpc_enable_profiler_v2=true
     ```
 
-    And Then link the "libtcmalloc_and_profiler" in the BUILD file of the server:
+    And then link the "libtcmalloc_and_profiler" in the BUILD file of the server:
 
     ```bzl
     cc_binary(
@@ -320,14 +320,14 @@ Below, we will introduce the ways to enable this feature in Bazel and CMake, res
 
 3. Define the "TRPC_ENABLE_PROFILER" macro and link "tcmalloc_and_profiler" manually.
 
-    For example, you can add the compilation macro in the .bazelrc file like this:
+    For example, add the compilation macro in the .bazelrc file like this:
 
     ```sh
     # In the .bazelrc file
     build --copt='-DTRPC_ENABLE_PROFILER'
     ```
 
-    And Then link the "libtcmalloc_and_profiler" in the BUILD file of the server:
+    And then link the "libtcmalloc_and_profiler" in the BUILD file of the server:
 
     ```bzl
     cc_binary(
@@ -342,7 +342,7 @@ Below, we will introduce the ways to enable this feature in Bazel and CMake, res
 
 ##### CMake
 
-You need to define "TRPC_ENABLE_PROFILER" and link "tcmalloc_and_profiler" in the CMakeLists.txt file.
+Users need to define "TRPC_ENABLE_PROFILER" and link "tcmalloc_and_profiler" in the CMakeLists.txt file.
 
 ```cmake
 # define "TRPC_ENABLE_PROFILER"
@@ -464,7 +464,7 @@ $ curl http://admin_ip:admin_port/client_detach -X POST -d 'service_name=trpc.ap
 
 # Custom management commands
 
-The tRPC-Cpp allows users to customize and register management commands to perform additional management operations as needed by the user. For specific usage examples, please refer to the [admin example](../../examples/features/admin/proxy/).
+The tRPC-Cpp allows users to customize and register management commands to perform additional management operations as needed. For specific usage examples, please refer to the [admin example](../../examples/features/admin/proxy/).
 
 Usage:
 
@@ -494,7 +494,7 @@ Usage:
     You can choose to override the `CommandHandle` interface or the `Handle` interface to implement the control logic.
 
     * CommandHandle: It can conveniently return data in JSON format, suitable for commands accessed through the command line.
-    * Handle: It allows flexible control over the format of the returned results, for example, returning data in HTML format.
+    * Handle: It allows flexible control over the format of the returned results, for example, return data in HTML format.
 
     Example:
 

docs/en/architecture_design.md

@@ -40,7 +40,7 @@ The implementation of framework core mainly includes the following modules:
 - client: provides a concurrent and safe general-purpose client implementation, which is mainly responsible for operations related to rpc calls, service discovery, load balancing, circuit breaker, encoding and decoding, and custom filter. All parts support plugin extensions;
 - codec: provides codec-related interfaces, allowing the framework to expand multi protocols, serialization methods, data compression methods, etc.;
 - transport: provides the ability of network transmission, supports transmission methods such as tcp/udp/ssl/unix-socket;
-- runtime: provides the implementation of the framework runtime environment, encapsulates the thread model and io model, supports m:n coroutine (fiber) model, io and handle separation, and model thread model;
+- runtime: provides the implementation of the framework runtime environment, encapsulates the thread model and io model, supports m:n coroutine (fiber) model, io and handle separated and merged thread model;
 - filter: provides the definition of a custom filter, implements the extension capability, such as tracing, metrics, logreplay, etc.;
 
 The service governance plugin implementation mainly includes the following modules:
@@ -80,22 +80,22 @@ The request processing generally includes the following processes:
 1. The server transport calls the Acceptor to wait for the client to establish a connection;
 2. The client initiates a connection establishment request, and the server transport Accept returns a tcp connection;
 3. The server transport determines to dispatch the connection according to the current runtime environment (whether it is fiber runtime);
-     1. If it is a fiber runtime, then select a fiber scheduling group, which will be processed by the Fiber Reactor on the specific fiber scheduling group;
-     2. If not, then select an io thread to be handled by the Reactor of the specific io thread;
-4. Start the logic of receiving packets. The server transport reads the request continuously according to the codec protocol, compression method, and serialization method. Each request will create a msg, which includes the ServerContext of the request, and requests the msg to be handed over to the upper service deal with;
+     1. If it is a fiber runtime, then select a fiber scheduling group, of which the Fiber Reactor will processes the connection;
+     2. If not, then select an io thread, of which the Reactor will processes the connection;
+4. Start the logic of receiving packets. The server transport reads the request continuously according to the codec protocol, compression method, and serialization method. A msg including the ServerContext of the request will be created for each request, then handle the msg over to upper service for further processing;
 5. The service will find the corresponding registered processing function according to the rpc name of the msg, and call the corresponding processing function;
-6. Before calling the corresponding processing function, the filterchain must be executed first, and the end of the filterchain execution is the processing function of the rpc we registered;
-7. Serialize, compress, encode and decode the result of the response, and then return the packet to the client. The return method is divided into synchronous and asynchronous;
-     1. The synchronization method is that after the rpc processing function is executed, the result is directly processed and returned to the client, the default method;
-     2. The asynchronous method is that after the rpc processing function is executed, the package is not returned to the client, but the business itself is asynchronously processed, and the package can be returned by actively calling the framework's return package;
+6. Before calling the corresponding processing function, the filterchain must be executed first, and behind the filterchain execution is the processing function of the rpc we registered;
+7. Serialize, compress and encode the result of the response, and then return the packet to the client. The return method is divided into synchronous and asynchronous;
+     1. The synchronization method is that after the rpc processing function is executed, the result is directly processed and returned to the client, this is the default method;
+     2. The asynchronous method is that after the rpc processing function is executed, the package is not returned to the client, but returned by users by actively calling the framework's interface after asynchronous business logic;
 
 ### Exit
 
 The service exit process generally includes the following processes:
 
 1. Wait for all requests received by the server to be processed(To avoid being unable to exit due to waiting, the default maximum waiting time is set to 5 seconds.It can be configured through server::stop_max_wait_time);
-2. Stop the monitoring and reading events of the server network connection;
-3. Close the server network connection;
+2. Stop the listening and reading events of the server network connection;
+3. Close the server network connections;
 4. Call the `Destroy` method of the `TrpcApp` business subclass to stop the dynamic resources created by the business (for example: started threads);
 5. Stop the dynamic resources created by the plugins (for example: threads started inside the plugins);
 6. Stop the framework runtime environment runtime;
@@ -142,5 +142,4 @@ The workflow of the interceptor filter is as follows:
 
 ![fitler](../images/filter.png)
 
-The ultimate purpose of the interceptor is to allow business logic and framework
-Decoupling and allowing cohesive development of each. You can add or replace different plugin implementations through configuration without modifying the source code.
+The ultimate purpose of the interceptor is to allow business logic and framework decoupled and allow cohesive development of each. You can add or replace different plugin implementations through configuration without modifying the source code.

docs/en/backup_request.md

@@ -2,7 +2,7 @@
 
 # Overview
 
-Sometimes, to ensure availability or reduce tail latency, it is necessary to simultaneously access two services and take the response from whichever arrives first. There are generally two approaches to implementing this functionality:
+Sometimes, to ensure availability or reduce tail latency, it is necessary to simultaneously access two services and take the response from whichever arrives first. There are generally two approaches to implement this functionality:
 
 1. Concurrently send two requests and take the result from the one that returns first.
 2. Set a reasonable resend time. If a request times out or fails

docs/en/basic_tutorial.md

@@ -286,7 +286,7 @@ client:
 
 By the configuration, `Forward` service will use target(ip:port) to access the `HelloWorld` service.
 
-After setting the options of the ServiceProxy, then creating and using the ServiceProxy to access the helloworld service.
+After setting the options of the ServiceProxy, then create and use the ServiceProxy to access the helloworld service.
 
 First, add a constructor to the ForwardServiceServiceImpl class in file `./server/service.h`, and define a GreeterServiceProxy type smart pointer member variable.
 
@@ -400,7 +400,7 @@ global:
         handle_thread_num: 6
 ```
 
-You can choose to merge or separate threadmodel runtime. Here we take the separated threadmodel runtime as an example.
+You can choose to merge or separate threadmodel runtime. Here we take the separate threadmodel runtime as an example.
 
 For detailed separate or merge runtime configuration, please refer to [Framework Configuration](framework_config_full.md).