微服务性能模式

标签: 微服务 性能 模式 | 发表时间:2016-02-24 02: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界微服务架构为基础的系统越来越多, 每一个应用系统都集成了不同的组件和服务,几乎所有的特定业务应用程序都需要集成一个或更多的应用服务. 但是一个综合性系统集成不同的服务这无疑是一个巨大的挑战.

微服务的反模式和陷阱

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

(译)面向性能的微服务

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

性能优化模式

- - 美团技术团队
一般而言,性能优化指降低响应时间和提高系统吞吐量两个方面,但在流量高峰时候,性能问题往往会表现为服务可用性下降,所以性能优化也可以包括提高服务可用性. 在某些情况下,降低响应时间、提高系统吞吐量和提高服务可用性三者相互矛盾,不可兼得. 例如:增加缓存可以降低平均响应时间,但是处理线程数量会因为缓存过大而有所限制,从而降低系统吞吐量;为了提高服务可用性,对异常请求重复调用是一个常用的做法,但是这会提高响应时间并降低系统吞吐量.

初识微服务

- - ITeye博客
微服务架构越来越火,有必要学习一下. 软件开发过程中碰到什么问题. 一个简单的应用会随着时间推移逐渐变大. 在每次的sprint中,开发团队都会面对新“故事”,然后开发许多新代码. 几年后,这个小而简单的应用会变成了一个巨大的怪物. 一旦你的应用变成一个又大又复杂的怪物,那开发团队肯定很痛苦. 敏捷开发和部署举步维艰,其中最主要问题就是这个应用太复杂,以至于任何单个开发者都不可能搞懂它.

高性能应用构建模式解析

- - ITeye博客
原文: http://java.sys-con.com/node/2116436. 虽然自己开发的一直都是号称"高性能, 高可用, 高并发"的"三高"应用. 但是一直没有对如何实现这种"三高"应用没有进行深入的思考, 直到最近看到这篇文章, 突然有一种醍醐灌顶的感觉. 所以简单的将其转换成中文, 以方便以后工作中的不时之需.

(转)关于Mybatis的Batch模式性能测试及结论

- - jackyrong
近日在公司项目中,使用到spring+mybatis的架构,特对mybatis的batch模式做了相关研究,得出以下结论:.      1.Mybatis内置的ExecutorType有3种,默认的是simple,该模式下它为每个语句的执行创建一个新的预处理语句,单条提交sql;而batch模式重复使用已经预处理的语句,.

谈微服务架构

- - 人月神话的BLOG
其实在前面很多文章谈到SOA,特别是系统内的SOA和组件化的时候已经很多内容和微服务架构思想是相同的,对于微服务架构,既然出现了这个新名称,那就再谈下微服务架构本身的一些特点和特性. 从这个图可以看到微服务架构的第一个重点,即业务系统本身的组件化和服务化,原来开发一个业务系统本身虽然分了组件和模块,但是本质还是紧耦合的,这关键的一个判断标准就是如果要将原有的业务系统按照模块分开部署到不同的进程里面并完成一个完整业务系统是不可能实现的.

微服务与架构师

- - 乱象,印迹
因为工作的关系,最近面试了很多软件架构师,遗憾的是真正能录用的很少. 很多候选人有多年的工作经验,常见的框架也玩得很溜. 然而最擅长的是“用既定的技术方案去解决特定的问题”,如果遇到的问题没有严格对应的现成框架,就比较吃力. 这样的技能水平或许适合某些行业,但很遗憾不符合我们的要求. 软件架构师到底应该做什么,又为什么这么难做好,这都是近来的热门问题,我也一直在和朋友们讨论.

从Excel到微服务

- - 乱象,印迹
Excel很老,Excel很土,Excel一点也不sexy;微服务新,微服务很潮门,微服务很高大上. 那么,Excel和微服务有什么关系. 上个月看了篇文章,The Unbunlding of Excel. 作者认为,对于初创公司(尤其是非“纯IT”初创公司)来说,Excel几乎包办各种工作. 想做轻量级的CRM,可用Excel.