作者 | Raja Saravanan
编译 | EthanServerless
已成为企业在数字化、现代化升级过程中越来越流行的范式，不管是国内的阿里云、腾讯云、华为云，还是国外的亚马逊云科技，微软等云计算厂商，都正在大力投入无服务器计算领域。由于 Serverless 提供了一个微型的架构，终端客户无需部署、配置或管理服务器服务，而且代码运行所需要的服务器服务皆由云端平台来提供，这就为企业提高了灵活性，同时降低了运营开销和成本。但与之而来的问题在于，Serverless 体系结构的高度分布式特性，要求开发人员重新思考其应用程序设计和开发方法。本文介绍几个最佳实践设计模式，以飨读者。
众所周知，Serverless 是基于微服务体系结构的自然选择。以基于 AWS 的 Serverless 应用程序为例，它依赖于 AWS Lambda 函数，这些函数在设计上是无状态和短暂的，Lambda 函数被设计为运行小块代码以响应其他服务发出的事件。Lambda 还与一系列可用于实现分布式系统中常见模式的托管服务集成，如消息队列（Amazon 简单队列服务）、API（Amazon API 网关）和事件流（Amazon Kinesis）。这将有助于将构建微服务过程中的痛点最小化。
为工作负载选择适当的设计模式
1、扼杀器（Strangler）模式Strangler 模式允许开发人员用微服务（可以用一个或多个 Lambda 函数实现）逐步替换其单体组件，而不是完全关闭或一次性替换。
Strangler 模式
此模式使用 strangler（如API网关）来接受对遗留系统的传入请求。然后，再将它们路由到遗留应用程序或新的 Serverless 应用。因为客户端只与 strangler 交互，所以他们不知道后端服务受到影响。一旦整个遗留系统被重构，并且所有流量都被路由到新应用程序，则可以安全地弃用前者。
2、聚合器（Aggregator）模式
在基于微服务的架构中，客户端通常需要调用多个后端服务来执行操作。由于这些调用发生在网络上，客户端和微服务之间的聊天通信可能会增加应用程序延迟，特别是在带宽有限的情况下。
聚合器模式
聚合器模式通过使用单个 Lambda 函数来接受所有客户端请求，减少了客户端需要进行的调用数量。然后，Lambda 函数将请求转发给适当的微服务和第三方 API，来聚合它们的结果，并向客户端返回单个响应。
3、状态机模式（State Machine）构建应用程序时，业务工作流往往会变得非常复杂。AWS 中的有一个比较好用的“Step”功能，可以用于协调涉及多个微服务的复杂工作流。“Step”功能包括内置的状态管理、分支、错误处理和重试功能，无需编写样板代码。
状态机模式
4、Saga 模式
在基于微服务的应用中，每个微服务通常都有自己的数据库，其中包含与其他微服务数据库中的数据密切相关的数据。Saga 模式通过协调互连微服务中的一系列本地事务来确保数据一致性。一旦微服务执行其本地事务，它就会触发链中的下一个服务执行其事务。如果一个事务在此过程中失败，将启动一系列补偿事务，以回滚以前事务中所做的更改。
Saga 模式
Saga 模式可以通过 choreography 或 orchestration 来实现。在 choreography 模型中，每个服务发布一个事件，触发下一个服务运行。而在orchestration 中，由中央协调器管理整个事务链。
5、断路器（Circuit breaker）模式
在分布式系统中，在满足一个请求时涉及多个服务，思考如何处理服务故障是至关重要的。有些问题（如网络延迟）是间歇性的，可以自行解决，可能只需上游服务的重调用即可。然而，更严重的问题或停机，就需要主动干预，解决所需的时间成本都是不确定的。在这些情况下连续重试可能会消耗关键资源，并导致依赖同一资源池的其他服务匮乏，这可能导致灾难性级联故障。
Circuit breaker 模式
断路器模式允许使用键值存储来跟踪请求故障和断路器状态，而且通过 Lambda 函数来决定是否需要基于故障计数对受影响的服务进行后续调用，从而在系统中构建容错能力。
总结
毫无疑问，云计算正在悄无声息的影响着改变着我们的生活。不论是商业，还是科研，Serverless 计算正在成为当下云计算的主流发展方向之一。于开发者而言，Serverless 的部署比较简单，但前提是，我们应该借鉴最佳实践模式来设计，减少不必要的资源浪费。
原文链接：
https://medium.com/@raja.sk.saravanan/architect-your-microservices-in-serverless-with-right-design-pattern-60ebe674968