Pipy for Next Web：静态内容服务与缓存加速

背景

Pipy 是面向云、边缘和 IoT 的可编程代理，除了作为代理使用，还可以作为静态资源服务器。在 Pipy 教程：静态服务 中就曾介绍过如何使用 Pipy 提供静态资源服务。在获得静态资源的快速响应的同时，借助代理的能力静态服务器也可以响应动态请求，近几年流行起来的 CaaS（内容即服务 Content as a Service）正是使用这种架构实现了 CMS（内容管理系统）的前后端分离。

CMS（Content Management System）适用于管理数字内容的创建和修改的软件。CMS 降低了用户创建、管理、修改、存储数字内容，并发布到网站上的门槛。CMS 包含了前端、后端和数据存储，就是我们常说的单体服务。CMS 有着单体服务的种种缺点：复杂性高、性能低、可靠性差、扩展能力受限灵活性低；同时作为内容的展示平台，内容的展示方式单一不够灵活。如今的内容展示不再仅限于浏览器，移动互联网蓬勃发展之后，更多的展示渠道：移动设备浏览器、App、边缘设备如 TV、广告电子终端。

如此就有了现在的 Headless CMS（无头 CMS，如 Tez、DotCMS、Contentful、Strapi、Cockpit.）来解决传统的 CMS（Wordpress/Drupal 等） 所面临的问题。Headless CMS 有着如下的优点：

• 一次编写，多处展示

• 无需交互，响应快

• 通过 API 对外呈现，无需特定语言或框架

• 安全性提升

但 Headless CMS 也不是完美的，比如很明显的缺点就是前后端分离后无法实时发送用户交互数据，但也有解决方案。

实际上无头 CMS 或者内容即服务 并不是我们今天的重点，而是要介绍灵活多变的 Pipy 在内容即服务基础设施的角色。这里要说下，我们的官方网站 https://flomesh.io 就是使用 Pipy 作为内容即服务的基础设施。

文中使用的源码都可以从 GitHub 仓库 https://github.com/flomesh-io/pipy-demos 下载。

整体架构

下图展示了 Pipy 在内容即服务基础设施中的角色：静态服务器和 CDN。

存储在 Git、数据库或者 Headless CMS 中的内容，通过 DevOps 构建成静态内容后交付给静态服务器。代理服务器会响应静态和动态内容的请求，并对静态内容进行缓存。这里可以理解为二级缓存，CDN 作为一级缓存）。

实现

静态服务器

Pipy 作为静态服务器提供了静态资源展示、Logging、代理 &路由（支持多站点）、缓存（服务器缓存和 HTTP 缓存）、TLS 卸载等功能。这里通过模块化的方式提供，模块化也方便后期对功能的扩展，比如 metrics、动态服务代理所需的各项功能。

上面提到的几种功能在过去的文章中都有介绍过实现，有兴趣的同学可以参考：

• 静态资源服务
  

• Logging
  

• 路由
  

• 服务器缓存
  

• HTTP缓存
  

• TLS
  

这里解释下路由的功能，主要是通过 Pipy 提供多个静态站点的服务。比如我们使用一个 Pipy 提供 https://flomesh.cn 和 https://flomesh.io 两个静态服务。

CDN

CDN 的实现则会简单一些，主要用到了缓存和 TLS 卸载的实现。

CDN 同样支持多站点的内容分发。

Demo

在源码中我们使用 Gatsby 作为静态资源生成器，实现了一个简单的站点。

克隆代码后，在 sample-site 目录中执行 build.sh 脚本开始构建。构建后的静态内容，会自动“发布”到 静态服务器 static-site 的目录中。

本地在 static-site 目录中执行命令 pipy main.js，启动静态服务。服务分别监听 20080 和 20443 端口，作为 HTTP 和 HTTPS 的端口。

在浏览器中输入 http://localhost:20080 即可打开（图中展示的是 HTTP 缓存功能）。

在 cdn 目录中执行相同的命令 pipy main.js，可以启动 CDN 服务。为了本地测试方便，CDN 服务监听在 20081 和 20444 端口。

总结

Pipy 作为面向云、边缘和 IoT 的可编程代理，以其灵活性可以处理各种的场景；同时有着快、小的特性，既满足云端的高性能需求，又适应边缘低资源的场景。

此外 Pipy 还支持 x86、ARM、RISC-V 等多种计算架构，比如使用 arm 云主机为我们的官网部署了大量的 CDN 节点。

思考

看标题意味着这是系列的第一篇，可能细心的小伙伴发现了本篇中介绍的架构的“不足”，每次内容的更新非常依赖 CICD 进行站点的更新，内容的实时性较差。实际上这也不算是缺点，其实现简单适合内容更新频率低的场景。

下一篇，我们来看下内容实时性高的场景要如何去实现。