我为什么要开发一个 MixPHP 框架

最近业余时间一直在开发 ExpressPHP 的第二个版本 MixPHP，今天下班想起之前一个面试官的问题：你为什么还要再造一个轮子呢？仔细回想，第一个版本，现在想来确实 “炫技” 的成份比较多，现在推翻第一版，又重构一个所谓的 “全功能 PHP 框架” ，这东西又不赚钱，我到底为了啥？其实，写程序和写诗有很多相似之处，同样需要优雅的语法，好作品也同样想要有更多的人欣赏，感性完了，接下来理性的分析一下。

国内常用的框架

国内较流行的 PHP 框架，参考 Lagou 等招聘网中的招聘信息与众多同事口口相传。

ThinkPHP: 易上手，文档友好、过度封装
Yii: 安全性高、规范、性能稍差
Codeigniter: 简单、高效、文档友好
Yaf/Phalcon: C 扩展，高性能

后端开发业务场景

通常后端开发有以下这些场景：

网页 /后台管理开发
API 开发
TCP 服务器开发
UDP 服务器开发
异步队列消费者开发
定时任务开发

采用多种技术，复杂度、成本必然更高

因为不同场景的诉求不同，所以很多公司采用多种框架来开发，APP 的 API 采用 Yaf/Phalcon，后台管理采用 Yii、ThinkPHP、Codeigniter，TCP/UDP 服务器又采用 Java/C++来写，一个后端开发就需招聘擅长不同框架不同语言的程序员来开发。

现有 MVC 框架的弱项

在网页 /后台管理 /API 开发方面，流行的各种 PHP 框架一直都很擅长，可是在控制台程序开发方面：

HTTP/TCP/UDP 服务器开发：还未有流行的 PHP 框架封装。
异步队列消费者开发：只提供了 CLI 模式下运行控制器方法，并未提供主进程多子进程的进程模型，并未提供多线程处理。
定时任务开发：还需依赖第三方工具 crontab 等，PHP 框架本身不能实现。

PHP 框架开发效率与性能不可兼得

Yaf/Phalcon 这样 C 扩展框架，如果开发业务十分复杂的后台与网页，开发效率不高，中小企业开发效率才是生存王道，而开发效率高的 ThinkPHP、Yii、Codeigniter 开发 API 性能又差了点，当然性能可以从架构上着手，但是如果高性能与开发效率可以兼得，岂不更好。

MixPHP 试图解决这些

高性能与开发效率兼得：参考 Yii、ThinkPHP、Codeigniter 提高开发效率的特性，编写全部面向对象的 MVC 框架，使其同时支持 LNMP 架构与 Swoole 应用服务器，需要开发效率时采用 LNMP 传统架构，需要高性能 API 时，修改少量代码，即可切换为 Swoole 应用服务器，把框架类库预加载至内存，数据库按进程长连接，可达到 Yaf/Phalcon 的性能。
多线程异步队列服务：只需写好控制器方法，然后在配置文件中配置下路由命名空间、进程、线程数量，就可在 CLI 模式中启动多进程多线程模型的异步队列处理程序。
定时任务服务：只需写好控制器方法，然后配置下路由命名空间、定时循环条件，就可在 CLI 模式中启动动态多进程模型的定时任务处理程序。
TCP/UDP 服务：一步步来，后续版本再考虑加入。

结尾

许愿：希望以后所有后端开发，如用 PHP，就用一个框架可好？

GitHub

支持的用户请加个 Star 吧，让更多人发现 MixPHP。 https://github.com/mixstart/mixphp

onanying

2017-10-12 15:30:45 +08:00

@Immortal 可能你还没有深入了解 Swoole，Swoole 有很多领域与使用方法，而我使用的是 SwooleHttpServer 这一块，而这一块的话，最大的优势就是：因为是 CLI，request/response 变为了事件，从而允许对象常驻内存，而 Yii 这类的框架是以 Apache/PHP-FPM 方式为基础的，无法在 Swoole 里常驻运行，当然应该如果有人去特殊处理一下，应该也可能，不过我没有这方面的经验，而如果不使用常驻运行，包含代码与执行框架全放在 request 事件里，那这样的运行方式与 PHP-FPM 的多进程模型，没有什么差别，而 MixPHP 从设计开始就是以常驻内存的方式设计的，也考虑了 SwooleHttpServer 内运行多个 HOST 的问题，还有 session，PHP 自带的 Session 无法在 CLI 下运行，这就导致了基于 PHP Session 封装的框架都无法运行，Session 做自己定制一下，还有全局变量问题，传统框架搭设在 SwooleHttpServer 面临很多问题，实际上无法真接运行的，大部分人是把 Swoole 使用在传统框架内，当 client 端使用。