Dora-RPC 端午升级 PHP微服务开发…

Dora-RPC端午升级,目前master还在beta版本增加了大量的特性。

项目线上已经有几家公司平稳使用一年多了,当然他们是以此为原型进行了一定改造。最近升级改进了很多,如去掉unique函数导致性能翻倍,发现服务端有个别函数会被重复执行问题目前都已经修复,另外增加了异步任务拿回结果。目前groupclient也在改造,稍晚会将groupclient的功能集成到client内而不是两个客户端。

在之前一直没有深入做介绍,这里简单介绍一些目前有的特性:

此开源使用Swoole扩展进行的再次封装,用于PHP前后端分离,当我们项目变得庞大的时候我们需要隔离一些功能作为公共服务,我们希望通过这个方式将我们复杂的系统通过API服务变的简单易维护,更好评估复杂项目和跨项目组调用更加清晰。

框架思考:
  • 仅提供一套最基本的服务端和客户端,通过简单集成即可使用在任何开发框架上。
  • 返回数据结构分三层,每层都有msg和code,第一层(底层)代表当前客户端通讯情况,第二层代表当前api在服务端执行情况是否有异常或者投递情况,第三层代表代码执行情况若业务代码产生异常自动会纪录在这里。使用这个方式是因为RPC本身的复杂性,特提供这个方式来判断系统真正的状态。
  • 为了支持异步任务稍晚获取功能,将开发包底层都做了升级,主要原因是服务端处理完异步任务后会向客户端发送处理结果,如果当前客户端向服务端下发新任务并执行Recive的时候,之前客户端是无法判断出这次返回的内容是否为此次请求,与此同时由于长链接的特殊性,上一次的请求如果被异常中断没有执行recive的话,会导致上次的结果被本次请求拿到。为了防止以上问题特做了guid生成功能通过guid的判断完成了异步任务结果的收集和非本次请求的返回数据鉴别。
  • 由于我们的业务代码特殊性,我们不能保证我们的业务代码不会因为一些特殊原因产生故障,很多故障会导致进程终止,为此我们的业务代码都是在task上执行的,而不是worker上。通过这个方式我们可以做很多特殊的功能。不过task缺点是很多swoole异步特性不支持。
  • 服务分组,很多情况下我们是一个公共池子,既然同在一片天下我们就会收到影响。另外不同业务部署在不同的服务器上也很常见,为此我们提供了服务分组功能。规定某个服务器属于哪几个组,通过组能找到正确的服务器配置进行连接工作。
任务下发模式:
    下发任务数量可以分为:
  • 并发多个任务下发
  • 单个任务下发
    下发任务等待结果有多个模式:
  • 下发任务阻塞当前进程等待处理完毕并拿到返回数据
  • 下发异步任务不等待任务处理结果,只会返回下发成功,而任务在服务器跑完毕后没有任何返回
  • 下发异步任务不等待任务在服务器的处理,下发成功后马上返回下发成功,而服务完成后服务端返回处理结果给客户端,客户端通过一个函数统一将所有之前异步任务结果获取返回给当前业务进程。
通过以上方式我们可以成倍的增加我们接口响应速度和服务器利用能力。即使不使用复杂的多线程我们也可以达到我们的目标。 

网络通讯:
  • 客户端可以在PHP-FPM及CLI下工作,可维持长链接
  • 每次来回一次请求网络耗时在 0.002~0.004 左右(也取决于内网网络)
  • 请求处理完毕后链接仍旧保留不关闭 减少握手耗时及客户端队服务器的端口数消耗。
  • 若数据较大,支持包压缩gzip若有特殊需要可简单更改为其他压缩方式
  • 序列化使用的PHP自带的serialize若有需要可以直接自行更换
  • 连接和接收结果默认超时3秒,在const文件内设置,如果出现超时,客户端会自动使用其他配置进行尝试重试指定次数后返回json描述错误原因。如果有需要可以在重试逻辑内增加重试监控,监测各个服务器的工作状态。
  • 如果在本次请求中有一个ip已经失败过一次会自动在本次内进行屏蔽,如果发现所有配置已经都尝试或超过重试次数会返回失败。cli下失败一次后再次下发API时会取消掉之前所有屏蔽配置继续重试。
  • 之前RPC单线程客户端和虚拟机下的测试QPS大概在200~500次每秒通讯,但是每次下发的任务可以很多QPS可以在2k 单应用服务器
  • 当前的通讯架构并没有假如反向代理服务,因为客户端连接反向代理会消耗一定时间。另外反向代理服务器虽然性能高但是本身也是一个“单点”,对于分布式服务来说这种方式还是直连比较方便。

服务发现:
  • 当我们服务器需要增加减少的时候我们正常的流程是更新客户端的配置来实现新服务器的增加,但是这个方式还是很多缺点如果某台服务器出现故障,短期内我们无法发现,发现后还是需要人工修改配置或去运维配置中心区去摘除,通过服务发现我们可以自动的摘除,增加服务器,只要我们的控制逻辑做的很完善后期我们可以让这个过程完全自动。
  • 本框架提供了最简单的服务发现实现方式,使用redis作为存储,纪录所有服务端的ip和端口及所在分组。
  • 启动应用服务器并告诉他服务发现的redis列表后,服务器会自动将当前服务的ip和端口及分组上报到多个redis上进行注册,并定期刷新其超时时间。如果有个别节点在超过超时时间仍旧没有再上报那么自动摘除。
  • 客户端会定期从多个redis获取到最新的配置,并且更新本地配置文件内容。

后期支持:
下一步将会支持分布式日志,配置同步等

最后Dora-RPC是一个很开放的开源,本意是给Swoole社区用户作为参考做出优秀的RPC及微服务。
与此同时也希望各位踊跃参与此项目开发,任何有效的参与人都会纪录在wiki内。

项目地址:https://github.com/xcl3721/Dora-RPC 
最近活动:http://www.huodongxing.com/event/5337738177600 分享SOA实战经历,免费门票

  • 0
    点赞
  • 1
    收藏
    觉得还不错? 一键收藏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值