Serverless边缘计算架构概述

1、 Page * MERGEFORMAT 12Serverless边缘计算架构概述新的边缘架构兴起，Serverless 的发展方向在哪？ 目 录 TOC o 1-3 h z u HYPERLINK l _Toc44432609 1.分层架构 PAGEREF _Toc44432609 h 3 HYPERLINK l _Toc44432610 基础设施即服务(IaaS) PAGEREF _Toc44432610 h 3 HYPERLINK l _Toc44432611 平台即服务(PaaS) PAGEREF _Toc44432611 h 3 HYPERLINK l _Toc44432612 软件即

2、服务(SaaS) PAGEREF _Toc44432612 h 4 HYPERLINK l _Toc44432613 容器即服务(CaaS) PAGEREF _Toc44432613 h 4 HYPERLINK l _Toc44432614 2.Serverless 架构 PAGEREF _Toc44432614 h 5 HYPERLINK l _Toc44432615 函数即服务 (FaaS) PAGEREF _Toc44432615 h 6 HYPERLINK l _Toc44432616 3.一个新的边缘架构 PAGEREF _Toc44432616 h 7 HYPERLINK l _T

3、oc44432617 CDNs and Jamstack PAGEREF _Toc44432617 h 7 HYPERLINK l _Toc44432618 分布式服务的兴起 PAGEREF _Toc44432618 h 8 HYPERLINK l _Toc44432619 分布式服务网络 PAGEREF _Toc44432619 h 10 HYPERLINK l _Toc44432620 分布式 serverless 数据库 PAGEREF _Toc44432620 h 10 HYPERLINK l _Toc44432621 分布式 serverless 边缘计算 PAGEREF _Toc4

4、4432621 h 11Serverless 服务无处不在。Serverless 编程方式的演变背后的驱动力来自各种形式，包括应用程序托管平台、 Serverless 数据库、 CDN 、安全产品等。Serverless 产品消除了底层配置、可伸缩性和维护方面的问题，剩下的就是分发问题了。这里，边缘 serverless 通过在多个数据中心之间分布数据和算力来提供解决方案。边缘 serverless 通过让计算更靠近用户来达到减少延迟的目的。边缘 serverless 是从云架构发展而来，始于大约 15 年前的基础设施即服务那个时期。这种演变的下一个阶段将是进一步推动 serverless “

5、构建块”的分布，并使它们更容易为开发人员所使用。接下来，让我们将介绍 serverless 已经实现的功能以及下一步的发展方向。分层架构基础设施即服务(IaaS)随着“基础设施即服务(Infrastructure-as-a-Service.)”的出现，云计算革命正式开始。使用 IaaS，公司可以将其本地基础设施移动到托管的“云”基础设施上，并在那里进行操作。只需要支付使用的存储空间和算力的费用即可，不需要安装或管理任何硬件或网络。起初，IaaS 看起来很昂贵，但公司很快采用了它，因为 IasS 稳定性更强，而且购买和维护自己的基础设施的价格往往超过购买 IaaS 的价格。最重要的优势是，使用云

6、免去了硬件配置和维护的精力，这使开发人员可以专注于业务价值。平台即服务(PaaS)厂商们随后将云计算进一步改进，提供了“平台即服务(Platform-as-a-Service)”。Paas 解决方案不是只租用服务器，而是租用构建应用程序所需的所有东西。这不仅包括服务器，还包括操作系统、编程语言环境、数据库和数据库管理工具。IaaS 供应商让你成为租用服务器的管理员，PaaS 供应商却接管了服务器管理任务，比如软件安装或安全更新，并经常试图预测代码的环境需求。Paas 的目标是为您提供一种部署应用程序的简便方法。比 IaaS 更具优势的是，PaaS 将开发人员从系统管理任务中解放出来，使他们能够

