How to Dubbo service governance, service degradation, failed retry, and timeout retry?
Service governance
- The invocation link automatically generates a large distributed system, or to use the popular microservices architecture, a distributed system consists of a large number of services. So how do these services call each other? What is the call link? To be honest, it’s almost impossible to keep track of what’s going on in the back because there are so many services, hundreds or even thousands of them. In the distributed system based on Dubbo, the calls between various services are automatically recorded, and then the dependencies and call links between various services are automatically generated, made into a map and displayed, so that we can see them, right?
- Service access pressure and Duration Statistics The number of calls between interfaces and services and the access delay are automatically counted. The statistics are divided into two levels. The first level is interface granularity, that is, how many times each interface of each service is invoked every day, TP50/TP90/TP99, and the request latency of the three levels respectively. The second level starts from the source. After a complete request link passes through dozens of services, it completes a request. How many times does the whole link go every day? After all these things are done, we can see where the main pressure of the current system is, how to expand and optimize ah.
- Other service layering (avoiding cyclic dependencies) invokes link failure monitoring and alerting services to authenticate each service’s availability monitoring (interface call success rate? Several 9? 99.99%, 99.9%, 99%)
Service degradation For example, service A calls service B, and service B hangs y