在Serverless环境中如何设计微服务？

作者 | 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 的部署比较简单，但前提是，我们应该借鉴最佳实践模式来设计，减少不必要的资源浪费。

原文链接：

http://medium.com/@raja.sk.saravanan/architect-your-microservices-in-serverless-with-right-design-pattern-60ebe674968

来源： 51CTO技术栈