7、专注于最重要的东西应用程序。Aws Elastic Beanstalk、 Google App Engine 和 Heroku 都是向公众提供 PaaS 的供应商。软件即服务(SaaS)软件即服务 (Software-as-a-Service) 通常是指可通过各种订阅获得的在线托管应用程序。这些应用程序完全在云端运行，可以通过互联网和浏览器访问。从本质上讲，每个运行在云中并具有基于订阅的定价模型的应用程序都被认为是 SaaS 应用程序。有两种类型的 SaaS 应用程序: 侧重于最终用户的应用程序和侧重于开发人员的应用程序。后一种类型旨在为其他应用提供基础。和 Slack 都是针对终端用户的 S

8、aaS 应用的例子，而 Stripe 和 Slaask 则提供了接口，允许用户将他们的 SaaS 解决方案整合到自己的应用中。容器即服务(CaaS)容器平台是 IaaS 的最新化身。Caas 提供者让您在容器中托管服务或应用程序，并代替你管理容器，而不是提供成熟的服务器主机。容器在利用底层主机资源方面比虚拟机更有效率。人们可以把容器想象成“微型机器” 它们启动迅速，并且允许多个实例可以在单个服务器上运行。Caas 提供者提供了一些工具，用于在服务器上部署容器以及上下调整容器实例的数量。最大的优势是完全帮你管理底层服务器，允许您的公司专注于代码(或容器) ，而不是基础设施。Caas 已经迅速成为

9、 PaaS 和 SaaS 的构建模块之一，从而形成了一种分层架构。开发应用程序已经向金字塔上尽可能高的位置转移。因为现有的平台不够灵活，无法满足应用程序的所有需求，所以许多复杂的应用程序仍然需要将 SaaS、 PaaS 和 CaaS 组合到一起使用。 许多复杂的应用程序是 SaaS、 PaaS 和 CaaS 的结合体。通过尽可能多地依赖 SaaS，你可以从配置和可伸缩性问题中解脱出来。对于其余部分，公司通常采用正在运行的容器，这意味着他们仍然需要考虑配置。为了减少这些担忧，第五个产品问世来填补空白，于是 Serverless 架构便诞生了。Serverless 架构函数即服务 (FaaS)Fa

10、as 允许您上传和执行代码，甚至不需要关心扩容的事情，也不需要关注服务器或容器。从这个意义上说，它更易用，但它也有一些限制，这些限制在 PaaS 中不那么突出。Faas 的最大优势是可扩展性。扩展 FaaS 可以在比 PaaS 或 caa 更低的粒度上完成，并且不需要配置。而且，你不需要为你不使用的东西付费。粒度: PaaS 应用程序通常只能扩展到每个应用程序，而基于 CaaS 构建的应用程序只能扩展到每个容器。Faas 应用程序被分解为独立的函数，因此是函数级别的粒度。缺点是，它通常需要你重新思考应用程序的体系结构。与管理一个应用程序或几个容器不同，许多执行较小任务的函数必须被管理，这会引入

11、大量编排工作。配置: 你通常会配置何时进行伸缩 (触发器进行伸缩) 或手动设置需要运行的应用程序或容器的实例数量，FaaS 就不需要你配置伸缩或提供特定的资源。现收现付：与部署容器(CaaS)不同，方法只在被调用时产生费用。这种现收现付的定价模式正逐渐成为 serverless定义的最重要方面限制: 在一个典型的应用程序中，你可以为代码设定内存限制或执行时间限制。尽管 FaaS 提供程序允许你配置这些资源，但是有一些会设置一些上限来确保提供程序能够有效地优化这些资源。可以想象，如果一个服务提供商可以用10GB 的内存创建函数，或者一个函数要运行几个小时，那么他们就很难估计需要多少服务器才能最大

12、限度地利用其资源。一个新的边缘架构Serverless 架构消除了维护和扩展方面的顾虑，但是分发仍然是一个具有挑战性的问题。理想情况下，我们希望我们的代码尽可能靠近最终用户运行，以减少延迟。迄今为止，我们构建应用程序的方式存在多种问题:分布逻辑: 除非您将函数或容器部署到不同的区域，并自己将客户机路由到最接近的方法，否则方法通常会保留在一个数据中心中。分布动态数据: 分布逻辑而不分布数据不会获得巨大的回报，因为延迟刚刚移动到不同的位置。你的用户可能更接近后端，但是你的后端仍然远离数据层。成本、配置、监视: 很少看到一个应用程序分布到两个或三个以上的区域，因为这样做通常会带来额外的成本或配置，并

