本人用c++实现了 微服务的 【注册中心】， 并对这个注册中心实现了高可用，我的服务网通过TCP通信，服务上线的时候 会注册到 【注册中心】上面，【注册中心】会推送这个服务器地址到 【服务消费者】。这样【服务消费者】就持有了所以的【微服务的map】我的负载均衡是在【服务消费者】这样做的，说白了【服务消费者】是要常驻内存的，这样对python或者java还好做点，但是对于走FPM的PHP相当于判了死刑，如何对PHP做改造，能让让传统的 FPM的PHP支持这种架构。 看起来Dubbo 也是类似这样子做的，那么前端如果用php做的话 是不是就有点蛋疼了？
回复内容：
负载均衡有2种做法：
客户端负载均衡，典型的是 Finagle 和 Dubbo。好处是实现出来简单，服务直接直连性能好。坏处是多语言的时候需要为每种语言实现一个客户端。
服务端的负载均衡，典型的负载均衡器是 Nginx 和 HAProxy 。通常是在服务前面加一个反向代理。客户端通过反向代理和服务端通信，具体的负载均衡逻辑由负载均衡器实现。负载均衡器本身也可以注册到注册中心。好处是客户端非常简单，多语言也好支持。坏处嘛就是有点性能损失。
具体怎么选要看业务，也要看公司的技术选型。多语言的场景下服务端的方案会省去很多维护成本，当然如果有一个 team 来维护客户端的话当我没说，毕竟 team 需要有事干么。
纯 Java 场景，已经用了 Dubbo 或者类似的框架，框架已经提供了支持就别折腾了。
回到题主的场景，如果非要在 php 服务里实现服务发现，可以把服务注册表缓存起来，比如放到 memcache 里，每隔一段时间可以重新拉一次。
以上
这个最简单（可能也是最靠谱）的方案是 agent，在 php 的服务器上跑一个 agent，监听你的注册中心，这个 agent 在收到新地址后修改 php 的配置文件，php 被 fpm 调用的时候都去读取一下这个配置。
一般来说，几乎所有的框架都有配置文件，直接去改这个文件就可以了，改造没有增加任何成本（因为你本来也是要读配置文件的）。
现在这种设计方式有一定的优势，即本身属于服务总线的一些能力已经完全下层到服务消费方节点上，这样总线本身功能更轻，只管理服务注册和注册信息的分发。注册中心down机基本对服务消费和调用没有任何影响。
鉴于你刚才提到的问题，有两种解决方法，一种是仍然将服务代理这块的能力提升回总线上来实现，包括路由和负载均衡等。如果不希望这样做，也可以考虑再单独起一个server，在该server上来实现服务消费和路由均衡逻辑。这个server可以看作是对应php应用的后端代理。
微服务中使用客户端负载均衡我觉得是大趋势，原因有三：一是性能有优势，二是可靠性更高注册中心down掉还是可以正常运行，三是客户端本身就需要实现断路器、服务降级之类的逻辑，多实现一个简单的负载均衡逻辑也算是顺路。PHP不太熟悉，是否可以考虑将服务配置写入到某个service_config.php文件，其他文件来包含这个service_config.php？包含之前检测一下文件的时间戳，如果超过某个时间（比如1分钟）就再重新从注册中心获取配置写入文件。
两个方案
1、Swoole
Swoole: PHP的异步、并行、高性能网络通信引擎
可以使用swoole写一个常驻内测的php server
2、缓存
使用APCu(PHP: APCu - Manual
)或者redis，把服务器地址列表缓存起来
看具体的性能要求和服务列表的一致性要求，一致性要求比较高，缓存可以短点，担心redis缓存读写的网络开销，可以使用APCu这种本地缓存
swoole啊
