Monolithic architecture

Microservices architecture

Registration and discovery and load balancing of service governance

Throttling circuit breaker for service governance

Service monitoring for service governance

Today to share a topic with you, is about the service governance of the microservice architecture, many small partners may feel that they have played with the microservice architecture, and then may have heard of service governance, but what is the service governance, what are the things, how should the service governance be done, this may be confused.

So today I will talk to you about the service governance under this microservice architecture.

Monolithic architecture

First of all, when it comes to microservice architecture, let’s talk about how everyone usually plays with microservice architecture.

In fact, it is very simple, when there is no microservice before, it may be directly SpringBoot+SSM This set of architecture will directly write a single block of new system OK, use SpringBoot to hit a jar package, and then after the jar package is deployed to the online system, directly use the java -jar command to start the JVM process to run our code.

When using SpringBoot, the Web server that generally receives Http requests externally is embedded Tomcat, that is, after SpringBoot is started based on the main method, the embedded starts a Tomcat, Tomcat will listen to a port number externally, and then we can initiate an Http request for that port number.

Microservices architecture

So at this time, our system is essentially a monolithic system, so what should it be like if you upgrade to a microservices architecture?

In the case of microservices, it means that the original single-block system is split into many services, and the services and services are called through the service registry and RPC framework such as Nacos+Dubbo.

Five years ago, the basic microservices framework commonly used in the industry was the combination of Dubbo + Zookeeper, but 3 years ago basically transitioned to the SpringCloud technology stack as a microservices architecture.

A year or two ago, the industry basically slowly transitioned to the SpringCloud Alibaba technology stack, that is, using Nacos as the service registry and Dubbo as the RPC framework, so we will take SpringCloud Alibasil’s Nacos+Dubbo combination as an example.

In the case of microservices, that is, to let each service register with Nacos, and then the service wants to call other services, it will be discovered through Nacos, and then RPC called through Dubbo.

Just like this diagram, in fact, many services call each other, which can be roughly understood as a microservice architecture, because our single-block system has been split into many services. So then, how do we govern the services of this microservices architecture?

Registration and discovery and load balancing of service governance

The first thing to say to you is that the first thing about service governance is actually service registration and discovery, so it is already the first thing that service governance can do through Nacos.

Okay, so what’s the second thing about service governance? In fact, it is load balancing, what does this load balancing mean? In fact, we can deploy multiple machines per service, and there are multiple service instances.

So if a service can find multiple machines with another service instance, which one should be called?

At this time, you have to use a load balancing algorithm, use the algorithm to find a machine, and then you can make an RPC call against that machine. This load balancing job is what Dubbo did for us.

Throttling circuit breaker for service governance

Then, the third thing in this service governance is the flow restriction fuse, which is divided into two pieces, because the flow restriction is used to prevent the system from being crushed, and the circuit breaker is used to prevent the system from being dragged down.

Let’s talk about throttling, suppose your system is normal and can only resist up to 1,000 requests per second, and the result is 2,000 requests per second.

Of course, it will overwhelm your system, so at this time we must do a throttling, if more than 1000 requests per second, all subsequent requests are directly returned to disable access.

Then we talk about a fuse, which means that if you call a system, and that system hangs up, and then every time you call it, it is a failure, and each time you fail, you have to block for a while, won’t that drag you down?

Therefore, at this time, it must be fused, if once it is found that if it is frequently called to others to fail in a period of time, the circuit breaker will be triggered at this time, and after the circuit breaker, it will be directly reported as an error every time it is requested.

So who does this flow restriction and fuse do for you? Sentinel in SpringCloud Alibaba can do this for you, so the throttling fuse is his job.

The next task of service governance is the configuration center, that is, the configuration of our system is usually placed in the src/main/rsource directory of various properties and xml files.

But if you want to deploy the system online, you have to modify the configuration, you can only modify the configuration in the code, and then repackage the deployment to go online, which is too troublesome, right?

So if you introduce a configuration center, some of the core configuration of the system is dynamically loaded directly from the configuration center, and then if you want to modify the configuration directly in the configuration center.

Then the online system directly perceives the latest configuration and application, then there is no need to package and redeploy every time the configuration is modified, and the work of this configuration center is Nacos for us.

Service monitoring for service governance

Then the last link of service governance is service monitoring, which includes a lot of content, such as monitoring the CPU, memory, disk, network, IO of each server deployed by the online system, and monitoring the JVM GC of the online system, including monitoring the QPS and latency of each interface of the online system.

At the same time, it is also possible to monitor the call link between the various services of the online microservice system, which is usually done with the two monitoring systems of Prometheus and Skywalking.

Skywalking typically tracks our microservice invocation links, and Prometheus monitors the servers, JVMs, and interfaces of our online systems.

Well, the content of microservice governance introduced to you today ends here. If there’s something to be gained, give it a thumbs up!