无服务器服务正变得无处不在。作为向新的编程方式发展的推动力，无服务器产品正在以各种形式出现，如应用程序托管平台、无服务器数据库、CDN、安全产品等等。
　　无服务器产品消除了底层配置、可伸缩性和预置方面的问题，最后剩下的就是分发问题。边缘无服务器服务通过在多个数据中心之间分发数据和计算的方式提供了一种解决方案。边缘无服务器通过让计算更接近用户的方式减少了延迟。
　　边缘无服务器是15年前开始推出的“基础设施即服务”云架构发展的一个顶点。其下一发展阶段将是进一步推动无服务器“构件”的分发，让开发人员更容易使用它们。
　　现在让我们回顾一下它们的发展历程，并展望其未来发展趋势。

分层架构基础设施即服务（IaaS）

　　随着基础设施即服务的出现，云计算革命才算真正开始。借助IaaS，企业可以将其本地基础设施移至托管的云基础设施上并从那里进行操作。用户只需要根据他们使用的存储和计算时间付费，无需再安装或管理任何硬件或网络。
　　刚开始，IaaS的收费貌似很贵，但是企业还是很快地采用了它们。因为在保证正常运行时间上，IaaS远远超过了本地数据中心。此外，企业自己购买和维护基础设施在费用上也远远超过了IaaS产品。最重要的一个优势是，云计算消除了硬件维护和配置工作，从而解放了开发人员，使其能够更加专注于业务价值。

平台即服务（PaaS）

　　供应商将云计算服务又向前推进了一步，开始提供平台即服务。用户可以通过PaaS解决方案租用构建应用程序所需要的一切，而不仅仅是租用服务器。该方案不仅包括服务器，还包括操作系统、编程语言环境、数据库和数据库管理工具。
　　与IaaS服务提供商让用户成为租用服务器的管理员不同，PaaS服务提供商则是接管了服务器管理任务，例如软件安装或安全更新，并经常会对用户代码的环境要求进行预测。PaaS的目标是为用户提供一种简单的方法来部署他们的应用程序。PaaS将开发人员从系统管理任务中解放出来，让他们能够专注于最重要的应用程序。与IaaS相比，PaaS又向前迈进了一步。
　　在向公众提供PaaS产品的众多服务提供商中，AWS Elastic Beanstalk、Google App Engine和Heroku是其中的典型代表。

软件即服务（SaaS）

　　软件即服务通常是指可以通过各种订阅获得的在线托管应用程序。这些应用程序完全可以在云端运行，并且可以通过互联网和浏览器进行访问。从本质上说，在云端运行且定价模式采用基于订阅的所有应用程序都可被视为SaaS应用程序。
　　SaaS应用程序有两种类型：专注于终端用户的应用程序和专注于开发人员的应用程序。后一种类型旨在为其他应用程序提供一个坚实的基础。Gmail、Dropbox、Jira、BitBucket和Slack都是典型的专注于终端用户的SaaS应用程序，Stripe和Slaask还开放了API允许用戶将其SaaS解决方案集成到他们自己的应用程序中。

容器即服务（CaaS）

　　容器平台是IaaS的最新形式。CaaS服务提供商可让用户在容器中托管服务或应用程序，或是让用户自己管理容器，而不再提供完整的服务器主机。
　　与虚拟机相比，容器可更为高效地利用底层的主机资源。人们可以将容器视为“微型机器”。它们能够快速启动，并且可在单个服务器上运行多个实例。
　　CaaS服务提供商提供了一些工具，用以在服务器上部署容器以及调整容器实例的数量。最先进的产品完全可为用户管理底层服务器，让用户能够专注于代码（或容器）而不是基础设施。
　　如今，CaaS已迅速发展成为了PaaS和SaaS的一个构建模块，从而形成了一种分层的体系结构。开发应用程序工作也逐步变成了金字塔结构。由于目前可用的平台还不够灵活，无法提供应用程序所需的一切，因此许多复杂的应用程序采取的办法是综合使用SaaS、PaaS和CaaS。

