[skywalking] branch master updated: Refine concepts and designs (#6724)

[ke...@apache.org]

This is an automated email from the ASF dual-hosted git repository.

kezhenxu94 pushed a commit to branch master
in repository https://gitbox.apache.org/repos/asf/skywalking.git


The following commit(s) were added to refs/heads/master by this push:
     new 024f810  Refine concepts and designs (#6724)
024f810 is described below

commit 024f8104959531d902c181f62ad0da34d8ee60fa
Author: Wing <69...@users.noreply.github.com>
AuthorDate: Sat Apr 10 16:56:09 2021 +0800

    Refine concepts and designs (#6724)
---
 docs/en/concepts-and-designs/service-mesh-probe.md | 28 +++++++++++-----------
 docs/en/concepts-and-designs/ui-overview.md        | 14 +++++------
 2 files changed, 21 insertions(+), 21 deletions(-)

diff --git a/docs/en/concepts-and-designs/service-mesh-probe.md b/docs/en/concepts-and-designs/service-mesh-probe.md
index 9d11dc1..423fb43 100644
--- a/docs/en/concepts-and-designs/service-mesh-probe.md
+++ b/docs/en/concepts-and-designs/service-mesh-probe.md
@@ -1,28 +1,28 @@
 # Service Mesh Probe
-Service Mesh probes use the extendable mechanism provided in Service Mesh implementor, like Istio.
+Service Mesh probes use the extendable mechanism provided in the Service Mesh implementor, like Istio.
 
 ## What is Service Mesh?
-The following explanation came from Istio documents.
-> The term service mesh is often used to describe the network of microservices that make up such applications and the interactions between them.
+The following explanation comes from Istio's documentation.
+> The term "service mesh" is often used to describe the networks of microservices that make up such applications and the interactions between them.
 As a service mesh grows in size and complexity, it can become harder to understand and manage.
 Its requirements can include discovery, load balancing, failure recovery, metrics, and monitoring, and often more complex operational requirements
 such as A/B testing, canary releases, rate limiting, access control, and end-to-end authentication.
 
 ## Where does the probe collect data from?
-Istio is a very typical Service Mesh design and implementor. It defines **Control Panel** and **Data Panel**,
-which are widely used. Here is Istio Architecture:
+Istio is a typical Service Mesh design and implementor. It defines **Control Panel** and **Data Panel**,
+which are widely used. Here is the Istio Architecture:
 
 ![Istio Architecture](https://istio.io/latest/docs/ops/deployment/architecture/arch.svg)
 
-Service Mesh probe can choose to collect data from **Data Panel**. In Istio, it means collecting telemetry data from 
-Envoy sidecar(Data Panel). The probe collects two telemetry entities from client side and server side per request.
+The Service Mesh probe can choose to collect data from **Data Panel**. In Istio, it means collecting telemetry data from 
+Envoy sidecar (Data Panel). The probe collects two telemetry entities from the client end and the server end per request.
 
 ## How does Service Mesh make backend work?
-From the probe, you can see there must have no trace related in this kind of probe, so why SkyWalking
-platform still works?
+In this kind of probes, you can see that there is no trace related to them. So how does the SkyWalking
+platform manage to work?
 
-Service Mesh probes collects telemetry data from each request, so it knows the source, destination,
-endpoint, latency and status. By those, backend can tell the whole topology map by combining these call
-as lines, and also the metrics of each nodes through their incoming request. Backend asked for the same
-metrics data from parsing tracing data. So, the right expression is:
-**Service Mesh metrics are exact the metrics, what the traces parsers generate. They are same.**
+The Service Mesh probe collects telemetry data from each request, so they know about information such as the source, destination,
+endpoint, latency and status. From these information, the backend can tell the whole topology map by combining these calls
+into lines, as well as the metrics of each node through their incoming requests. The backend requests for the same
+metrics data by parsing the trace data. In short:
+**The Service Mesh metrics work exactly the same way as the metrics that are generated by trace parsers.**
diff --git a/docs/en/concepts-and-designs/ui-overview.md b/docs/en/concepts-and-designs/ui-overview.md
index 72bef4d..af898d8 100644
--- a/docs/en/concepts-and-designs/ui-overview.md
+++ b/docs/en/concepts-and-designs/ui-overview.md
@@ -1,10 +1,10 @@
 # Visualization
-SkyWalking native UI provides the default visualization solution.
+The SkyWalking native UI provides a default solution for visualization.
 It provides observability related graphs
-about overview, service, service instance, endpoint, trace and alarm, 
-including topology, dependency graph, heatmap, etc.
+on overview, service, service instance, endpoint, trace, and alarm, 
+such as topology maps, dependency graphs, heatmaps, etc.
 
-Also, we have already known, many of our users have integrated SkyWalking
-into their products. 
-If you want to do that too, please use [SkyWalking query protocol](../protocols/README.md#query-protocol).
- 
\ No newline at end of file
+We know that many of our users have integrated SkyWalking
+into their own products. 
+If you would like to do that too, please refer to the [SkyWalking query protocol](../protocols/README.md#query-protocol).
+