(skywalking) branch master updated: Update the `Overview` docs to add the `Service Hierarchy Relationship` section. (#11699)

[wu...@apache.org]

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

wusheng 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 9ba0ad2991 Update the `Overview` docs to add the `Service Hierarchy Relationship` section. (#11699)
9ba0ad2991 is described below

commit 9ba0ad299139eeb4bb4e274c500cec1deaf84f79
Author: 吴晟 Wu Sheng <wu...@foxmail.com>
AuthorDate: Tue Dec 26 15:40:43 2023 +0800

    Update the `Overview` docs to add the `Service Hierarchy Relationship` section. (#11699)
---
 docs/en/changes/changes.md               |  1 +
 docs/en/concepts-and-designs/overview.md | 16 +++++++++-------
 2 files changed, 10 insertions(+), 7 deletions(-)

diff --git a/docs/en/changes/changes.md b/docs/en/changes/changes.md
index 1068a59a25..753777f212 100644
--- a/docs/en/changes/changes.md
+++ b/docs/en/changes/changes.md
@@ -26,5 +26,6 @@
 * Begin the process of `SWIP - SkyWalking Improvement Proposal`.
 * Add `SWIP-1 Create and detect Service Hierarchy Relationship`.
 * Add `SWIP-2 Collecting and Gathering Kubernetes Monitoring Data`.
+* Update the `Overview` docs to add the `Service Hierarchy Relationship` section.
 
 All issues and pull requests are [here](https://github.com/apache/skywalking/milestone/202?closed=1)
diff --git a/docs/en/concepts-and-designs/overview.md b/docs/en/concepts-and-designs/overview.md
index 6118bcccb9..0699a412db 100644
--- a/docs/en/concepts-and-designs/overview.md
+++ b/docs/en/concepts-and-designs/overview.md
@@ -30,6 +30,10 @@ Besides the support of various kinds of telemetry formats, the hierarchy structu
 **service**(s), **service instance**(s), **endpoint**(s), **process**(s). The terms Service,
 Instance and Endpoint are used everywhere today, so it is worth defining their specific meanings in the context of SkyWalking:
 
+- **Layer**. A **layer** represents an abstract framework in computer science, such as Operating System(OS_LINUX layer),
+  and Kubernetes(k8s layer). A layer is an abstract collection of services. A service typically only belongs to one layer,
+  but in some scenarios, a service could belong to multiple layers. For example, a service could be deployed in an Istio service mesh,
+  it could belong to mesh and mesh-dp(mesh data plane) layer.
 - **Service**. Represents a set/group of workloads which provide the same behaviours for incoming requests. You can define the service
   name when you are using instrument agents or SDKs. SkyWalking can also use the name you define in platforms such as Istio.
 - **Service Instance**. Each individual workload in the Service group is known as an instance. Like `pods` in Kubernetes, it 
@@ -38,14 +42,12 @@ Instance and Endpoint are used everywhere today, so it is worth defining their s
 - **Process**. An operating system process. In some scenarios, a Service Instance is
   not a process, such as a pod Kubernetes could contain multiple processes.
 
-SkyWalking allows users to understand the topology relationship between Services and Endpoints, to view the metrics of every 
-Service/Service Instance/Endpoint and to set alarm rules.
-
-Starting from v9, SkyWalking introduces the new core concept **Layer**.
-A **layer** represents an abstract framework in computer science, such as Operating System(OS_LINUX layer),
-Kubernetes(k8s layer). All detected instances belong to a layer to represent the running environment of this instance, 
-the service would have one or multiple layer definitions according to its instances.
+SkyWalking allows users to understand the topology relationship between Services and Endpoints, also detect API dependencies
+in the distributed environment if you use our native agents.,
 
+Besides topology map, SkyWalking provides Service Hierarchy Relationship, which defines the relationships of existing 
+logically same services in various layers. For example, a service could be deployed in a Kubernetes cluster with Istio mesh, 
+services are detected by k8s monitoring and Istio mesh, this hierarchy relationship could connect the services in k8s layer and mesh layer.
 
 ## Architecture
 SkyWalking is logically split into four parts: Probes, Platform backend, Storage and UI.