Vocabulary

Vocabulary #

The main terms used in service grid products are listed below.


About Registration #

Static Registration #

The static registry declares the topology, channel and other logical relationship information between services. It is generally used for deployment (determining the deployment structure), calling permission query (viewing whether there is a calling relationship between services), etc.

Dynamic Registration #

When the service is deployed and running normally, it can be seen in the Dynamic Registry. Its information is generally dynamic information, that is, the information available only when the service is alive, such as service address information, hostname information, etc.

Resource Events #

Resource alert focuses on CPU and memory consumption. When the consumption exceeds the monitoring threshold, a resource alert event is triggered. At present, the types of resource alerts include:

  • Service resources (CPU usage greater than 80%, memory usage greater than 80%)
  • Sidecar warning system (CPU usage greater than 80%, memory usage greater than 80%)

Service Resource Protect #

The early warning caused by the shortage of service container resources is called service resource protect.

Sidecar Resource Protect #

The early warning caused by the shortage of sidecar container resources is called sidecar resource protect.

Registration Engines #

That is, the workload collection that provides services and registration. In order to ensure the high availability of services, the registration engine is generally composed of multiple engine nodes.


About Governance #

Health Check #

Each service provides a service inspection interface according to the health inspection standard, and MSP regularly checks the health status of the service.

Circuit Breaker #

That is, limit the call of unstable resources, make the request fail quickly, and avoid cascading errors caused by affecting other resources.

Rate Limiting #

That is, monitor the QPS and other indicators of application traffic, control the traffic that reaches the threshold, and avoid the application from being overwhelmed by the instantaneous traffic peak, so as to ensure the high availability of the application.


About Logs #

Log Key #

When sending logs, you need a log key to send them. If there is no log key or the log key is wrong, the log will be intercepted when it is sent, and the log interception event will be triggered.

Block Key #

When the log key is wrong or not turned on, an attempt to send a log will trigger an interception event.

Rate Limiting #

You can set the upper rate limit for the specified log key. Logs exceeding the rate will be discarded and the key current limiting event will be triggered.

Length Threshold #

In order to ensure the stability of the system, the current log is sent to the log data storage device through the queue flow. When the sending rate is too fast, the queue may have a backlog. When the queue backlog exceeds the set “length” threshold, the length threshold event will be triggered.

About Pub/sub #

pubsubname #

Pubsubname is the engine name used when using asynchronous messages. It is the unique identification of the engine. The engine concept here is the middleware carrier carrying information in the asynchronous message system. In design, services are allowed to use multiple engines, and the use of different engines is identified by pubsubname. A default redis cluster engine is created in MSP, which can be directly used by ordinary services in the middle office.

Topic #

Topic if you have used message queue, you will be familiar with this concept. Topic or topic is a queue of messages. Asynchronous messages are classified by topic. Data between different topics are isolated from each other. A topic will have a message publishing service and a message subscribing service, both of which can be multiple. That is, services a and B… Can publish messages on topicxxx, and services D and E… Can subscribe to messages on topicxxx. Of course, the premise is that this rule is configured on MSP.

metadata #

Metadata is not aware of this concept for go services and PHP services, and has been encapsulated inside the SDK. If other services need to use asynchronous message function, and TTL function is used, TTL information needs to be attached in metadata.

route #

Route this definition appears in the subscription topic configuration later. When there is a message in the current topic, sidecar will call back the service interface to push the subscribed message to the service. The value is the interface route path without the “/” prefix.