　　通过尽可能地依靠SaaS，用户可以摆脱配置和可扩展性方面的顾虑。对于其余部分，用户通常会考虑运行中的容器，这意味着他们仍然需要进行预置和配置。
　　为了减少这些顾虑，人们开发出了第五种解决方案，即无服务器架构。无服务器架构填补了这方面的空白。

无服务器架构

函数即服务（FaaS）

　　在FaaS中，用户在上载和执行代码时无需考虑扩展、服务器或容器。从这个意义上讲，它们在易用性方面超越了先前的产品，不过它们也存在一些局限性。这些局限性在PaaS中不怎么明显，但是在FaaS却被放大了。
　　FaaS的最大优势是扩展。FaaS扩展的粒度比PaaS或CaaS要更出色，并且不需要配置。在收费方面，用户不使用就不付费。
　　·粒度：PaaS应用程序通常是按应用程序扩展，而基于CaaS构建的应用程序则按容器扩展。FaaS应用程序可拆分为单独的函数，因此可以按函数进行扩展。缺点是它们经常需要用户重新考虑应用程序的架构。用户必须对许多执行较小任务的函数进行管理，而不再是管理一个应用程序或几个容器，不过其中的不足是这可能会导致产生大量的编排工作。 　　·配置：用户通常需要对扩展的位置，触发扩展的时机（以进行向上和向下扩展）进行配置，以及手动设置需要运行的应用程序或容器实例的数量，FaaS则不需要用户配置扩展或预置特定的资源。
　　·按需付费：在使用容器时（CaaS），无论代码是否被主动执行，用户都需要付费。而在使用FaaS时，只有函数被调用时才会产生费用。这种按需付费的定价模式正逐渐成为无服务器定义中一个最重要的方面。
　　·限制：在典型的应用程序中，用户可以为代码定义内存限制或执行时间限制。尽管FaaS服务提供商允许用户配置这些设置，但仍有一些上限限制以确保提供商能够有效地优化这些资源。我们可以设想一下，如果函数可以使用10GB的RAM或可以运行几个小时的功能，那么提供商将很难评估出要启动多少台服务器才能最为高效地使用他们的资源。

新的边缘架构

　　无服务器架构消除了预置和扩展方面的问题，但是分发仍然是一个具有挑战性的问题。在理想的情况下，我们希望我们的代码尽可能靠近终端用户运行，以减少延迟。然而直到最近，我们在构建应用程序的方式上还存在多个问题：
　　·分发逻辑：除非用户将函数或容器部署在不同的区域，并且自己将客户端路由到最近的函数，否则用户的函数通常都保留在一个数据中心中。
　　·分发动态数据：只分发逻辑而不分发数据是无法获得巨大优势的，因为延迟会出现在不同的位置。例如，你的用户可能离后端更近，但是你的后端仍与数据层相距甚远。
　　·成本、配置和监控：一个应用程序被分布在两个或三个以上区域的情况很少见，因为这样做通常会带来额外的成本或配置，并且需要用户监控多个区域的函数或容器。
　　无服务器的下一个发展趋势是无需配置即可进一步推动分发和交付。这意味着我们的逻辑和数据将在全球许多地区被分发，并将有效地降低终端用户的延迟。

CDN和JAMstack

　　我们已经在使用自动分发的基本服务形式，被称为内容交付网络（CDN）。Netlify和Zeit等公司认为，通过尽可能多地预生成应用程序以及使用无服务器函数和SaaS API处理动态部分已经能够实现自动分发。
　　这种被Netlify称为“JAMstack”的方法正在快速普及，因为内容交付网络首先带来了边缘架构可以提供的功能。当然，JAMstack也存在一些限制，如仅可基于服务器端渲染，新流入的内容必须触发构建等。这些限制使得将这种方法应用于有着大量构建时间的高度动态的网站非常具有挑战性。

