借助Volterra App Delivery Network (ADN)拉近Web应用与用户的距离

F5生态系统 | 2020年7月30日

本文是一个全新博客系列的开篇。该系列将探讨企业面临的真实问题，并介绍Volterra的App Delivery Network（ADN）如何解决这些问题。本文重点介绍全球在线企业每天都会面临的一项关键挑战：Web应用性能。随着大多数消费者居家办公，这一挑战变得更加严峻。本文将介绍Volterra如何帮助企业消除Web应用的“距离”障碍，无需重写应用，即可将应用性能提升77%。

什么是Web应用性能？

Web应用性能通常以最终用户感知到页面内容可见所需的时间来衡量。Web开发人员会使用多项指标来衡量Web应用性能，例如首次内容绘制、最大内容绘制或文档完成。在本博客中，我使用“文档完成”指标来衡量Web应用的性能。Web开发人员会使用Web Page Test、Google Lighthouse或Rigor等工具测量这些指标。

为什么Web应用性能很重要？

Web应用性能略有下降，就会对用户体验产生巨大影响，进而影响在线门户的销售额。电商巨头Amazon报告称，应用性能下降1秒会造成16亿美元的收入损失。正如Akamai在这份稍早发布的报告中所述，多个垂直行业的在线企业也受到类似的经济影响。Google和Microsoft报告的经济影响数据也与此类似。

图1

这些数据点清楚地表明，在线企业高度重视Web应用性能。

面临哪些挑战？

以电商领域的一家在线企业为例。许多电商企业将Web应用部署在一个或少数几个数据中心，而这些数据中心并未覆盖其用户所在的所有国家/地区。当用户与数据中心位于不同的国家/地区时，用户与数据中心之间的网络延迟较高，导致页面加载时间长达近6–12秒。如上所述，当页面加载时间超过5秒时，跳出概率会升至90%。

下面以图2为例，解析Web应用的页面加载过程

图 2

首先，建立安全的SSL会话，这需要在用户浏览器与Web应用之间往返传递6条消息。
接下来，Web应用通常会使用用户浏览器中的Cookie，判断用户是否拥有该电商商家的账户。
系统会根据Cookie判断用户是否有账户。如果有，则显示登录页面；否则，显示访客结账页面。

仅为建立安全的SSL会话，就需要通过高延迟链路（可能是跨大西洋或跨太平洋链路）传输6条消息，这必然会影响页面加载时间，进而导致用户体验不佳。

Volterra ADN如何提升应用性能？

可以通过多种应用优化技术来提升Web应用性能，例如压缩图像或优化依赖项，以缩短页面加载时间。但受应用设计所需满足的业务要求影响，这些优化往往可能无法实施。即使可以实施，也可能并不可行，因为最初编写应用的开发人员可能已离职，或正忙于开发新服务。因此，电子商务组织的DevOps团队重视无需更改应用即可提升应用性能的解决方案。

Volterra提供VoltMesh和VoltStack两款产品。二者与Volterra的ADN结合使用时，可将应用性能提升多达75%（请参阅下一节中的演示）。Volterra的VoltMesh是一款全球分布式网络和安全产品，在Volterra的ADN上完成配置后，还可提供应用加速功能。Volterra的VoltStack提供分布式应用部署和生命周期管理，使用户能够将应用的部分工作负载卸载到Volterra的ADN，从而进一步提升应用性能。

VoltMesh和VoltStack通过以下三种方式提升电商企业的Web应用性能

解决方案1：在Volterra ADN上终止SSL（又称TLS卸载）

提升Web应用性能最简单的方法是在Volterra Global ADN上终止SSL会话。用于建立SSL会话的6条消息会在本地发送到所在国家/地区的全球网络边缘，无需经过跨大西洋或跨太平洋链路。远程Volterra全球网络站点与源服务器之间将保持持久SSL会话，从而进一步提升性能。具体如图3所示。

图 3

解决方案2：将Cookie处理等延迟敏感型处理迁移到Volterra ADN

为进一步提升性能，企业可以将应用中对延迟敏感的部分部署到ADN上。Web应用中对延迟敏感的部分包括Cookie处理、GraphQL或面向前端的后端（BFF）。以电商企业为例，通常会通过处理Cookie来确定向用户呈现哪个页面。例如，如果用户有账户，则呈现登录页面；否则呈现访客页面。与在集中式数据中心或远在全球另一端的云中处理Cookie相比，在ADN上处理Cookie可显著提升性能。具体如图4所示。

图4

解决方案3：将Web应用的前端（例如产品目录）迁移到边缘，即实体店

许多零售商（如 Macy’s、Home Depot 和 Target）也设有实体店。消费者可在店内浏览在线商品目录，查看商品位置并获取优惠和优惠券。为改善用户体验，这些零售商可以选择仅将 Web 应用的前端迁移到店内计算环境。应用的其余组件（如数据库）可以继续保留在后端数据中心，因为这些组件的访问频率不及前端商品目录。具体架构如图 5 所示。

图 5

任何解决方案都应考虑的关键架构原则

从根本上说，这是一个跨多个异构云的分布式计算问题。DevOps团队可以选择自行构建，将公有云提供商、CDN提供商或边缘服务提供商等不同厂商的零散解决方案拼接起来；也可以购买分布式云服务平台提供商提供的打包解决方案。相关挑战如图6所示。

图 6

以下是DevOps团队在评估任何解决方案时应考虑的关键架构原则。

跨多个云的一致应用运行时环境：DevOps团队的应用将分布在后端云、边缘位置和实体门店位置。后端云可能是私有数据中心或公有云，而这些位置的应用运行时环境可能完全不同。DevOps团队应重点考虑利用Kubernetes在所有这些分布式云中提供一致应用运行时环境的解决方案。Kubernetes可统一不同云环境，让应用组件更易于在云之间迁移。
基于地理邻近性的流量路由：应用前端可能部署在不同位置，例如云端、边缘或实体店边缘。因此，任何解决方案都应确保将用户流量转发到距离最近且已部署前端服务的位置。此外，所考虑的解决方案不应要求DevOps团队更改互联网路由策略。
全局负载均衡：所考虑的任何解决方案都应提供全局负载均衡，因为后端服务可能分布在全球多个位置。
跨多个云环境的统一应用和网络安全策略：虽然应用组件的位置可能因地区而异，但所考虑的任何解决方案都应支持在前端服务所部署的任意云环境中应用统一的应用和网络安全策略。
跨多云以及应用和网络连接的统一可观测性：在分布式云环境中，对跨多个云的应用和连接问题进行故障排查极其困难。所考虑的任何解决方案都应提供统一的可观测性，以便集中查看跨多个云的连接、安全和应用部署。