微服务性能模式

标签: 微服务 性能 模式 | 发表时间:2016-02-24 10:29 | 作者:jenny.run
出处:http://www.iteye.com

微服务性能模式

前言:基于微服务系统越来越普遍。下面我们就来看看五种常见的特定微服务性能的挑战,以及如何应解他们

背景:在IT界微服务架构为基础的系统越来越多, 每一个应用系统都集成了不同的组件和服务,几乎所有的特定业务应用程序都需要集成一个或更多的应用服务。但是一个综合性系统集成不同的服务这无疑是一个巨大的挑战。随着基于微服务架构的发展,集成点和接触点的数量大量增加,许多系统基于微服务提供的服务或功能开始进行系统自身的分解。这反过来又增加了性能挑战,影响系统的整体功能。本文主要讨论一些能影响以微服务为基础系统的性能的关键性挑战,也提出了一些能够避免这些问题的技术和模式;

系统集成面临的挑战

分布式计算本来就有它自己的挑战,所有这些挑战不仅有据可查,而且还几乎每天都在分布式系统上工作的专业人士都经历过。尤其在集成环境中接触点超过了“正常点”,就会变得更糟糕。如果我们的应用程序没有设计优雅地处理这种情况,这对我们的应用程序的性能和稳定性将产生不利影响。当连接到其他微服务(在同一界范围内或者远程的,外部系统)时,很多事情都可能出错,可能导致微服务的连接速度变慢甚至奔溃。在本节中,我们将讨论一些方法和设计方面的决策,这可以帮助我们在微服务为基础的环境中实现更好的性能,增强系统的弹性和整体稳定性。

一、Throttling 节流模式

节流是一种技术,可用于避免任何由于行为异常或“胭脂”应用,发送的请求超过我们的应用程序处理的荷载,而导致的系统过载或奔溃。实现节流的一个简单方法是限定单个应用程序的连接数。考虑有两个厂商调用我们的微服务从账户中取钱。如果一个供应商是一个很大的应用程序像亚马逊,那么它调用应用的次数要比一个拥有小用户群体的供应商要多的多。因此,我们可以提供这两家厂商两个独立的专门“切入点”专用节流进行连接限制。这样,大量来自亚马逊未来的请求不会妨碍从第二个供应商来请求。此外,我们可以调节各个合作伙伴,这样发送请求速度就不会超过我们的处理速度了。来自外部负载均衡器或HTTP服务器同步请求或其他这样的切入点就是节流。

二.Timeouts 超时

如果请求的微服务回应比较迟钝,这会导致系统的一次请求需要花费很长时间。甚至应用程序线程在很长的时间内处于忙碌状态。这可能对我们的应用程序中的级联影响,导致应用/服务器成为完全哽咽/响应。大多数库/APIs/框架和服务器都为各种特定的请求超时提供配置。您可能需要设置读取请求/写请求/等待超时/保活超时超时/连接池等待超时等。这些超时值只能通过适当的性能测试/验证SLA等确定

三.Dedicated Thread Pools/Bulkheads 专门的线程池/舱壁模式

另一个重要的设计是:让不同任务请求通过自个专门的线程池请求到各自微服务,像舱壁一样对资源进行隔离; 假设这么个场景,在应用中你需要使用REST通过HTTP连接五个不同的微服务,使用一个普通的线程池去维持这些连接,如果五个服务中其中一个服务由于某种原因出现异常,所有的池成员都将精疲力尽的等待服务器响应,为了最大限度地减少的影响,它始终是一个很好的做法,定制个性化服务话服务始终是一个号的做法。这可以减少某个异常影响对其他服务的影响,从而使您的应用程序其他部分继续执行。这种模式俗称的舱壁。
下图描述了实施舱壁的简单的示例场景:在左侧,微服务A,用同一个连接池去请求X和Y两个服务。如果服务X或服务的Y其中任何一个行为异常,这会影响连接池的整体行为。如果舱壁模式实现,如该图所示的右侧,即使微服务X被错误操作,只有池X将受到影响。微服务Y可以继续为应用程序提供服务.



 

四.Circuit Breakers 断路器(CircuitBreaker)设计模式

断路器是一种设计模式,它是用来减少任何下游的不可访问或系统故障(由于计划内或计划外的中断的)影响。断路器用于检查外部系统/服务的可用性,一旦外部系统或服务奔溃了,断路器应用程序就可以阻止发送请求到这些外部系统。这种做法作为一种安全措施,在超时/舱壁,其中一个可能不希望,甚至等待超时所规定的期限上。如果下游系统宕机,那是没有用的等待超时时间为每个请求,然后获得超时异常的响应。相反,请求应甚至不尝试连接到这些系统中,在时间,当这些下降。断路器可有内置的逻辑来执行外部系统进行必要的健康检查,并开始转发请求,一旦这些系统和做工精细。

五.Asynchronous Integration 异步集成

解耦各个微服务之间的通信可以避免多数的集成性能问题,异步集成方法是一种实现解耦的机制,如果您的系统基于微服务系统设计的,而且是各个微服务之间都是点到点的整合,那么这就值得认真思考了。任何标准的消息代理系统可用于提供发布 - 订阅功能。

总结

