译者|徐磊审稿人|云计算的演进也列举了一些现在已经转向无服务器模型的用例。在本文中，我们将进一步阐述如何实现Serverless，以及在实现过程中会遇到的挑战。最后，本系列将总结论点和愿景。挑战转向更纯粹的无服务器世界将解决运行现代工作负载的许多问题，但也存在许多挑战。在本文中，我们将这些挑战分为四大类：云优化、服务设计、功能和工作流以及安全问题，并分别进行讨论。在每个类别中，我们列出了需要彻底解决的重要具体问题。虽然并不全面，但我们坚信这些将成为无服务器社区计划电路的基石。挑战总结类别挑战应对挑战需要改进云优化减少分配和释放计算资源的开销需要改进云系统组件（主要是Kubernetes）的设计减少服务延迟需要改进云系统组件的设计（主要是Kubernetes）支持用于暂停工作节点需要对使用的资源进行碎片整理（需要KNative和Kubernetes支持）服务设计外部化服务流事件需要服务设计支持事件驱动的处理延迟问题需要服务设计考虑事件风暴、概率事件减少和事件不可用的延迟处理需要云系统（Knative）设计和相关服务设计考虑支持功能和工作流服务标准化需要社区满足行业标准不同服务的工作流通用描述需要完整的工作流语言安全问题更多权限自动从用户本地过渡到云端云计算需要在保护潜在易受攻击的服务方面发挥更积极的作用工作负载的细粒度分类扩大了攻击面网络边界消失增加安全消息监控（Knative、Kubernetes）云计算优化Serverless适用于为服务需求分配计算资源，在服务需求增加时分配新的计算资源，在需求减少时释放相关资源计算资源.这里分配和释放计算资源的开销可能是无服务器应用程序部署后出现的最重要的问题之一。Serverless服务（无论是函数、容器还是运行工作流的容器组）都会产生减少和回收计算资源的成本，而且这个成本的数额可能相当可观，因为它实现了Serverless服务生命周期的各个方面。包括Kubernetes在内的大多数云技术在设计时都考虑到了服务资源的配置。在Serverless模式下，需要考虑通过减少运行实例变化带来的开销来优化更多动态用例。例如，Kubernetes添加一个pod副本必须通过最小化开销来优化，以便每次服务需求变化时成本和能源消耗最小化。另一方面，我们需要关注因应需求增长而增加计算资源所带来的服务延迟。在等待分配额外资源时，这可能会导致服务延迟增加。在极端情况下，当请求到达尚未分配资源的服务时，冷启动时间会导致请求受到显着影响。正如Knative减少冷启动时间中所讨论的，最坏情况下的服务启动时间以秒为单位，而请求响应时间通常为数十毫秒。当您创建由多个独立扩展组成的无服务器解决方案时，冷启动的影响非常显着，必须加以考虑。这个问题的进一步改善需要云技术的更多优化。最后，需要对KUbernetes和Knative进行优化，以充分发挥其解决能源和资金节约的潜力。Pod分配和集群控制应该发展到支持对其他工作节点的一个子集进行动态调整（碎片整理），以便空闲节点可以暂停，当然当集群资源的总体需求增加时可以恢复。服务设计当您创建无服务器应用程序或解决方案时，主要挑战之一是使用事件驱动的思维方式设计应用程序和服务，即了解应用程序上运行的事件以及整个解决方案的各个部分.这些事件来自您对应用程序域的业务理解，必须显式提取。比如在一个业务流程的应用中，比如：假期预订系统，有明确的事件来驱动整个应用的使用。当客户计划假期时，他们必须依次选择和预订一系列选项，如地点、航班、酒店、租车、餐饮和其他活动。整个过程可以分解为服务和在它们之间流动的事件。企业将其应用程序设计为微服务。这种分解和设计也是众所周知的。无服务器事件驱动架构只是将事件（内部或外部）触发器添加到不同的服务中，如果它们不处理任何请求，则可以减少为零。为了充分利用此架构，必须将驱动服务的事件外部化，以便这些事件可用于触发无服务器组件网络中的工作流。由于服务可以动态扩展，前面提到的问题之一是需要考虑冷启动的潜在影响，还需要一个良好显示和快速响应的用户界面。事件驱动架构也有自己的一系列必须解决的挑战，其中大部分可以通过选择正确的事件委托、触发器和事件模型来解决。并且您的应用程序的某些部分还需要注意一些陷阱，尤其是事件风暴或事件可能会在一段时间后减少或不起作用的问题。以上就是我们所说的无服务器设计。函数和工作流当AWS在2014年推出其Lambda服务时，它引入的第一个模型是纯函数式编程模型。服务被实现为各种语言和库中定义的函数。后来Knative提出了更通用的模型：以容器为中心，像Lambda函数一样，基于事件触发执行，资源规模随着服务需求（requests）的变化而增减。随后，Knative适时推出了自己的函数式编程模型：Knativefunctions。不同Serverless技术的共存虽然对创新有很大帮助，但毕竟没有标准，它们是不兼容的，兼容性挑战是在网络边界解决的。首先，容器镜像的格式和执行由Kubernetes社区定义。最重要的是，很多Serverless平台的事件模型都是基于云事件标准，这是一个非常重要的标准。它允许工作负载跨云协作、协作和执行。Kubernetes提供了一个通用的执行平台，以及我们所需要的Serverless在这个平台上的通用定义。最后一个挑战是对无服务器服务之间协调流程的一般描述。创建一个简单的无服务器解决方案不仅需要触发器、事件源和来自不同服务的事件聚合，还需要不同服务之间的协调。各种流程语言都有部分解决方案，即流水线语言，但它不是为任意复杂的带有同步点的图而设计的，需要一个完整的工作流语言。这种语言可能是Tekton的演变，或者至少是它的超集。每一项新技术都伴随着安全问题，新的网络安全挑战也随之而来。Serverless技术的出现改变了这种格局，因为更多的控制权从客户端转移到云端自动化，尤其是控制计算资源在何处以及使用多少来满足需求。结果，许多相关的安全控制随着网络边界的消失而消失。此外，随着Serverless带来的低成本和简化操作，很多工作负载将被拆分成更细的自助服务，随着工作负载碎片越来越多，攻击者也将看到更大的攻击面。Knative社区应对新的网络安全挑战的措施提高了已部署服务的更新效率和速度。Knative提供了辅助服务纠错的基础功能，支持服务纠错时的流量切分，使得服务可以在修改版本中迭代。期间可以平稳无风险的过渡。支持更频繁的更新，以降低不断变化的威胁和新发现的漏洞带来的风险。避免任意服务配置Knative自动化部署确保服务所需的所有Kubernetes资源都来自单一服务资源。违规者或内部人员对任何资源的手动修改，无论是有意还是无意，都会被Knative自动覆盖，避免随意修改配置。避免任意基础设施配置Knative使用Kubernetes辅助管理Knative的底层组件，但不支持手动更改Serverless的基本设置。监控和控制安全行为Knative社区正在引入新技术来监控已部署服务的行为以及发送到这些服务的事件的行为。SecurityGuard是为每个服务定制的运行时安全保障，用于保护易受攻击的服务免受0-day或已知漏洞的侵害。该技术还为您提供了防止服务被利用的机制。总结随着云计算的不断发展，它已经成为全球能源消耗的重要参与者。据国际能源署估计，2021年已占全球能源消耗的1-1.5%，二氧化碳排放量的1%！Kubernetes标准化了工作负载的部署和管理方式。而Knative在Serverless和高效率方面更进一步。有助于实现更环保的云计算，为云服务提供商和云用户节省大量成本。这种无服务器模式适用于所有工作负载。更高的效率不仅适用于单个工作负载，还适用于底层云资源和执行每个工作负载所消耗的能源。除了效率之外，无服务器还为云用户带来了其他额外好处，包括简化、自动化、版本修订管理和改进的网络安全性。然而，这些也存在挑战。Kubernetes需要根据实际负载进一步优化自动扩展服务的动态特性。要使Serverless更通用并覆盖更多用例场景，还有很多工作要做。同样为了使用Serverless模式，用户还必须改善他们的工作量和部署策略，当然这些都需要时间。随着我们逐渐转向Serverless模式，我们还需要考虑适用的新工作负载和用例场景。AI、数据和机器学习社区率先认识到这种按需计算资源模型的价值，Kubeflow和Tekon是在无服务器模型中设计和执行数据密集型AI管道和工作负载的好例子。其他面向未来的工作负载和用例场景包括量子无服务器，通过它可以在量子计算机上按需使用或执行量子算法。Serverless模型代表了资源分配的成本节约和经济性，应用程序就是为此而设计的，平台对于运行Serverless解决方案也是高效和经济的，因此对各方都有意义。作为一个额外的好处，它对环境也有好处。致谢感谢PaulSchweigert和LionelVillard的反馈和评论。此外，我还要感谢整个Knative社区为创建Kubernetes的Serverless平台所做的贡献和努力。在不到两年的时间里，社区已经发布了十几个版本，改进了各个方面，并与Kubernetes保持了相同的关系。兼容并允许扩展和试验各种创新。译者介绍徐磊，社区编辑，某知名电商技术副总监，专注于Java后端开发、技术管理、架构优化、分布式开发等领域。原标题：Howdowemakethefutureserverless?，作者：MichaelMaximilien、DavidHadas、AngeloDanducciII、SimonMoser
