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

Web 架构&设计

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

作者： Hrishikesh Barua

正文：

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