　　增量构建和诸如客户端激活之类的概念为该问题提供了部分解决方案，但是我们还是希望复杂网站同时能够具有两大优势：终端用户的延迟（极低）和新内容可立即被访问。

分布式服务的兴起

　　在我们通常使用的架构中，前端与后端进行通信，后端又与数据库和其他服务进行通信。后端和数据库通常会一起扩展，以保持后端和数据库之间的延迟处于很低的状态。分布式是有可能做到的，不过这通常很麻烦，这也使得它们受到了限制。

　　在未来的架构中，对分布式服务的使用将把JAM的理念提升到一个新的层次。这些服务中的每一个都将是一个分布式网络，其节点不一定必须与其他服务位于同一数据中心中。为了将延迟时间减少到最低，我们必须要重新考虑安全模型，以使前端能够与数据库和其他服务网络进行通信。
　　下面让我们来看看要实现这一目标需要哪些服务。

分布式服务网络

　　许多SaaS平台（如Algolia和SendGrid）旨在成为其他应用程序的构建基块。目前服务提供商已经开发出了特定的服务，以消除典型后端应用程序中的特定问题，其中一些正在发展成为分布式服务，例如Algolia（其自称为分布式搜索网络，DSN）。许多其他的Saas平台也正在紧跟这一发展趋势，预计我们很快就会对分布式服务网络是否作为SaaS应用程序的下一个发展趋势展开讨论。

分布式无服务器数据库

　　Azure Cosmos DB、Google Cloud Spanner和FaunaDB等数据库正在采用即付即用的无服务器模式，并通过某种形式的ACID保證提供现成的分发。某些数据库还提供了安全层和原生GraphQL API，这些安全层和本机GraphQL API可以由客户端应用程序安全使用，并可以与无服务器后端很好地配合使用。这些安全层使得用户界面可以直接与数据库进行交互，而不仅仅是与后端进行交互。理想情况下，前端应用程序可以与具有低延迟和ACID保证的全球分布式数据库进行通信，使用起来就像数据库在本地运行一样。

分布式无服务器边缘计算

　　Cloudflare worker和StackPath Serverless Scripting等新的无服务器函数正在将无服务器函数推向边缘，其旨在使函数尽可能接近终端用户，以将延迟降低到最低。目前，Cloudflare workers已经拥有194个服务点，StackPath也有45个以上。
　　为什么现在这种新的边缘架构越来越受欢迎呢？在我们考虑由IaaS到边缘无服务器的转型演变时，一个绊脚石一直在困扰着，即如何处理动态数据？尽管我们已经有了Amazon S3之类的服务来托管相对静态的数据，但是真实的数据库仍然难以提供良好的无服务器体验。其中的主要原因是构建高度一致的分布式系统目前依然相当困难。

　　如今，我们已经拥有了具有内置安全性的无服务器数据库，这些数据库为新型应用程序创造了条件。默认情况下，这些应用程序以全球分布式方式进行扩展。自从这扇门打开以来，许多开发人员已经开始寻求用微服务和API替换后端部分的方法，以为众多SaaS服务提供商打开新的市场。
　　这一趋势的最终成果是生态系统可以运用像Legos一样的构建模块搭建。预计不久之后，开发人员将可以组合自己所需的构建模块，而不必担心扩展或分发问题。
　　本文作者Brecht De Rooms现为Fauna公司的高级开发者布道师，其曾经在初创公司和IT咨询公司担任过全职开发人员和研究员，在IT领域有着丰富的从业经验。他的任务是阐明新兴的强大技术，让开发从员能够更容易地使用这些技术构建可吸引用户的应用程序和服务。
　　原文网址
　　https：//www.infoworld.com/article/3526480/whats-next-for-serverless-architecture.html？nsdr=true