在本文中,谈到了一些我们所面对集成基于微服务系统性能的挑战。它也提出了一些设计模式,设计系统怎么避免这些性能问题。我们讨论了限制,超时,舱壁和断路器模式。除了这些,异步集成方法也进行了讨论。
简而言之,异步集成应该是首选,只要有可能。其他的设计模式,我们应该根据集成场景去使用,来避免异常引起下游系统的级联副作用。



已有 0 人发表留言,猛击->> 这里<<-参与讨论


ITeye推荐



相关 [微服务 性能 模式] 推荐:

微服务性能模式

- - 互联网 - ITeye博客
前言:基于微服务系统越来越普遍. 下面我们就来看看五种常见的特定微服务性能的挑战,以及如何应解他们. 背景:在IT界微服务架构为基础的系统越来越多, 每一个应用系统都集成了不同的组件和服务,几乎所有的特定业务应用程序都需要集成一个或更多的应用服务. 但是一个综合性系统集成不同的服务这无疑是一个巨大的挑战.

微服务之saga模式

- -
你已经使用 database ber service 模式. 每个service拥有自己的database. 一些业务事务会跨越多个service,所以你需要来确保data consistency. 例如,假设你正在构建一个电子商务网站,这个网站的用户的会有一个最大欠款限制,应用程序必须确保一个新订单不能超过用户的最大前款限制,但是orders表和customers表不在同一个数据库,所以应用程序不能简单的使用本地的ACID事务.

微服务的反模式和陷阱

- - 鸟窝
前几天我写了篇读书笔记: 《产品级微服务的八大原则》,介绍了Uber的SRE工程师 Susan J. Fowler 的免费书: Microservices in Production,文中提出了一个微服务成功与否的唯一标准就是可用性,非常有实践意义. 但是这本书偏向于从 SRE (site reliability engineer)的视角看待微服务,对于开发工程师 (SWE, software engineer)来说,更关注的是如何正确地从单体程序重构到微服务架构,或者从头设计微服务架构, 这篇读书笔记主要就是介绍这方面的实践和经验.

(译)面向性能的微服务

- - mindwind
从性能响应延迟的角度解读微服务带来的影响,并提出了几个保证服务低延迟的建议. 微服务是目前的一个热门词汇. 它是原创的还是基于最佳实践产生的. 虽然在实施微服务的过程中有一些缺点,但这些缺点能被克服么. 一旦你组装好了一个大系统,那么几乎不可能监测到系统的最大延迟来自哪里. 你可以监测到平均的延迟和吞吐量,但为了达到稳定的延迟,需要去分析系统的关键部分.

微服务的十个反模式和陷阱

- - 后端技术杂谈 | 飒然Hang
O’Reilly的电子书《Microservices AntiPatterns and Pitfalls》讲述了在微服务设计实现时十种最常见的反模式和陷阱. 书籍地址: https://www.oreilly.com/programming/free/microservices-antipatterns-and-pitfalls.csp,更全的反模式和陷阱可见作者的视频: http://oreil.ly/29GVuDG.

微服务分布式一致性模式 – ThoughtWorks洞见

- -
微服务拆分后遇到的一个麻烦是分布后的一致性问题. 单体架构的业务处理和数据都在一个进程里面,一致性保障很成熟,开发人员基本上不用关心. 当把业务系统拆分到不同进程时,就遇到了技术性一致性问题. 这带来了纠结,我们希望有一颗银弹,一把解决问题. 但由于分布式一致性在(CAP)理论上没有完美的解决方案,我们所能选择的方案是在特定业务场景下的选择.

[ 翻译 ] 微服务架构及设计模式

- -
本文介绍了主流常见的微服务模式. 因此,了解如何处理微服务架构(MSA)以及一些微服务设计模式,一个微服务架构的一些通用目标或者设计原则是很有价值的. 下面是在微服务架构方案中值得考虑的四个目标[1]. 1、缩减成本:MSA将会降低设计、实现和维护IT服务的总体成本. 2、加快发布速度:MSA将会加快服务从想法到部署的落地速度.

从单体迁移到微服务的几种模式

- -
正确实现的微服务较单体应用有很多优势. 许多组织都希望将他们的单体应用程序代码换成微服务代码. 但事实证明,迁移到微服务并非易事. 你应该问的第一个问题是,你真的需要微服务吗. 单体存在的许多问题都可以使用模块化的单体架构轻松解决. 一旦你确定自己真的需要微服务,就必须制定一套将单体应用转换为微服务的计划.

微服务架构设计模式 - XuMinzhe - 博客园

- -
单体地狱的银弹-微服务架构. 大型的复杂应用程序可以持续交付和持续部署. 每个服务都相对较小并容易维护. 分布式系统带来的各种复杂性. 开发者需要思考到底应该在应用的什么阶段使用微服务架构. 随着网络基础设施的高速发展,以及越来越多的个体接入互联网,在考虑构建支持海量请求以及多变业务的软件平台时,微服务架构成为多数人的首选.

微服务架构及设计模式 - DockOne.io

- -
【编者的话】本文作者详细介绍了微服务架构里一些常见的设计模式和它们各自的使用场景. 因此,了解如何处理微服务架构(MSA)以及一些微服务设计模式,一个微服务架构的一些通用目标或者设计原则是很有价值的. 下面是在微服务架构方案中值得考虑的四个目标. 缩减成本:MSA 将会降低设计、实现和维护IT服务的总体成本.