有关云可移植性的三个考量：三事件驱动架构（EDA）和无服务器计算

在这一系列文章中，我们将从架构、设计等不同方面来探讨，在云的可移植性方面，具体都需要考虑哪些细节问题，如何最大限度避免云时代的技术锁定，充分发挥云的灵活性优势。

下文将简要探讨事件驱动架构以及无服务器计算。欢迎点击这里回顾云原生和容器技术在云可移植性方面的注意事项；或点击这里回顾微服务架构对云可移植性的重要意义。

事件驱动架构（Event-Driven Architecture，EDA）会对事件或消息做出反应并触发特定操作，但不依赖于直接的同步通信。EDA 是异步的，这样组件即可独立运行，从而提高系统在可变工作负载下的响应能力和性能。

我们可以考虑两个简单的例子：文件上传和新用户注册。这两个操作都可以通过通过同步的请求 - 响应流（例如 REST API）发生，但需要发出新请求以更新文件上传状态，或在将新用户的数据插入数据库后通过新请求触发需要执行的下一步操作。假设有一群任务运行程序正在不断地轮询消息，甚至在 “无线电静默期” 或者完全与自己无关的时间段内，它们也会不知疲倦地轮询。可想而知，如果使用了按需付费的弹性云计算资源，这种方式会造成巨大浪费。EDA 通过基于推送的方法解决了这个问题。

事件驱动系统可以按需添加或移除组件从而快速扩展，并对故障获得极高适应性，因为即便某一个组件不可用，系统依然能继续运行。EDA 也非常适合实时处理以及海量数据处理，因为组件可以对事件做出反应并在数据到达时就立即开始处理，而不需要等待收到完整的数据集。

为何要使用 EDA？

• 增强系统灵活性：事件驱动架构松散耦合的特性使得我们可以轻松修改、添加或移除组件而不影响整体系统，从而让系统能够适应不断变化的需求。
• 提高可扩展性：EDA 支持非常方便的水平扩展，借此，企业可以根据需要添加更多组件或服务实例，从而应对增加的工作负载或流量。
• 提高系统弹性：EDA 的异步通信以及解耦的组件有助于提高容错能力，因为一个组件的故障并不一定导致整个系统中断。
• 实时处理能力：EDA 能实时处理大量数据和复杂的事件模式，因此很适合需要立即获得洞察力或对快速变化的情况快速做出反应的业务场景。
• 优化资源使用：通过仅在事件发生时对其做出反应，EDA 有助于优化资源利用率并减少对持续运行流程的需求，从而帮助企业节约成本，提高效率。

云原生无服务器计算

EDA 同样支持类似无服务器计算这样的应用程序开发模型，这样我们就可以编写可移植，并且与特定供应商无关的代码，从而根据功能、支持的语言、成本等因素灵活选择适合自己的云供应商。函数即服务（Functions-as-a-Service，FaaS）是一种流行的产品，很多云供应商都已提供，用户可以通过这类产品在一个位置管理函数和应用程序基础设施。云供应商作为责任人，主要负责处理底层基础设施，包括服务器的配置、缩放和维护，这样开发者就可以更专注地编写代码。

很多流行的 FaaS 服务（例如 AWS Lambda、Azure Functions 以及 Google Cloud Functions）就是我们所说的平台原生服务。它们通常会限制用户只能使用特定云提供商的平台，无法轻松迁移至其他平台。Akamai 曾多次介绍过，Knative 是一种开源、基于 Kubernetes 的无服务器运行平台，只需几秒钟即可将应用程序从 0 个副本扩展到 N 个副本。扩展到 0 个副本这种能力非常实用，可以让 Kubernetes 和 Knative 按需重新分配资源。

我们只需要使用一段代码即可自动扩展资源，因为这种代码可以并行调用多次。从本质上来看，并不建议使用上文提到的平台原生 FaaS 产品，因为这类服务的费用是不可预测的。但如果通过托管的 Kubernetes 服务在我们的计算实例上运行 Knative，用户就只需要支付一个固定并且可预测的费用，而不必担心某些服务的免费额度用完后开始按照执行次数计费。

为何使用无服务器？

• 成本效率：无服务器计算按用量付费的定价模型有助于节约成本，企业只需要为自己实际使用的计算时间付费，无需提前分配资源。
• 提高可扩展性：无服务器计算可以自动扩展资源以满足需求，确保应用程序可以顺利处理激增的工作负载而无需人工介入或停机。
• 降低运维开销：对于无服务器计算，云提供商负责管理底层基础设施，这样 IT 团队就能更专注于应用程序的开发、创新，以及其他战略性活动。
• 更快的上市时间：无服务器计算简化的开发和部署流程有助于企业更快速发布新功能、更新以及 Bug 修复，从而增强自己的竞争优势。
• 灵活性和适应性：无服务器计算使得企业能够使用各种编程语言和技术构建并部署应用程序，从而更易于适应需求的变化或按需融入新技术。

正如上文所说，无服务器计算基于事件驱动架构，这意味着函数可以由 HTTP 请求、文件上传、数据库更新等事件来触发。这有助于简化应用程序架构并改善可扩展性。

无服务器函数的世界也应该是无状态的。函数在不同调用之间不存储任何数据或状态，这保证了函数可以轻松扩展，并且函数故障后可以轻松替换。函数还应当是短暂的，这保证了资源不会被浪费，并且函数能够快速扩展。如果一个函数的任务需要长时间运行，则需评估是否更适合使用持续运行的服务来代替。

无服务器函数同样需要监视并记录日志，这样才能确保函数按照预期运行，同时发现可能存在的任何问题或错误。为此可以使用一些日志聚合器和应用程序性能监视（APM）工具，例如 Prometheus 和 Grafana。另外，别忘了通过身份验证、认证授权、加密等最佳实践措施保护函数，这样不仅可以保护应用程序本身，也能保护敏感数据。在将函数部署到生产环境之前，请进行完善的测试，从而确保函数能够按照预期运行并且不存在漏洞。

无服务器计算极具成本效益，但为了进一步降低成本提高效率，依然需要使用各种成本优化技术，例如函数优化、资源共享以及自动扩展。用户有必要评估自己的工作负载、使用模式以及需求，从而决定对于自己的特定用例来说，无服务器计算是否是一种具备成本效益的方式。另外，对于选择使用的无服务器平台，还需要考虑预期使用模式、性能需求以及定价结构。