V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
onanying
V2EX  ›  PHP

MixPHP V3 发布前的感想, 有哪些变化和特点

  •  
  •   onanying · 2021-07-26 14:09:39 +08:00 · 1745 次点击
    这是一个创建于 976 天前的主题,其中的信息可能已经有所发展或是发生改变。

    最近把 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 一样独立使用我们的模块了。

    5 条回复    2021-08-01 11:42:36 +08:00
    qwertyzzz
        1
    qwertyzzz  
       2021-07-26 16:33:41 +08:00
    顶 大佬 有空来用用
    zl939144892
        2
    zl939144892  
       2021-07-27 09:55:05 +08:00
    前两年项目用的 mix 怀念
    onanying
        3
    onanying  
    OP
       2021-07-27 17:41:51 +08:00
    @zl939144892 转 go, java 了?
    zl939144892
        4
    zl939144892  
       2021-07-28 10:24:32 +08:00
    @onanying 换公司了 现在 PHP 用的 Yii
    yqf0215
        5
    yqf0215  
       2021-08-01 11:42:36 +08:00
    赞。开源软件不易,做的完善了更是不容易
    关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   我们的愿景   ·   实用小工具   ·   3320 人在线   最高记录 6543   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 468ms · UTC 13:36 · PVG 21:36 · LAX 06:36 · JFK 09:36
    Developed with CodeLauncher
    ♥ Do have faith in what you're doing.