尹吉峰：使用 OpenResty 搭建高性能 Web 应用

2019 年 8 月 31 日，OpenResty 社区联合又拍云，举办 OpenResty × Open Talk 全国巡回沙龙·成都站，原贝壳找房基础架构部工程师尹吉峰在活动上做了《使用 OpenResty 搭建高性能 Web 应用 》的分享。

OpenResty x Open Talk 全国巡回沙龙是由 OpenResty 社区、又拍云发起，邀请业内资深的 OpenResty 技术专家，分享 OpenResty 实战经验，增进 OpenResty 使用者的交流与学习，推动 OpenResty 开源项目的发展。

尹吉峰，原贝壳找房基础架构部工程师，多语言爱好者，偏向异步和函数式编程，酷爱原型搭建，先后在贝壳使用 OpenResty 搭建了 WebBeacon、图片处理等服务。

以下是分享全文：

今天和大家介绍一个 OpenResty 比较小众的使用场景，使用 OpenResty 做 Web 框架写服务，希望能给大家带来一些新的东西。

为什么要做高性能服务

首先给高性能 Web 服务一个简单定义：QPS 过万的服务是高性能 Web 服务。我认为一个好服务绝对不是优化出来的，架构决定一个服务的基准，过早优化是万恶之源。

大家都知道如果做 Web，Web 只需要水平伸缩、扩展就行，那么为什么还要高性能呢？事实上有些服务是不适合水平伸缩的，比如有状态的服务。我盘点了过去几年使用过的服务，发现有状态的数据库服务的确很多：

• 统一集中式的缓存 Redis
• 高性能的队列 Kafka
• 传统的关系型数据库 MySQL、Postgres
• 新兴的非关系型数据库 MongoDB、Elasticsearch
• Embedded 数据库，属于内嵌数据库，跟服务配置在一起的 SQLite3、H2、Boltdb
• 最新的时序数据库 InfluxDB、Prometheus 等

上面这些服务实际上都是有状态的，它的扩容、伸缩不是那么简单，一般是以 Sharding 的方式通过人工操作手动做伸缩。

而基础服务和平台服务是整个公司的服务所依赖的，一家公司的服务可能有成千上百台机器，但是基础服务应该只占很小的比例，所以我们对基础的通用服务有高性能需求，比如 Gateway 网关、Logging、Tracing等监控系统，以及公司级别的用户的 API、Session/Token校验，这类服务对性能有一定要求。

此外，水平扩展是有限度的，随着机器的增多，机器提供的容量、QPS 不是一个线性增长的过程。

高性能的好处，我认为有以下几个方面：

• 成本低，运维简单：伸缩容不敏感，一台机器可以扛多台机器的量；
• 便于流量分发：机器少可以便于流量分发，部署快意味着回滚快；面对完全不兼容，或者对极度的流量平滑迁移有需求的情况会用到红绿部署；
• 简化设计：应用内的缓存会更高效，按机器纬度可以做一些简单的 ABTest；
• “程序员的自我修养”。

如何做高性能服务

绝大部分Web 应用实际上都是 IO 密集型服务，而非 CPU 的密集型服务。对 CPU 的性能，大家可能没有一个直观感受，这里给大家举个例子：π 秒约等于一个纳世纪，说的是人在观察世界的时候是以秒级的尺度。而 CPU 的是纳秒级别的尺度。对于 CPU 来说，3.14 秒相当于人类的一个世纪这么漫长，1 秒就相当于 CPU 的“33 年”。如果是 1-2个毫秒，我们觉得很快，但对于 CPU 实际上是它的“20 天左右”。

而这仅仅是单核，实际上还有多核的加持。面对这么强的 CPU 性能，怎么充分利用呢？这就有了 2000 年以来的新型编程模式：异步模型，也叫事件驱动模型。异步编程、事件驱动，是把阻塞的、慢的 IO 操作转化成了快的 CPU 操作，用通过 CPU 完全无阻塞的事件通知机制来驱动整个应用。

我自2012 年在手机搜狐网接触 Python Tornado 异步编程以来，用过多个语言和框架做异步编程。我认为同步模型就是“线程池 频繁的上下文切换 线程之间数据同步的大锁”，这意味着如果是同步模型，需要根据当前的 loading 去做系统的调优，根据目前的各个状况，一点一滴去做，实际上调优难度是非常大的。

而异步模型相当于一个高并发的状态，因为它是EventLoop，是在不停循环的。同时有两个请求过来，它可能同时会触发，如果其中一个请求操作 CPU 没有及时让出，就会影响另一个请求。它用潜在的时延换来更高的并发。高性能就相当于“异步