Edgemesh 的 P2P Web 加速服务是如何推出到生产环境的

Edgemesh 提供了一种基于 WebRTC 协议族的 P2P Web 加速服务，可将通常由传统 CDN 处理的部分流量分流给一些基于浏览器在 P2P 网络上共享的缓存。在最近几个月中，Edgemesh 实现了将版本推送到生产环境，他们分享了这一做法。

Edgemesh 的技术依赖于一种“中继”网络，该网络由使用 WebRTC 协议族的终端用户浏览器创建。传统的 CDN 具有全球范围内的边缘节点（Edge Location），通过定位接近终端用户的边缘节点，降低了对终端用户的延迟。Edgemesh 的缓存内容位于用户浏览器上，通常浏览器也是这样做的，只是位于二级缓存上。该缓存内容使浏览器可以相互通信而提供内容，而非通过 CDN 定位并获取内容。要启用 Edgemesh，需要在 Web 页面上运行一个 JavaScript 小程序。这在生产环境中意味着 Edgemesh 的客户端 JavaScript 可运行于上千的浏览器上，跨越多个地理区域。这种中继网络被称为“网格”（Mesh）。

Edgemesh 使用了 Docker 容器作为基础开发单元。其架构运行于 SmartOS 区域的 Joyent 公开云上，是运行在真实的物理机上，而非在虚拟机上。Edgemesh 使用Joyent 的 Autopilot 模式管理容器，这使得容器可获得更高度的操作自治性。数据库系统同样也通过 Triton 运行在容器内。数据库文件、日志文件等的状态信息通过 Joyent Manta 存储在稳定存储中，并在 Google’s Storage Platform 上具有二级备份。

在 4 月 1 日启动向生产系统的迁移之前，Edgemesh 的工程团队就认识到了其中的主要挑战，包括：无需客户输入就能调试生产环境中错误的能力、自动化受限于时间的更新发布、跨五百个网络的“网格”、跨五十个国家的近 1TB 数据下线到“网格”中。到 5 月 26 日，团队开始让传入流量全面进入到“网格”中。在一周的时间内，来自于原始客户服务器的 TB 级流量已有半数以上被下载到“网格”中，平均客户页面的加载时间下降了 33%。期间，团队持续地测量和监控着各种度量，包括“网格”的大小，及独立页面的加载时间。一旦 Edgemesh 客户遇上错误，Edgemesh 就会退出，让浏览器恢复正常的操作。从错误中采集的数据会汇报给 Edgemesh，用于对错误的分析。

在部署软件到生产环境的过程中，团队使用了三个指导原则。前两个原则分别是通过自动化维持一致性，以及通过周期性重建基础设施减少异常实体的攻击表面。第三个原则是从最小可能值启动而节约成本，这更像是前两个原则的输出。

为深入了解 Edgemesh 在推出到生产环境中所面对的 DevOps 挑战，InfoQ 采访了 Edgemesh 的 CEO Jacob Loveless。在问及 Edgemesh 对 Docker 基础设施所使用的监控工具类型时，Loveless 给出了如下的回答：

对系统状态，我们使用了 Prometheus 。此外我们还具有一个内部系统，用于给出错误和消息类型记录等信息（例如，来自于客户的 WebRTC 统计）。这些度量有助于每个应用确定请求向上扩展的时机。

Edgemesh 的大部分代码存在于客户端，这一分布特性使得如何确保发布到生产环境前系统的纯洁性成为一个重要挑战。Loveless 详细解释了他们的试机（即生产系统前）设置：

我们具有一个标准的 CI/CD 平台，我们在其中实现了 Docker 构建，并将这些部署到开发环境。一旦抵达“试机”阶段，我们就将镜像标记为“试机”，这样的镜像就进入到一个“全新设计”（Clean Slate）状态。我们有一个运行试机的数据中心，在该数据中心处理了近 10% 的全球流量。一旦我们可对发布版本做标记，我们就将 Docker 镜像标签修改为“master”，并将该镜像在所有的数据中心中滚动到生产环境。当需要回滚时，我们仅需要在注册项中更改 Docker 镜像标签，这样镜像将在下一次运行“全新设计”时得以重置。因此，可以说我们每日都会做一次部署，但是这在很多情况下并非一个新的发布版。可以说我们每五到十天发布一个完全发布版到生产环境。

这里的“全新设计”指的是 Edgemesh日常重建数据中心容器的方式。这确保 Edgemesh 可以坚持执行上面所提出的三个部署原则。

通过允许试机设置去接收生产环境数据，并辅以易于回滚更改的机制，Edgemesh 模拟了代码会在生产环境中遇上的一些生产环境负载和流量模式。但这通常是不够的，对此 Loveless 指出，Edgemesh 的策略是“确保软件版本可以快速地迁移到生产环境”。

每天都重置那些在基础规模上会自动向上扩展的实例的规模，这是“全新设计”策略的一部分，并在每个数据中心得以实施。如果数据中心正承受着高流量和重置后基线（开始）状态无法处理的问题，Edgemesh 需要确保客户不会察觉这些错误。Loveless 解释了这一实现机制：

当数据中心 A 开始“全新设计”时，首先要做的就是从 DNS 条目中注销自身。我们在 DNS 记录上运行低 TTL（每 30 秒），中间暂停五分钟，使得有时间确保所有流量被重定向到数据中心 B 和 C。五分钟后，数据中心 A 开始“全新设计”。当 A 重新在线后，它重新注册到 DNS 服务器，开始接收流量。进而数据中心 B 开始“全新设计”（这是在 A 发送允许 B 知道 A 重新恢复在线并接收流量的消息后）。在这一转换中，为处理一些额外的负载，数据中心 B 和 C 通常将会向上扩展。

查看英文原文： How Edgemesh Rolled Out Its P2P Web Acceleration Service to Production