利用无服务器技术优化应用程序开发
优化应用程序开发的机会
虚拟机 (VM)、容器和公共云等创新在许多方面改善了应用程序的开发，但一些配置、维护和优化决策仍然由开发人员而非技术来负责。
开发人员身上担负的这类责任越多，就越没有时间构建产品和内部应用程序。不幸的是，许多广泛采用的技术还要开发人员负责性能优化、应用程序扩展、安全补丁、负载平衡等任务。这些责任带来了次优选择或错误风险，可能大大减少预算或导致漏洞和停机。
这种低效方式导致了严重的后果。开发人员花在非编码任务上的时间每年给组织造成的损失超过 850 亿美元，令人震惊。
因此，消除应用程序开发的复杂性可以改善开发人员的体验，同时为组织节约大量资金。
行业向无服务器转变
无服务器技术旨在解决这些问题，特别是通过减轻开发人员的负担来改善应用程序的开发。然而，并非所有无服务器平台都能产生同样的效果。无服务器平台在早期迭代过程中，继承了许多与其底层技术（即容器）、地区和公共云相关的配置、可扩展性和性能问题。
因此，我们今天所知的“无服务器”往往是在旧模式基础上的抽象泄漏。
先进的无服务器平台改进了几个重要的架构，让这些问题成为过去式。这些改进消除了开发过程中非常耗时的决策，因此团队可以将更多时间用于构建伟大的产品和应用程序。
基于之前的开发方法
在无服务器之前，使用的方法有虚拟机和容器。虚拟机是基于软件的计算机，存在于另一台计算机的操作系统中，而容器是标准软件单元，其中容纳了应用程序运行所需的所有元素。
这两种技术都能让开发人员更加专注于应用程序，而非管理硬件。然而，虚拟机和容器仍然让开发人员承担管理和配置的职责，拖慢了整个开发过程。
虚拟机和容器都在不同程度上要求开发人员及其合作伙伴的 IT 和安全团队：
管理安全补丁以及身份和访问管理 (IAM) 权限
配置负载平衡和网络
确保可用性并引入冗余
Kubernetes 等容器编排系统减轻了许多与容器有关的配置要求，包括管理规模和冗余。然而，开发人员运营 (DevOps) 团队需要具备 Kubernetes 专业知识才能有效管理，但他们专注于解决内部开发问题而不是面向客户的问题。如果没有 Kubernetes 和经过适当培训的团队，还是无法解决容器的局限性。
虚拟机和容器只是开发中的一部分。这两种技术都可以在公有云中使用，这就引入了公有云自身的局限性。
公有云有助于简化开发的各方各面，但仍将各层配置交由客户负责，例如选择地区、管理安全策略、设计网络解决方案和确保可用性。公共云还需要手动组合多种服务，例如数据库、消息队列和存储。手动配置和连接这些服务非常费时，增加了总体部署时间。
第一代无服务器开发效率低下
无服务器开发旨在克服与虚拟机、容器和公共云相关的挑战。但是，早期的无服务器方法只取得了部分成功。
第一代无服务器开发的主要挑战包括：
延迟和可扩展性。许多此类无服务器平台在公共云中运行，公共云依靠中心化的数据中心来降低管理成本。这种模式要求客户选择部署地区，即实际存储客户资源的地区。数据中心化会导致延迟，因为代码在远离最终用户的地方运行。此外还可能在多个地区进行扩展和部署，但配置起来会很复杂。
冷启动和 CPU 限流。构建在容器上的无服务器平台难以解决冷启动和中央处理器 (CPU) 限流问题。冷启动是指第一次执行无服务器函数时发生的加载延迟。之所以会发生冷启动，是因为容器可能需要几秒钟时间预热。另一方面，当平台达到其指定的无服务器实例限制并延迟请求时，会发生 CPU 限流。
开发人员经验不足。开发人员往往需要管理耗时的任务，例如设置编排模板、按大小将应用程序分类和确定内存阶层。这些任务导致可能发生代价高昂的错误，减少了开发人员用于编码的时间，久而久之将给组织造成损失。
可观察性不足。许多无服务器开发平台难以监控，因为它们没有提供足够的可观察性。可观察性是指一个组织能在多大程度上通过性能指标、事件日志等了解分布式系统中的运行情况。如果没有足够的可观察性，组织就无法高效诊断和修复无服务器应用程序中的问题。
无状态的性质限制了应用程序的功能。第一代无服务器平台实际上是无状态。无状态的性质有助于解决可扩展性，但会使平台难以构建需要强一致性或多个客户端实时协调的应用程序，例如互动聊天、视频游戏或协作编辑工具。
成本。许多云无服务器平台需要支付额外的费用，且通常是隐形费用，例如 API 网关费或容器保温费。因此，使用这些第一代平台构建应用程序可能成本高昂，特别是达到一定规模时。
无服务器运动一直旨在简化应用程序开发过程，但在中心化公共云上运行的无服务器平台并没有完全兑现 这一承诺。
重新思考无服务器：无服务器的改进
新一代无服务器开发平台克服了早期产品的许多缺点。通过不依赖容器和公有云等传统基础设施，这些解决方案在多个方面获得了改进，将时间还归开发人员。
这些改进包括：
在网络边缘运行。最先进的无服务器平台是在“边缘”运行，边缘是由许多数据中心组成的分布式网络。网络越大，解决性能和可扩展性问题的能力越强。因为在边缘网络中，计算发生在最接近终端用户的入网点。这种分布式方法降低了延迟，与公共云中在中心化地区计算完全不同。因此，将代码部署到由数百个数据中心组成的网络中，比部署到由 20 个数据中心组成的网络中性能更好。最先进的边缘平台将提供较长的 CPU 运行时间来构建复杂的工作负载。
使用隔离而非容器。这种方法消除了基于容器的架构存在的问题——冷启动和 CPU 限流，缓解这些问题的成本高昂。与容器不同，隔离不需要保温，所以不存在冷启动的问题。而且隔离消耗的内存较少，降低了开销，解决了 CPU 限流的问题。
前期决策减少。一些较新的边缘无服务器平台会自动优化应用程序，提高性能和安全性。而且，全球边缘网络解决方案不要求开发人员选择托管工作负载的地区，因为它们会将代码部署到网络上的所有数据中心。没有了这些繁琐的任务，开发人员的体验也得到改善。
详细的分析和记录。早期的无服务器平台没有提供太多的分析、调试或记录功能，而先进的边缘无服务器平台的可观察性更高。开发团队可以利用详细的分析和记录，更轻松地收集所需信息来排除问题。此外，有些平台集成了更复杂的监控工具，开发更复杂的应用程序时可能需要这些工具。
集成协调和存储。这一特性使得无服务器的有状态架构成为可能。有状态的架构需要持续的数据存储，无状态的应用程序则不然，其中的数据是暂时的。如果没有有状态的架构，就不可能创建互动、实时的应用程序。
具有成本效益。与以前基于容器的解决方案相比，基于轻量级隔离的边缘无服务器平台成本更低。隔离架构可提供与云计算相关的可扩展性和灵活性的所有好处，但没有隐形费用和成本飙升。
通过这些改进，下一代无服务器平台优化了整个应用程序的开发过程；消除了繁琐的任务，让开发人员能够保持专注，同时为组织节约成本。
使用 Workers 优化应用程序开发
合适的无服务器平台消除了可扩展性限制，同时减轻了开发人员的负担，提高了应用程序开发过程的整体效率。Cloudflare Workers 是一个基于边缘的无服务器平台，使用智能基础设施为开发人员减少了许多前期决策工作。凭借 Cloudflare 的基础设施，构建在 Workers 上的应用程序在安全性、性能和可靠性方面始终可得到优化。
由于 Workers 在全球 Cloudflare 网络上运行，覆盖 100 多个国家/地区的 200 多个城市，因此可扩展性从来不是问题。代码会自动部署到所有地区，不需要额外的费用或配置。开发团队可以通过使用 Workers Unbound 在边缘构建需要较长 CPU 运行时间的高级应用程序。由于 Workers 平台在隔离环境而不是容器上运行，因此不存在冷启动或 CPU 限流的问题。Workers 内置可观察性，与更先进的监控工具集成（例如 New Relic 和 Sentry)，此外还通过 Workers 命令行界面 (CLI) 提供调试和日志工具。耐用对象为 Workers 平台提供了低延迟的协调和一致的存储，可以开发有状态的无服务器应用程序。同时，Workers 通过消除隐形费用，提供行业领先的价格，为客户节约了资金。
Workers 让开发团队能够专注于构建产品而非维护和配置，改善了开发人员的体验，长期也可让公司获得财务效益。
Cloudflare 就影响当今技术决策者的最新趋势和主题发布了系列文章，本文为其一。
关键要点
阅读本文后，您将能够了解：
低效的开发架构存在哪些风险
开发方法的发展如何引领我们进入无服务器时代
早期的无服务器迭代并未简化应用程序的开发
下一代无服务器的关键区别