在题为“什么比微服务更好?无服务器微服务”的网络直播中,Alan Williams(Autodesk)、Asha Chakrabarty(Amazon)和 Alan Ho(Apigee)讨论了一个无服务器微服务的架构。其中,该微服务的构建使用了 AWS lambda 函数和运行在 AWS 上的 Apigee 端点。
据 Chakrabarty 介绍,无服务器是一种相对比较新的架构风格,其中的计算单元不是虚拟机,而是一个封装了待执行代码(事件触发)的函数。Williams 指出,无状态计算模型的主要特点是:“代码为主(code focused)”、没有需要管理的服务器、没有需要配置和管理的 EC2 实例、无需人工扩展、没有空闲资源、没有 SSH 或 RDP。
下图简单地描述了一个由 Autodesk 实现的无服务器微服务的架构(点击查看大图):
该微服务有多个入口点作为 HTTP 端点(由 Apigee 管理)暴露。用户发起一个 HTTP 调用,并不知道其请求会由一个无服务器微服务提供服务。该服务由多个 Python 编写的 lambda 函数组成,这些函数之间通过 AWS SNS 异步通知进行通信。Lambda 函数是相互独立的,可以使用不同的语言开发,可以由不同的团队维护。
由于 lambda 不是短期的,所以它们需要将状态在某个地方持久化,其中一个选择是使用 DynamoDB 表。这些表的访问通过 IAM 角色控制,并且仅限于那些需要对它们进行读 / 写访问的函数。这可以避免将不需要的数据暴露给某个 lambda 函数,如果存在安全漏洞的话,这还可以缩小微服务的攻击面。Autodesk 之所以选择使用 DynamoDB 存储状态,是因为它简单,可以将数据作为 JSON 传递,不需要管理一个服务器实例,并且支持自动向上扩展。
上图底部的 DynamoDB 表(talr-taskstatus)将来自多个 lambda 函数的状态持久化,并在表被修改时产生流式事件。这些事件由另一个 lambda 函数监控(talr-validator),它会在必要时采取行动。
对于在 AWS 上实现一个无服务器架构,Williams 列举了如下好处。
- 敏捷性:只需数周就可以实现。
- 不需要管理基础设施,无需 EC2 或 ELB 实例,不需要打安全补丁。
- 开发人员只需专注于他们编写的代码。
- 通过无服务器框架管理代码的能力。
- 成本。根据他们的经验,运行 lambda 解决方案的成本只是传统云解决方案的一小部分(约 1%)。由于不需要雇佣运维人员配置和监控 EC2 和 ELB 实例,所以成本还会进一步降低。
Williams 还提到,无服务器架构不适合运行长期工作负载或者第三方应用程序。在那些情况下,他认为容器更合适。
本次直播还展示了如何在 AWS 上通过无服务器框架组织代码、部署和运行演示程序。
查看英文原文: A Sample Serverless Microservice Architecture from Autodesk
评论