Apache skywalking Architecture Design "translation"

Apache Skywalking provides a powerful and lightweight back end. Here, you'll learn why you can design it in the following ways, and how it works.

　　

Architecture diagram

For APM, the agent or SDKs only uses the technical details of Libs. The form of manual or automatic is not schema-independent, so in this article, we don't talk about these things, and we can consider these as client lib.

Basic principle

　　The basic principles about skywalking architecture design are:

1) easy to maintain;

2) controllable;

3) flow-based;

　　To achieve this, the Skywalking backend provides the following design:

1) Modular design;

2) to provide clients with a variety of connection methods;

3) cluster discovery mechanism;

4) flow mode;

5) switchable storage implementation;

First, Modular

The skywalking Collector (collector) is based on a modular design that allows users to change or integrate the functions of the collector according to their needs.

Second, the module

A module defines a set of features that can include technical implementations such as Grpc/jetty Server Management, trace analysis (for example, trace segment or Zipkin span parser), or aggregation features. In summary, these are defined and implemented by the module.

Each module can define its own services through the Java interface, and implementation classes implement these services. And these implementation classes have to define which classes are dependent on the functionality that is implemented. This means that even the two different implementations of a module can depend on different modules.

In addition, the modular core in the collector checks the boot sequence, and if no circular dependencies or dependencies are found, the core feature terminates the collector.

The collector launches all the modules, which are defined in the Application.yml file. This file structure is as follows:

1) The root node is the module name, such as: cluster,naming;

2) The secondary node is the function implementation name of this module, such as: Zookeeper is the cluster module;

3) The third-level node is the property of the function implementation, such as: Hostport and Sessiontimeout are zookeeper required properties;

Three, multi-connection mode

First, the collector provides two types of connections, namely the support for both protocols: HTTP and Grpc.

1) Name the service in HTTP, and in the back-end cluster, return all available collectors;

2) The Uplink service supports GRPC (primarily for skywalking local agents) and HTTP, which tracks and measures the collector. Each client sends monitoring data (traces and metrics) only to a single collector. If the connected collector is disconnected, try connecting to the other collector.

Example of processing flow between client lib and collector cluster

　　

Iv. Collector Cluster Discovery

Collectors must somehow discover each other when the collector is running in cluster mode. By default, Skywalking uses zookeeper to reconcile and use this as the Registry for discovery.

Thus, the client's lib will not use zookeeper to find the cluster. Users are advised not to do so. Because the cluster discovery mechanism is switchable, it is provided by the modular core. Based on this, the ability to switch is broken.

We want the community to be able to provide more functional implementations of cluster discovery. As now some eureka,consul,kubernate.

　　Five, Flow mode

Flow patterns tend to be lightweight storm/spark implementations and allow the use of APIs to build flow process diagrams (Dags), as well as input/output data conventions for each node.

The new module can find and extend the existing process diagram.

There are three types of cases in the process:

1) synchronization process. Traditional method invocation.

2) asynchronous process, based on the queue buffer of the a.k.a batch processing process.

3) remote process, aggregate matrix collector, in this way, the selector is defined in the node to determine how the collector is found in the cluster. (Hashcode,rolling,foreverfirst is three ways to support it)

With these features, the collector runs like a mobile network. Supports simultaneous writing of the same ID by aggregating metrics and not relying on the storage implementation feature.

　　Six, switchable storage implementation

Because flow mode is responsible for concurrency, the responsibility of the storage implementation is to provide high sketching and group queries.

Support for Elasticsearch is now supported, as well as H2 preview, while supporting the Shardingsphere project for managing MySQL relational database clusters.

　　Vii. Web UI

In addition to the principle of collector design, the UI is another core part of Skywalking. It provides collector cluster discovery, query dispatch, and visualization based on react, ANTD, and Zuul proxies.

The Web UI uses localhost:10800 to make a named query for the collector cluster.

Reference Link: https://zhuanlan.zhihu.com/p/38442093?utm_source=wechat_session&utm_medium=social&utm_oi= 54098577588224&from=timeline&isappinstalled=0

Apache skywalking Architecture Design "translation"