作者 | 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