本文介绍 Microsoft 商业软件工程 (CSE) 团队如何与一家全球零售商合作，使用 Serverless Framework 在 Azure 和 Amazon Web Services (AWS) 云平台上部署高度可用的无服务器解决方案。
体系结构
下载此体系结构的 Visio 文件。
数据流
- 用户应用可以来自任何能够登录到云的源。 在此实现中，用户登录到网关应用，该应用在 Azure 和 AWS 云之间对请求进行 50-50 的负载均衡。
- 任何响应也会通过 API 管理器网关进行路由，然后该网关会将其发送到请求者应用。
组件
Serverless Framework
此解决方案使用 Serverless, Inc 提供的 Serverless Framework。免费版本的 Serverless Framework 包括 CLI、其他插件和有限的监视服务。 专业版具有跨云操作功能，例如增强监控和警报。 该框架支持 Node.js 和 Python 语言，以及 AWS 和 Azure 云主机。
若要将 Azure 与 Serverless Framework 配合使用，需要：
- Node.js，打包微服务
- Azure Functions，提供与其他云平台类似的功能
- Serverless Framework，支持多云部署和监控
- 无服务器多云库，为开发人员提供规范化运行时 API
- Azure Functions 无服务器插件，支持多云部署。 此插件最初就与同类插件 AWS Lambda 不一样，并且已针对此项目扩展。
下图显示了处理管道。 中间件层表示到达处理程序之前所需的任何中间功能。
与云无关的 API
每个平台上的无服务器实现都支持将单个功能作为微服务，每个对应一个功能 VM 节点，并根据需要执行处理。 每个 AWS Lambda 函数都有相应的 Azure Functions 函数。 无服务器多云库将类似微服务从任一云构建到与云无关的规范化 REST API 中，客户端应用可用于与任一平台交互。 由于抽象 API 层提供代码来处理每个平台的相应微服务，因此不需要转换事务。 与云无关的界面允许用户应用与云交互，而无需知道或关注其访问的云平台。
下图演示了此概念：
将 CI/CD 与 GitOps 一起使用
Serverless Framework 的主要工作是抽象出将应用部署到云的所有基础结构问题。 Serverless Framework 通过使用基于清单的方法，可以处理所有部署问题，从而允许根据需要自动进行部署以支持 GitOps。
尽管此初始项目使用手动部署，但在云中或跨云实现清单驱动的无服务器生成、测试和部署是实际可行的。 此过程可以使用 GitOps 开发人员工作流：从 Git 生成、使用质量门槛进行测试和评估，以及将无服务器解决方案推送到两个云提供商。 从项目一开始就使用 Serverless Framework 进行所有部署是最有效的方法。
API 管理器
API 管理器可以是现有或自定义应用程序。 在此实现中，Apigee™ API 管理器仅充当路由器，为两个云平台提供 50-50 事务负载均衡，并且其功能未充分利用。
API 管理器必须能够：
- 根据需要在云平台内部或外部部署
- 将消息路由到两个云平台以及从两个云平台路由消息
- 记录流量请求以协调异步消息流量
- 使用通用 REST API 将请求和响应中继到用户应用程序
- 监视两个云无服务器框架部署的运行状况，以验证其接收请求的能力
- 在每个云平台上执行自动运行状况和可用性检查，支持路由和高可用性
备选方法
其他语言（如 Python）可以实现该解决方案，只要它们受到云平台的无服务器实现的支持，这里指 AWS Lambda 和 Azure Functions。 此项目使用 Node.js 打包微服务，因为客户对其感到满意，并且 AWS 和 Azure 平台都支持 Node.js。
该解决方案可以使用任何支持 Serverless Framework 的云平台，而不只是 Azure 和 AWS。 目前，Serverless Framework 报告与八个不同的云提供商的兼容性。 唯一的注意事项是确保支持多云体系结构的元素或等效元素在目标云平台上可用。
此初始实现中的 API 管理器仅充当路由器，为两个云平台提供 50-50 的事务负载均衡。 API 管理器可以合并特定方案的其他业务逻辑。
方案详细信息
在无服务器计算中，云提供商动态分配微服务资源以运行代码，并且仅对使用的资源收费。 无服务器计算从基础结构实现、代码部署以及操作方面（如计划和维护）抽象出应用代码。
与其他服务一样，每个云提供商都有自己的无服务器实现，客户很难在没有较大操作影响和成本的情况下使用不同的提供商。 潜在客户可能会认为这削弱了其所处的议价优势和拥有的灵活性。 供应商锁定是企业云采用的最大障碍之一。
开源 Serverless Framework 是一个通用云接口，用于跨云提供商开发并部署无服务器计算解决方案。 无服务器函数的开源和通用 API 可帮助提供商、客户和合作伙伴构建跨云解决方案，以实现同类最佳的服务。 Serverless Framework 通过解决供应商锁定和跨云提供商冗余的问题，减少了云采用障碍。 客户可以基于成本、敏捷性和其他注意事项优化其解决方案。
CSE 和 Azure 产品团队共同重写了无服务器 CLI，以支持新的 Azure Functions 功能，如 Premium Functions、API Management 和 KeyVault。 无服务器 CLI 现在提供了一个标准接口，用于将 GitOps 部署到 Azure 和 AWS。 该团队还开发了无服务器多云库，该库提供规范化运行时 API，用于将无服务器应用部署到 AWS 和 Azure。
此设计在多个云平台之间提供主动-主动故障转移的高可用性，而不是主动-被动故障转移。 如果某个云提供商的服务运行不正常或不可用，此解决方案可以将请求重新路由到另一个云平台。
此项目满足以下技术目标：
- 创建跨行业解决方案。
- 使用多云无服务器库支持与云无关的 API，无论微服务部署在何处，它都可以与微服务交互。
- 支持在所有受支持的云平台上进行开发、测试和部署的 GitOps CI/CD 过程工作流。
- 通过经过身份验证的云网关使用基于 API 的访问，并使用网关作为路由器在云平台之间实现负载均衡。
使用 Serverless Framework 的其他潜在好处包括：
- 防止或减少供应商锁定
- 使用多云无服务器库在开发期间减少 40-60% 以上的代码
- 开发同类最佳解决方案，组合不同的云提供商服务
- 消除大多数平台和基础结构复杂性以及维护要求
- 更轻松地数据共享、性能和成本比较，并能够利用特殊产品/服务
- 主动-主动高可用性
可能的用例
- 使用无服务器多云库中的与云无关的 API，为多个平台编写客户端应用程序。
- 将无服务器框架中的功能微服务集合部署到多个云平台。
- 跨云平台使用与云无关的应用程序，而无需知道或关注哪个平台将其托管。
注意事项
尽管初始部署包含安全解决方案，但本文不做介绍。 有许多可能的安全解决方案，一些方案依赖于平台，此框架应该能够适应任何合理的解决方案。 用户身份验证是假定的最低安全性。
由于很难阐明 AWS 和 Azure 无服务器功能产品之间的差异，因此早期工作应侧重于映射每个云平台上可用的函数并确定必要的转换要求。 可以根据此信息开发与平台无关的 API。
使用开源解决方案可能会带来风险，因为存在长期维护和支持任何开源软件的挑战。
在免费版本中， Serverless Framework 的监视主要限于管理仪表板。 付费企业产品/服务提供监视功能。 目前，Azure Functions 无服务器插件不包括可观测性或监视设置，并且需要进行修改来实现这些功能。
此解决方案可以使用指标来比较云平台之间的性能和成本，使客户能够无缝优化跨云平台的使用情况。
部署此方案
传统的蓝绿部署将应用开发并部署到两个独立但相同的环境，即蓝绿环境，以提高可用性并降低风险。 蓝色环境通常是通常处理实时流量的生产环境，绿色环境是根据需要而进行的故障转移部署。 通常，CI/CD 管道会自动在同一云平台中部署蓝绿环境。 此配置被视为主动-被动配置。
在多云解决方案中，蓝绿部署在两个云平台中实现。 在无服务器情况下，将针对每个云平台部署两组重复的微服务，一组作为生产环境，另一组作为故障转移环境。 每个云平台中的这种主动-被动设置可降低平台关闭的风险，提高可用性，并实现多云主动-主动高可用性。
蓝绿部署的辅助优点是，在将微服务更新发布到生产部署之前，可将每个云平台上的故障转移部署作为微服务更新的测试环境。