我为什么要开发一个 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

sagaxu

2017-10-12 19:55:36 +08:00

@onanying 很多公司一个部门内部就有几组不同框架和不同程度的轮子，每个选型的人都有理有据，都觉得自己业务特殊，实际上很多时候把他们的框架互换，可能也没多少不利的影响。如果公司可以养 3 个以上只做基础设施不碰业务的平台开发人员，造一些轮子也无碍，不舍得养的话，另造轮子很可能得不偿失。

@hhacker 问题是资深或者高级开发，出发点不是公司利益，而是自身利益，力排众议用自己的轮子，成了可以写晋升 PPT，可以巩固自己专家地位，搞砸了大步了跑路换个公司继续坑。空降 CTO，然后全盘重构的例子多了，有多少不是政治因素，单纯技术决定的重构，只有当事人们自己清楚了。

我们公司在 PHP 技术积累上国内排前 5 应该没问题，就在这周还有好多次 coredump，一路踩过无数的坑，十次里面九次是自造轮子引起的，我们是因为每天几十亿次请求，没法选择那些用户基数大比较 stable 的 PHP 框架。