13、要求您监视多个区域的功能或容器。serverless 的下一个发展趋势是进一步推动发行版，并在不需要配置的情况下交付它。这意味着我们的逻辑和数据分布在全球许多地区，以降低最终用户的延迟。CDNs and Jamstack我们已经使用了提供自动分发服务的最基本形式，它被称为内容传递网路分发服务，或 CDN。Netlify 和 Zeit 等公司的一些聪明人认为，通过尽可能多地预先生成应用程序，并处理具有 serverless 方法和 SaaS 接口的动态部分，已经可以实现自动分发。这种方法被 Netlify 称为“ Jamstack” ，由于内容交付网络首次尝试了边缘架构所能提供的东西，这种方法迅

14、速得到了普及。当然，对于纯粹基于服务器端呈现的 Jamstack 也有一些限制。例如，构建必须为新的传入内容触发。这使得将这种方法应用于高度动态的网站变得非常具有挑战性，因为这些网站需要大量的构建时间。 基于服务器端渲染的Jamstacks面临着高度动态的网站的挑战，因为必须为新内容触发做建设。增量建设和客户端激活 提供了这个问题的部分解决方案，但最终，我们希望我们的复杂网站具有两方面的优势: 最终用户的延迟低，并且可以立即访问新内容。分布式服务的兴起我们所处的架构是前端与后端通信，而后端又与数据库和其他服务通信。后端和数据库通常一起进行伸缩，以保持后端和数据库之间的延迟较低。可以分发，但往往

15、是繁琐的，因此非常有限。 后端和数据库的分发虽然可行，但往往是麻烦的，因此非常有限。在未来的体系结构中，通过使用其他分布式服务将 Jamstack 的思想提升到一个新的水平。这些服务中的每一个都将是一个分布式网络，其节点不必像其他服务一样生活在同一个数据中心中。为了将延迟减少到最小，必须重新考虑安全模型，以便前端能够与数据库和其他服务网络通信。 未来的应用架构将充分利用分布式服务网络、分布式数据库/服务网络和分布式serverless后端。接下来，让我们来看看那些有助于实现这一目标的服务。分布式服务网络许多 SaaS 平台，如 Algolia 和 SendGrid，旨在成为其他应用程序的基石。

16、他们开发特定的服务，从典型的后端应用程序中移除特定的关注点。其中一些正在演变为分布式服务，比如 Algolia，它自称为分布式搜索网络(Distributed Search Network，DSN)。很多其他的 Saas 平台也会跟进，很可能我们很快就会谈到分布式服务网络作为 Saas 应用程序的下一个发展方向。分布式 serverless 数据库Azure Cosmos DB、 Google Cloud Spanner 和 FaunaDB 等数据库正在采用现收现付的无服务器模式，并提供某种形式的 ACID 保证的开箱即用分发。一些数据库提供了安全层和原生的 GraphQL 接口，客户端应用程

17、序可以安全地使用这些 接口，并且这些接口可以很好地处理 serverless 后端。安全层使用户界面可以直接与数据库交互，而不仅仅是与后端交互。理想情况下，前端应用程序可以与全局的分布式数据库 / 服务器通信，具有较低的延迟和 ACID 保证，几乎就像数据库在本地运行一样。分布式 serverless 边缘计算新的 serverless 方法平台，如 Cloudflare workers 和 StackPath Serverless Scripting，正在将 serverless 方法推向极限。他们的目标是尽可能接近最终用户的功能，以减少延迟到绝对最小。Cloudflare workers 有 194 节点，而 StackPath 有 45 个以上。为什么这种新的边缘架构现在正在不断获得关注的目光？当我们考虑从 IaaS 到边缘 serverless 的转变时，一个绊脚石总是阻碍我们: 如何处理动态数据？尽管我们有像 Amazon S3 这样的服务来承载相对静态的数据，但是真