I use C + + to implement the "Registration center" of micro-services, and the registration center to achieve a high availability, my service network through the TCP communication, the service will be registered to the "Registration center", the "registration center" will push this server address to "service consumers." So the "service consumer" is holding the "micro-service Map" My load balancing is in the "service consumer" to do, the "service consumer" is to reside in memory, so that Python or Java is good to do, but for the walk fpm PHP equivalent to the death penalty, How to transform PHP allows traditional fpm PHP to support this architecture. Looks like Dubbo is also similar to do, then the front end if you do with PHP, is it a bit of egg ache?
Reply content:
There are 2 ways to load balance:
Client load balancing, typically Finagle and Dubbo. The advantage is that it is simple to implement and the service directly connected to the performance is good. The downside is that multiple languages need to implement a client for each language.
Server-side load balancing, typical load balancers are Nginx and HAProxy. Typically, a reverse proxy is added to the front of the service. The client communicates through the reverse proxy and the server side, and the 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, multi-lingual support. The downside is a bit of performance loss.
Specific how to choose to see the business, but also to see the company's technology selection. Multi-lingual scenarios will save a lot of maintenance costs, of course, if there is a team to maintain the client, when I did not say, after all, the team need to do something.
Pure Java scenarios, already using Dubbo or similar frameworks, the framework has provided support to do not toss.
Back to the main scene, if you do not want to implement service discovery in PHP service, you can cache the service registry, such as in Memcache, can be pulled back every time.
This is the simplest (and probably the most reliable) solution is the agent, on the PHP server to run an agent, monitoring your registry, the agent after receiving the new address to modify the PHP configuration file, PHP is called by FPM to read this configuration.
In general, almost all of the framework has a configuration file, directly to the file can be changed, the transformation does not add any cost (because you have to read the configuration file). Now this design approach has a certain advantage, that itself belongs to the service bus, some of the ability is completely down to the service consumer node, so that the bus itself is more light, only to manage the distribution of service registration and registration information. The registration center down machine basically has no effect on service consumption and invocation.
In view of the problem you have just mentioned, there are two workarounds, one that still improves the ability of the Service Broker to be implemented on the bus, including routing and load Balancing. If you do not want to do this, you can also consider a separate server to implement service consumption and routing equalization logic on the server. This server can be seen as a back-end proxy for PHP applications. Using client load Balancing in MicroServices I think it is a big trend, for three reasons: one is the performance advantages, the second is the reliability of higher registration center down or can run normally, the third is the client itself needs to implement circuit breakers, service degradation and other logic, more to achieve a simple load balancing logic is also on the way. PHP is not familiar with, can you consider writing service configuration to a service_config.php file, other files to include this service_config.php? Contains the timestamp of the previous detection of the file, and if it is more than a certain time (for example, 1 minutes) then re-fetch the configuration from the registry to write the file. Two Solutions
1, Swoole
swoole:php asynchronous, parallel, high-performance network communication engine
You can use Swoole to write a resident beta PHP server
2. Cache
Use APCU (php:apcu-manual
) or Redis, cache the server address list.
See specific performance requirements and service list consistency requirements, consistency requirements are high, cache can be short, worry about Redis cache read and write network overhead, you can use APCU this local cache swoole AH
