Design issues for distributed service governance?

I used C++ to implement the [Registration Center] of the microservice, and implemented high availability for this registration center. My service network communicates through TCP. When the service goes online, it will be registered on the [Registration Center], and the [Registration Center] will push This server address goes to [Service Consumer]. In this way, the [Service Consumer] holds all the [Microservice Maps]. My load balancing is done in the [Service Consumer]. To put it bluntly, the [Service Consumer] needs to be resident in memory, so it is very important for Python. Or Java is easier to do, but for PHP using FPM, it is equivalent to a death sentence. How to transform PHP so that traditional FPM PHP can support this architecture. It seems that Dubbo is done in a similar way, so if the front-end is done in PHP, wouldn’t it be a bit of a pain in the ass?

Reply content:

There are two methods of load balancing:

Client load balancing, typically Finagle and Dubbo. The advantage is that it is simple to implement, and the service is directly connected and has good performance. The disadvantage is that when using multiple languages, you need to implement a client for each language.

Server-side load balancing, typical load balancers are Nginx and HAProxy. Usually a reverse proxy is added in front of the service. The client communicates with the server through a reverse proxy, and the specific load balancing logic is implemented by the load balancer. The load balancer itself can also be registered with the registry. The advantage is that the client is very simple and supports multiple languages. The disadvantage is that there is a bit of performance loss.

The specific choice depends on the business and the company’s technology selection. In a multi-language scenario, the server-side solution will save a lot of maintenance costs. Of course, if there is a team to maintain the client, I will not mention it. After all, what does the team need to do?

For pure Java scenarios, you have already used Dubbo or a similar framework. If the framework already provides support, don’t bother.

Back to the main scenario, if you have to implement service discovery in the PHP service, you can cache the service registry, such as putting it in memcache, and pull it again every once in a while.

Above The simplest (and probably the most reliable) solution is agent. Run an agent on the PHP server to monitor your registration center. This agent will modify the PHP configuration file after receiving the new address. When PHP is called by FPM Go read this configuration.

Generally speaking, almost all frameworks have configuration files. You can just modify this file directly. The modification does not increase any cost (because you also have to read the configuration file). This design method now has certain advantages, that is, some capabilities that belong to the service bus have been completely down-layered to the service consumer node. In this way, the bus itself has lighter functions and only manages service registration and distribution of registration information. The downtime of the registration center basically has no impact on service consumption and invocation.

In view of the problem you just mentioned, there are two solutions. One is to still improve the capabilities of the service agent back to the bus, including routing and load balancing. If you don't want to do this, you can also consider setting up a separate server to implement service consumption and routing balancing logic on this server. This server can be regarded as the back-end proxy corresponding to the PHP application. I think the use of client load balancing in microservices is a major trend. There are three reasons: first, it has performance advantages; second, it has higher reliability. Even if the registration center is down, it can still run normally; third, the client itself needs to implement circuit breakers and services. For logic such as downgrading, it would be a good idea to implement a simple load balancing logic. I am not very familiar with PHP. Is it possible to consider writing the service configuration into a certain service_config.php file and include this service_config.php in other files? Contains the timestamp of the previously detected file. If it exceeds a certain time (such as 1 minute), the configuration write file will be obtained from the registration center again. Two solutions

1. Swoole
Swoole: PHP’s asynchronous, parallel, high-performance network communication engine
You can use swoole to write a permanent internal test php server

2. Cache
use APCu (PHP: APCu - Manual) or redis, cache the server address list
It depends on the specific performance requirements and the consistency requirements of the service list. The consistency requirements are relatively high, and the cache can be shorter. If you are worried about the network overhead of redis cache reading and writing, you can use APCu This local cache swoole