当前位置: 首页 > 软件库 > Web应用开发 > Web框架 >

MixPHP

基于 Swoole 4.4+ 单线程协程 PHP 微服务框架
授权协议 Apache2.0
开发语言 PHP
所属分类 Web应用开发、 Web框架
软件类型 开源软件
地区 国产
投 递 者 彭俊智
操作系统 跨平台
开源组织
适用人群 未知
 软件概览

MixPHP 是一个 PHP 命令行模式开发框架;基于 Vega 驱动的 HTTP 可以同时支持 Swoole、WorkerMan、FPM、CLI-Server 生态,并且可以无缝切换;V3 是一个高度解耦的版本,整体代码基于多个独立的模块构建,即便用户不使用我们的脚手架,也可以使用这些独立模块,并且全部模块都支持原生开发。例如:你可以只使用 mix/vega 来搭配 laravel orm 使用;可以在任意环境中使用 mix/database 和 mix/redis;可以使用 mix/grpc 原生代码编写 gRPC;所有的模块你可以像搭积木一样随意组合。

独立模块

核心模块全部可独立使用,并且都支持原生代码开发。

  • mix/vega PHP 编写的 CLI 模式 HTTP 网络框架,支持 Swoole、WorkerMan、FPM、CLI-Server
  • mix/database 可在各种环境中使用的轻量数据库,支持 FPM、CLI、Swoole、WorkerMan,可选的连接池 (协程)
  • mix/redis 可在各种环境中使用的 PHP Redis,支持 FPM、CLI、Swoole、WorkerMan,可选的连接池 (协程)
  • mix/redis-subscriber 基于 Swoole 协程的 Redis 原生协议订阅库
  • mix/grpc 基于 Swoole 协程的 PHP gRPC 库,包含 protoc 代码生成器、服务器、客户端
  • mix/websocket 基于 Swoole 协程的 PHP WebSocket 服务器与客户端
  • mix/cli PHP 命令行交互指挥官
  • mix/worker-pool 基于 Swoole 的协程池、工作池库
  • mix/validator 基于 PSR-7 的验证库
  • mix/event 基于 PSR-14 标准的事件调度库

服务器

支持多种服务器驱动,并且可以无缝切换。

快速开始

提供了现成的脚手架,快速创建项目,立即产出。

composer create-project --prefer-dist mix/cli-skeleton cli
composer create-project --prefer-dist mix/api-skeleton api
composer create-project --prefer-dist mix/web-skeleton web
composer create-project --prefer-dist mix/websocket-skeleton websocket
composer create-project --prefer-dist mix/grpc-skeleton grpc

推荐阅读

技术交流

知乎:https://www.zhihu.com/people/onanying
官方QQ群:284806582825122875 敲门暗号:phper

Golang 框架

OpenMix 同时还有 Golang 生态的框架

旧版文档

License

