kazusa
/
skywalking-java
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

docs: fix broken istio-architecture svg (#5664) 

* docs: fix broken istio-architecture svg

* server -> service
This commit is contained in:
Rei Shimizu 2020-10-15 01:19:35 +09:00 committed by GitHub
parent b24e3f3737
commit f48e4961ec
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
1 changed files with 9 additions and 9 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

18
docs/en/concepts-and-designs/service-mesh-probe.md
View File

@ -1,20 +1,20 @@
# Server Mesh Probe
# Service Mesh Probe
Service Mesh probes use the extendable mechanism provided in 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.
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
> The term service mesh is often used to describe the network 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 wide used. Here is Istio Architecture:
![Istio Architecture](https://istio.io/docs/ops/architecture/arch.svg)
![Istio Architecture](https://istio.io/latest/docs/ops/deployment/architecture/arch.svg)
Service Mesh probe can choose to collect data from **Control Panel** or **Data Panel**. In Istio,
Service Mesh probe can choose to collect data from **Control Panel** or **Data Panel**. In Istio,
it means collecting telemetry data from Mixer(Control Panel) or Envoy sidecar(Data Panel). Underlying
they are same data, the probe collects two telemetry entities from client side and server side per request.
@ -22,10 +22,10 @@ they are same data, the probe collects two telemetry entities from client side a
From the probe, you can see there must have no trace related in this kind of probe, so why SkyWalking
platform still works?
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
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:
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.**
## What is Next?