本人用c++实现了 微服务的 【注册中心】， 并对这个注册中心实现了高可用，我的服务网通过tcp通信，服务上线的时候 会注册到 【注册中心】上面，【注册中心】会推送这个服务器地址到 【服务消费者】。这样【服务消费者】就持有了所以的【微服务的map】我的负载均衡是在【服务消费者】这样做的，说白了【服务消费者】是要常驻内存的，这样对python或者java还好做点，但是对于走fpm的php相当于判了死刑，如何对php做改造，能让让传统的 fpm的php支持这种架构。 看起来dubbo 也是类似这样子做的，那么前端如果用php做的话 是不是就有点蛋疼了？
Magento是一套专业开源的PHP电子商务系统。Magento设计得非常灵活，具有模块化架构体系和丰富的功能。易于与第三方应用系统无缝集成。Magento开源网店系统的特点主要分以下几大类，网站管理促销和工具国际化支持SEO搜索引擎优化结账方式运输快递支付方式客户服务用户帐户目录管理目录浏览产品展示分析和报表Magento 1.6 主要包含以下新特性：•持久性购物 - 为不同的
回复内容：
负载均衡有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啊
