Stone的由来

Stone最初的目的是为了解决Laravel框架的性能问题， 公司是Laravel框架的重度使用者，在绝大多数场合， Laravel都可以很好的应对，但是对于一些并发量高的应用，比如定时抢购的活动， 存在一些问题。问题的根本原因是：Laravel框架本身性能不高， 由于PHP程序执行机制的特殊性，框架的性能会极大的限制程序的并发能力，这一点相信很多选择或者没选择Laravel的人都有体会。去年年底， 在解决一个性能问题的时候， 尝试性的使用Laravel+Swoole的组合搭建一个TCP的业务Server， 在Laravel资源完全初始化的情况下， 使用Swoole常驻内存并对外提供服务， 这样每个请求就不必再去初始化资源， 从而得到极高的性能提升。然后， 需要对前端提供接口， 所以TCP Server前面再放置一个lumen，对外提供HTTP接口服务。为了便于管理， 我给这个方案取了一个名字：Stone，希望它能稳定发展， 成为性能解决方案的一块基石。

到目前为止，Stone作为接口的方式已经在线上稳定运行超过3个月，有一些很重要的接口也在使用。这里面， 需要重点赞一下Swoole，因为是有了swoole的高性能和稳定， 才有后面的这些事情。

早期Stone的一些缺陷

早期Stone的方案缺陷主要体现在两方面：

  1. 程序架构变得复杂，加大测试难度，同时并发性能受限于lumen。

    • PHP以简单快速得到大家喜爱， lumen的方式， 程序被分离到laravel和lumen中，加大管理难度。
    • Swoole常驻内存， 修改调试需要不断重启进程
    • lumen虽然性能不算差， 但是和swoole比起来相差还是很远， 并发要求很高的场合， 还是会成为瓶颈
    • 当方案出现问题时， 无法快速降级

  2. 适用范围较窄

    • 只适用一些无状态的接口调用的方式
    • 不支持视图显示， 不支持Session

Stone近期的工作

可以参看之前写的一个优化计划， 目前基本达到的预期的效果。 主要工作为：

  1. 提高了Stone的适用性， 提供Stone-Web和Stone-Server两种运行方案。前者针对页面后者针对API服务。
  2. 加强了Stone的兼容性，提供Laravel4.x和Laravel5.x的支持， 支持composer安装
  3. 避免修改Laravel代码，代价是引入了对runkit的依赖， 但是我认为是值得的。 当然， 如果你不方便使用runkit，倾向于修改laravel源码， 也是可以的。
  4. 简化了架构， 去除了lumen的依赖， 实现了FastCGI协议， 直接和nginx交互，大大提高了性能。
  5. 大大简化了使用难度和降级难度， 极小的修改后使用Stone进程替代PHP-FPM就能使用， 降级时替换回来即可。你甚至可以同时使用两种方式， 同一份代码， 只有性能要求高的接口才使用Stone。

关于Stone的一些测试数据

  1. 线上核心接口请求次数累计超过20亿次，运行稳定
  2. Laravel5下测试，Stone-Web RPS大于3000， Stone-Server RPS大于8500，同等条件下，原始的Laravel RPS只有120.
  3. 线上运行超过2年的Laravel4 项目， 包括2000多个路由， 大量的过滤器等， Stone-Web RPS大于1000， 同等条件下， Laravel RPS只有80多。
  4. 一个实际项目的首页， 包含大量的数据库查询， Stone-Web RPS 为360多， 同等条件下， Laravel RPS只有30多。

进一步了解Stone

只需5分钟， 为你的Laravel项目提供10倍以上的性能提升， 不想试试吗？ 如果你对此感兴趣， 可以继续了解Stone是怎么优化Laravel性能的。