最近把 MixPHP 逐渐重构到了 V3 版本,之前停更了很长时间,是因为始终在开发 MixGo,回想起 V2~V2.2 版本中我做了很多尝试,其中特地是 V2.2 我十分激进的间接 all in 单线程协程,过后我是这样想的:MixPHP V2.1 为何从 Reactor+Manager+Worker 多过程改为单线程协程,然而切换后实际上带来了一些问题:
- 很多用户用了一些奇奇怪怪的第 3 方库,都是依赖 guzzle 和 curl 的,不论是 swoole hook curl 还是 mix/guzzle hook,总是偶然呈现申请失败,不稳固的状况,最初无奈只能用同步执行器解决。
- 解决简单一些的 cli 后盾计算的时候,通道死锁问题比较严重,问题应该是 db pool 抛出的连贯被用户始终持有,导致死锁,这个是我 db 封装的设计没有思考好这种状况。
当然下面也都不是解决不了的问题,前面大家也都解决了,只是带来了一些本不必要的麻烦,总体感触是其实多过程还是有多过程的意义,少了很多不必要的懊恼,很多人示意思念以前的 v1.1 的多进程同步模式,比方:敞开协程用同步模式的话,就兼容 composer 的全副生态,以上懊恼都没有,性能其实也不差。
太过理想化
在最后开始设计 V2.2 时,其实我太理想主义了,我心田真的是想复制一个 php 版 golang 的,我本人开发了 mix/runtime 外面蕴含 Select 用来解决多通道,格调齐全与 Go 相似的 Context,Signal、Time 等根底库,然而理论应用时,因为 Swoole 和 Golang 的协程切换机制不同,导致死锁的问题非常容易呈现,最初无奈放弃了,当然我是做非常复杂的那种后盾计算类的需要,如果只是 http 开发 CURD 根本不会遇到。Swoole 还是在 API、WebSocket 等畛域比拟适合。
微服务
在 V2.2 前期,我做了很多微服务的尝试,我开发了一个十分好用的 PHP gPRC 服务器开发库,我还把整个框架都接入到了 go-micro v1,v2 的生态中,简直能应用 micro 全副的工具链,难堪的是起初他们示意 v3 版本将全面 all in 云微服务。
再到前面我接触 APISIX 等网关产品后,我感觉其实咱们程序员就间接写 gRPC 和 http 这些接口就能够了,服务少的时候用 ALI 的内网 SLB 简略手动的注册一下负载平衡,多的时候就间接启动一个 APISIX 这种网关,而后把 host 切换到网关地址就能够了,其余的服务发现、熔断、链路啥的都不必去硬编码到框架里了,反而简略高效,当然发现其实还是要去调用网关接口的,然而相比之前我全副用代码 +etcd 去解决要单纯很多。
齐全独立的模块
以前我开发框架是先构建整体,而后依据框架的须要拆分模块,这导致了模块太多了,有些代码老是感觉放哪里都不太对十分的纠结,各个库之间总是有千头万绪的分割,独立应用的时候老是连带下载一堆的库。
V3 开始我采纳了齐全 golang 的那种可插拔的封装思维,我先开发很多个独立的库,这些库的代码尽量的内聚,而后我编写一个骨架,将这些库组合起来应用,我逐渐的重构了这些最重要的库。
- mix/vega PHP 编写的 CLI 模式 HTTP 网络框架,反对 Swoole、WorkerMan,与 Go 生态的 gin 定位统一
- mix/database 可在各种环境中应用的轻量数据库,反对 FPM、CLI、Swoole、WorkerMan,可选的连接池 (协程)
- mix/redis 可在各种环境中应用的 PHP Redis,反对 FPM、CLI、Swoole、WorkerMan,可选的连接池 (协程)
- mix/redis-subscribe 基于 Swoole 协程的 Redis 原生协定订阅库
- mix/grpc 基于 Swoole 协程的 PHP gRPC 库,蕴含 protoc 代码生成器、服务器、客户端
- mix/websocket 基于 Swoole 协程的 PHP WebSocket 服务器与客户端
- mix/validate 基于 PSR-7 的验证库
- mix/worker-pool 基于 Swoole 的协程池、工作池库
- mix/event 基于 PSR-14 规范的事件调度库
- mix/cli PHP 命令行交互指挥官
重构中
每个库都是独立可执行的,你能够只应用 mix/vega 来搭配 laravel orm 应用;能够在任意环境中应用 mix/database 和 mix/redis;能够应用 mix/grpc 原生代码编写 gRPC;所有的模块你能够像搭积木一样随便组合。
更多的应用场景,裸露原生接口
在 V1,V2 的时候,咱们总是只能在一种固定的过程模式下应用,因为咱们这些框架把 swoole 底层封装起来了,因为封装导致原生接口其实是无奈裸露进去的,因而都是通过配置的形式来做一些无限的模式切换。
V3 我做的比拟彻底,我通过封装的 mix/vega 只在申请事件那里引入框架,齐全把原生代码裸露进去,带来了非常灵活的启动形式,能够同时反对:Swoole 多进程同步,多过程协程,单过程协程,WorkerMan 多进程同步。蕴含了 CLI 下两大生态的全副执行模式,并且代码完全一致,能够随便切换,这带来了微小的可选择性,对协程兼容性困扰的用户能够抉择同步模式,在 windows 下无奈开发的用户能够抉择 workerman 驱动,甚至如果须要 Swow、FPM 我都能够接入进来。
数据库组件
这次数据库解决了之前的持有连贯导致死锁的问题,同时优化了池的实现,同时废除了之前简单的 where 设计,采纳的更加简略的 ? 绑定形式,这种形式在 golang 中一般采纳。这些扭转带来了稳定性和性能的晋升,同时更加雅观了,当然还减少了 FPM 的反对,我看到有些用户喜爱独自应用他们。
数据库不论在协程、同步、FPM 执行,代码无需批改,只有在协程时独自调用一下 startPool()
即可。
独立、灵便、性能好
以上,MixPHP V3 带来了很多显著的变动,但仍然是一个轻量的高性能框架,当初你能够像应用 symfony
一样独立应用咱们的模块了。