在题为“什么比微服务更好？无服务器微服务”的网络直播中，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