当前位置:Gxlcms > PHP教程 > 分布式服务治理的设计问题?

分布式服务治理的设计问题?

时间:2021-07-01 10:21:17 帮助过:20人阅读

本人用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啊

人气教程排行