Apache License Version 2.0, http://www.apache.org/licenses/

  • PHP 性能最好的应该就是原生代码了吧,真的么?MixPHP 是基于 Swoole 扩展的高性能 PHP 框架,今天我来做个对比测试,一行代码 VS 六千多行代码。 环境 虚拟机: 4 核,1G 使用 ab 工具压测,命令:ab -n 10000 -c 300 URL 原生 PHP Apache worker模式,mpm配置如下: ServerLimit 50 ThreadLimit 200 St

  • 经常在群里听到一些朋友问:TP 的项目怎么迁移到 mixphp 来处理高并发,我通常都是回复需要重写,可是一个开发很久的 TP 项目,代码量巨大,又怎么可能会花大量时间成本来重写呢? 那么为何我们不尝试换一种思路来解决问题? 在现有框架不变的情况下,引入 mixphp 来处理高并发的部分。 瓶颈分析 二八效应在任何领域都存在,如果你做过多个项目,你就会发现: 一个项目中高并发的接口或页面,通常只占

  • 最近把 MixPHP 逐步重构到了 V3 版本,之前停更了很长时间,是因为一直在开发 MixGo ,回想起 V2~V2.2 版本中我做了很多尝试,其中特别是 V2.2 我非常激进的直接 all in 单线程协程,当时我是这样想的:MixPHP V2.1 为何从 Reactor+Manager+Worker 多进程改为单线程协程,但是切换后实际上带来了一些问题: 很多用户用了一些奇奇怪怪的第3方库,

  • ## 创建命令 命令就是一个命令行程序,`Command` 类似于 HTTP 应用的 `Controller` 控制器,负责业务逻辑,不同的是命令行程序通常是处理复杂的数据处理逻辑,相比简单的 `CRUD` 操作要复杂很多。 | 类 | | --- | | mix\console\Command | >[info] 初始代码中命令行应用的命令在 commands 目录。 ## 一个简单的命令 首先

  • MixPHP 是一个基于 Swoole 的高性能框架,CodeIgniter 是一个元老级的轻量级框架,Yii 是一个非常流行的框架,以下是三个框架的对比。 由于 Yii/CodeIgniter 是基于 Apache/PHP-FPM 的传统框架,如果使用 MixPHP 的正常 Swoole 部署方式来对比,显得有些不公平,由于 MixPHP 同时支持在 Apache/PHP-FPM 中运行,所以此

  • ## Mix\Redis\Redis::class 基于 phpredis 封装,内置连接池,可独立使用。 ## 组件 使用 [composer]([https://www.phpcomposer.com/](https://www.phpcomposer.com/)) 安装: ~~~ composer require mix/redis ~~~ ## 依赖注入配置 - [manifest/bea

  • MixPHP V3 主推 Swoole、WorkerMan 驱动,因为这两个平台性能强劲。但是大部分的 PHP 开发者都是开发 API, Web 的程序员,热更新可能是最大的刚性需求,因此我对 Vega 做了扩展,让 MixPHP 增加了 PHP-FPM、CLI-Server 的支持,开发环境可以使用这两种模式,线上部署时切换为性能更强劲的 Swoole、WorkerMan 驱动。 开箱难即用 P

  • 国内中小型公司有大量的微信接入需求,EasyWeChat 是一个非常流行的微信开发库,由于该库是为 FPM 模式的传统框架而打造,因此很多 Swoole 用户不知道如何使用,下面详细介绍一下 MixPHP v2.1 中如何使用。 Hook Guzzle 首先由于 overtrue/wechat 是基于 GuzzleHttp 开发的,因为 GuzzleHttp 无法直接在 Swoole 中使用,所以

  • ## gRPC [gRPC](http://link.zhihu.com/?target=https%3A//github.com/grpc/grpc) 是谷歌基于 [Protobuf](https://github.com/protocolbuffers/protobuf) + Http2 研发的 RPC 通用框架,几乎支持流行的全部语言,该框架使用 .proto 文件定义交互的数据结构,并通过

  • ## 中间件 中间件主要用于拦截或过滤应用的 HTTP 请求,并进行必要的业务处理,通常使用在登录验证的场景。 ## 定义中间件 源码中默认自带了两个中间件,一个前置,一个后置。 >[success] - 中间件类名必须带 Middleware 后缀。 > - 配置文件 main.php 中可定义中间件目录的命名空间。 ### 前置中间件 如果想拦截请求不往下执行,只需在 $next() 前 re

  • ## 创建命令 命令就是一个命令行程序,`Command` 类似于 HTTP 应用的 `Controller` 控制器,负责业务逻辑,不同的是命令行程序通常是处理复杂的数据处理逻辑,相比简单的 `CRUD` 操作要复杂很多。 | 类 | | --- | | mix\console\Command | >[info] 初始代码中命令行应用的命令在 commands 目录。 ## 一个简单的命令 首先

 相关资料
  • 问题内容: Node.js服务器适用于支持回调函数的基于事件的模型。但是我无法理解它比传统的基于线程的服务器(线程等待系统IO)有什么优势。在基于线程的模型的情况下,当线程需要等待IO时,它将被抢占,因此不会消耗CPU周期,因此不会增加等待时间。 Node.js如何改善等待时间? 问题答案: 线程是相对较重的对象,具有资源足迹,一直扩展到内核。当您将线程驻留在阻塞的系统调用中或互斥或条件变量上时,

  • 与子程序(或者说函数)一样,协程(coroutine)也是一种程序组件。Donald Knuth 曾说,子程序是协程的特例。 一个子程序就是一次函数调用,它只有一个入口,一次返回,调用顺序是明确的。但协程的调用和子程序则大不一样,协程允许有多个入口对程序进行中断、继续执行等操作。 Python2 可以通过 yield 来实现基本的协程,但不够强大,第三方库 gevent 对协程提供了强大的支持。另

  • 线程(thread)是进程(process)中的一个实体,一个进程至少包含一个线程。比如,对于视频播放器,显示视频用一个线程,播放音频用另一个线程。如果我们把进程看成一个容器,则线程是此容器的工作单位。 进程和线程的区别主要有: 进程之间是相互独立的,多进程中,同一个变量,各自有一份拷贝存在于每个进程中,但互不影响;而同一个进程的多个线程是内存共享的,所有变量都由所有线程共享; 由于进程间是独立的

  • Swoole\Coroutine\Server 与 异步风格 的服务端不同之处在于,Swoole\Coroutine\Server 是完全协程化实现的服务器,参考 完整例子。 优点: 不需要设置事件回调函数。建立连接、接收数据、发送数据、关闭连接都是顺序的,没有 异步风格 的并发问题,例如: $serv = new Swoole\Server("127.0.0.1", 9501); //监听连接

  • 操作系统的设计,可以归结为三点: 以多进程形式,允许多个任务同时运行; 以多线程形式,允许将单个任务分成多个子任务运行; 提供协调机制,一方面防止进程之间和线程之间产生冲突,另一方面允许进程之间和线程之间共享资源。 本章主要介绍在 Python 中如何进行进程和线程编程等,主要有以下几个方面: 进程 线程 ThreadLocal 协程 参考资料 进程和线程 - 廖雪峰的官方网站 进程与线程的一个简

  • 我对web应用程序向微服务的发散点感到困惑--它是在url级别还是模型级别?举个例子,假设我有一个单片应用程序,它提供3个页面。假设每个页面都有一个单独的用法,我想用它们自己的微服务来支持它们。下面哪一种是实现基于微服务的体系结构的正确方法: 我创建了三个不同的应用程序(微服务),每个都包含一个页面的(路由、控制器、模型、模板)。然后根据哪个页面被请求,我将请求路由到那个特定的应用程序。这意味着从

  • C++11的伟大标志之一是将并发整合到语言和库中。熟悉其他线程API(比如pthreads或者Windows threads)的开发者有时可能会对C++提供的斯巴达式(译者注:应该是简陋和严谨的意思)功能集感到惊讶,这是因为C++对于并发的大量支持是在编译器的约束层面。由此产生的语言保证意味着在C++的历史中,开发者首次通过标准库可以写出跨平台的多线程程序。这位构建表达库奠定了坚实的基础,并发标准

  • 本文向大家介绍微服务哪些框架相关面试题,主要包含被问及微服务哪些框架时的应答技巧和注意事项,需要的朋友参考一下 Dubbo,是阿里巴巴服务化治理的核心框架,并被广泛应用于阿里巴巴集团的各成员站点。阿里巴巴近几年对开源社区的贡献不论在国内还是国外都是引人注目的,比如:JStorm 捐赠给 Apache 并加入 Apache 基金会等,为中国互联网人争足了面子,使得阿里巴巴在国人眼里已经从电商升级为一