Shulou(Shulou.com)05/31 Report--

This article mainly explains "what are the knowledge points related to Service Mesh". Interested friends may wish to have a look. The method introduced in this paper is simple, fast and practical. Next, let the editor take you to learn "what are the knowledge points related to Service Mesh"?

What is ServiceMesh?

Service Mesh is a non-intrusive and transparent micro-service governance framework. As a transparent management framework for direct communication between services, Service Mesh does not restrict service development language, uses lightweight communication protocols (HTTP, gRPC, etc.), and plug-ins provide all kinds of functions, such as service discovery, load balancing, intelligent routing, traffic control, performance analysis and so on. In other words, users can get advanced functions in a simple way through Service Mesh.

Rainbond natively supports Service Mesh. Next, we will interpret it from the aspects of service discovery and registration, auto scaling and load balancing, fault tolerance (circuit breaker and current limit), monitoring and alarm, data storage and sharing, log analysis, and so on.

Service discovery and registration

Service registration is an essential part of any SOA/ service / micro-service framework, which is closely related to some highly consistent distributed storage: Zookeeper, Etcd, Consul, in which Consul and Etcd are implemented based on Raft protocol, and Zookeeper is implemented based on PAXOS protocol.

Almost all service registrations and discoveries need to be based on the above strongly consistent distributed storage implementation, such as Spring_Cloud_Consul/Spring_Cloud_Zookeeper, two important subprojects of SpringCloud.

For Rainbond, automatic registration of all deployed applications / services is realized through unified application / service management. The principle lies in that Rainbond implements application scheduling based on Kubernetes, and the application / service information registered in the Kubernetes cluster is actually registered in Etcd. Each time the application instance is restarted, Rianbond will assign a different IP address to it, and the service registration information will be changed dynamically.

We know that applications must first discover each other before communicating directly with applications. In this regard, Rainbond adopts a declarative discovery mechanism, that is, when A service needs to communicate with B service, then it first needs to declare that it depends on B service in A service, and the Rainbond application runtime module will discover the other party's service address based on the user declaration. Inject it into the A service and give the A service a local access address (127.0.0.1) to access the B service.

Dependencies between platform services

Elastic scaling and load balancing

When it comes to service discovery and registration, auto scaling and load balancing have to be talked about.

A service above connects to B service, which can be a stateful database service, such as Mysql, MongoDB, etc., or a stateless restfulAPI service.

For applications that can scale horizontally (stateless applications or distributed stateful applications), service discovery injects multiple endpoint addresses, which inevitably requires load balancing, so the A service needs to support layer 4 network agents or layer 7 network proxies. Injected into the agent plug-in through the back-end address discovered by the application runtime module.

The default proxy plug-in of Rainbond supports layer-4 load balancer. With the easy expansion of Service Mesh, we can match different network governance plug-ins for various application layer protocols to achieve layer-7 load balancer, such as HTTP, gRPC, Redis and other protocols.

Why do you need advanced features such as layer 7 load balancing? The reason is that for some online environments, we want to be able to achieve hot changes or better fault tolerance for inter-service calls, such as Abig B testing, grayscale publishing, etc., which must be done on layer 7 load balancing.

Rainbond currently provides "layer 7 network governance plug-ins based on envoy" (envoy itself can run in the Rainbond plug-in system with Anson), users can also select and implement other plug-ins, and the Rainbond runtime will provide complete basic services.

How to configure 7-tier advanced load balancing

Fault tolerant treatment (circuit breaker and current limiting)

A micro-service architecture that can tolerate some of these service anomalies can be called a robust production-level micro-service architecture.

For example, on a shopping website, the order page will recommend other related products. In the case of abnormal traffic, in order to ensure the availability of the order function, the recommendation function (time-consuming computing and poor performance) is limited, and elegant service degradation is required. While using limited resources for key services, ensure the stability of the entire system.

There are two schemes: current-limiting, setting the maximum number of requests or connections for a service to rigidly protect downstream services; and circuit breakers, when the error rate of downstream services reaches a threshold, return the rapid failure of upstream requests to protect the stability of upstream services without increasing pressure on downstream services to achieve rapid failure and rapid return.

The implementation of the above functions is relatively complex for business systems. With the support of Rainbond advanced load balancer mentioned above, circuit breakers and current limiting mechanism can be used out of the box by configuring simple current limiting parameters or circuit breaker parameters for each calling line.

Monitoring and alarm

Traditional operation and maintenance staff focus on monitoring physical resources, such as memory, CPU, load and other indicators. In terms of monitoring and alarm, Rainbond does not focus on these aspects to reflect the health status. In addition to the basic resource monitoring, the Rainbond core chooses the throughput and response time that can directly reflect the operation of the service as the key indicators. For example, the abnormal decrease in throughput and the increase in response time prove that the current service pressure is too high, which means that it is necessary to expand.

The business-level monitoring analysis of Rainbond is shown below:

For different service protocols, Rainbond uses different indicators to show real-time throughput and response time, such as HTTP protocol, using Path request volume and corresponding time expression, Mysql protocol using SQL execution volume and response time expression.

In the future, Rainbond will support more application protocols besides the above two protocols, including gRPC, Redis, postgreSQL and so on. Users can automatically or manually configure rules or automatic learning rules on these indicators to provide business alarm and automatic scaling.

Data storage and sharing

Distribution is an indispensable part of micro-service architecture, which is not easy to implement and deal with when running many different types of applications, requiring different storage, and different data centers and different infrastructures provide different storage types.

Rainbond is implemented by decoupling storage from applications. Plug-ins support different storage types, such as NFS-based distributed file storage, block device storage, memory virtual storage, etc.

Of course, different storage has different properties. Shared file storage is most commonly used in Rainbond distributed stateless applications. The storage area allocated for each application will be mounted to all instances to synchronize data in real time. Users can customize the path that needs to be mounted, and the data will follow wherever it is applied.

Log analysis

Log processing generated by services in micro-service architecture is also a difficulty. Logs need to be collected uniformly, and logs generated by multiple instances of the same application need to be aggregated, and then need to be analyzed and alerted.

The logs of the service are generally divided into two parts: system logs and access logs. Rainbond recommends that you deal with the two types of logs differently.

For Syslog, its main function is to debug the system and record exceptions. Rainbond provides application log aggregation and real-time display based on application level, so you only need to output Syslog to standard output (stdout), and the system will automatically collect and aggregate to store the applied dimension.

For the access log, we generally need to analyze and monitor it. The common solution for log analysis is the ELK system. The recommended way for Rainbond is to output the access log to the specified file and install the Elasticsearch plug-in to send the collected file log to the specified Elasticsearch server (the platform deploys ELK full service with one click). If you use other analysis systems, you can also send the application log to the designated server in the form of a plug-in.

At this point, I believe you have a deeper understanding of "what are the relevant knowledge points of Service Mesh?" you might as well come to the actual operation! Here is the website, more related content can enter the relevant channels to inquire, follow us, continue to learn!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.