微服务架构 (四): 提升微服务分布式远程调用的可靠性与性能; Time Out 与 Circuit Breaker

2016.8.14, 深圳, Ken Fang

在分布式微服务的架构下, 架构师往往面临著可靠性与性能间的抉择。

当来自某个微服务外部 Client 的远程调用, 要求微服务处理一购买 100 张股票的订单时。

假如:

A.  架构师所设计的微服务外部 Client 远程调用的 Time Out 时间是 2000 ms。

      但, 此次微服务外部 Client 远程调用、微服务成功处理这 100 张股票的订单并送回一确认成功的信息到微服务外部 Client 时, 共花费了 3000 ms。

      所以, 微服务外部 Client 会误认为, 先前所发送的请求已因错误而 Time Out。微服务外部 Client 便又重发了一次 100 张股票的订单。

      这样的场景, 便使得微服务陷入一极为复杂的逻辑判断: 微服务需判断此 100 张股票的订单为重发或新购?

      这例子主要是说明了, 当架构师希望微服务的整体架构有一较好的性能时, 而将微服务外部 Client 远程调用的 Time Out , 设计得无法体现出:

      微服务 Client 远程调用、微服务处理服务与微服务送回一确认成功的信息到微服务外部 Client, 所需的总体时间时, 便会为整体微服务架构的可靠性带来风险。

      当微服务的整体架构有一较好的性能, 却会为可靠性带来风险:

      Time Out < 微服务 Client 远程调用所需的时间 + 微服务处理服务的时间+ 微服务送回一确认成功的信息到微服务外部 Client 的时间。

B.  架构师所设计的微服务外部 Client 远程调用的 Time Out 时间是: 微服务 Client 远程调用、微服务处理服与微服务送回一确认成功的信息到微服务外部 Client, 所需最长的总体时间的两倍。

     举例:

     微服务 Client 远程调用、微服务处理服与微服务送回一确认成功的信息到微服务外部 Client, 所需的平均总体时间为 2000 ms。

     微服务 Client 远程调用、微服务处理服与微服务送回一确认成功的信息到微服务外部 Client, 所需的最长总体时间为 5000 ms。

     微服务外部 Client 远程调用的 Time Out 时间便是: 10000 ms。

     架构师所设计的微服务外部 Client 远程调用的 Time Out 时间是 10000 ms; 微服务有更充裕的时间处理服务, 因而可靠性获得较好的保障, 但, 10000 ms 也许太长了, 而使得整体微服务的性能不佳。

     所以, 在分布式微服务的架构下, 光设计 “ Time Out” 是不够的。

     这也是为什么, 必需要在 Time Out 的架构下, 置入 Circuit Breaker 了。

     当架构师在微服务的 Client 与微服务间置入 Circuit Breaker 后, Circuit Breaker 将负责监控微服务的状态, 而使得微服务 Client 不致于一直还调用微服务, 当微服务已经无法运作时。

     另一方面, 当在微服务的 Client 与微服务间置入 Circuit Breaker后, 微服务外部 Client 远程调用的 Time Out 时间便是:

     微服务 Client 远程调用 Circuit Breaker 的时间 + Circuit Breaker 送回信息到微服务外部 Client 的时间。

     而这所需的时间便相当的短, 也许只需 1~2 ms。

     所以, Circuit Breaker 在整体微服务架构下, 扮演著相当重要的角色; 不仅保障了微服务整体的可靠性, 更不至于因保障了微服务整体的可靠性, 而牺掉牲了微服务整体的性能。

     在 GitHub 上有许多关于 Circuit Breaker 的实现。。

     我将在讨论到 AKKA 时, 再来讨论 Circuit Breaker 的作法与实现。 

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏社区的朋友们

Amazon Aurora 深度探索(二)

本文对 Aurora 系统的实现从整体架构、存储、事务处理三个方面进行深入探讨,基于其论文和相关资料讨论具体实现细节,又跳出其外、从数据库内核技术实现的角度对 ...

5671
来自专栏IT笔记

JavaWeb项目架构之Redis分布式日志队列

架构、分布式、日志队列,标题自己都看着唬人,其实就是一个日志收集的功能,只不过中间加了一个Redis做消息队列罢了。

48411
来自专栏Golang语言社区

Go 语言构建高并发分布式系统实践

你知道互联网最抢手的技术人才有哪些吗?最新互联网职场生态报告显示,最抢手的十大互联网技术人才排名中Go语言开发人员位居第三,从中不难见得,Go语言的渗透率越来越...

3104
来自专栏架构师之路

消息总线真的能保证幂等?

一、缘起 如《消息总线消息必达》所述,MQ消息必达,架构上有两个核心设计点: (1)消息落地 (2)消息超时、重传、确认 ? 再次回顾消息总线核心架构,它由发送...

4379
来自专栏Golang语言社区

Go 语言构建高并发分布式系统实践

你知道互联网最抢手的技术人才有哪些吗?最新互联网职场生态报告显示,最抢手的十大互联网技术人才排名中Go语言开发人员位居第三,从中不难见得,Go语言的渗透率越来越...

5325
来自专栏平凡文摘

你真的很熟分布式和事务吗?

1742
来自专栏美团技术团队

服务容错模式

背景 随着美团点评服务框架和服务治理体系的逐步成熟,服务化已成为公司内部系统设计的趋势。本着大系统小做、职责单一的原则,我们度假技术团队对业务系统进行了不少服务...

3554
来自专栏蓝天

大数据利器

1163
来自专栏CSDN技术头条

MongoDB + Spark: 完整的大数据解决方案

Spark介绍 按照官方的定义,Spark 是一个通用,快速,适用于大规模数据的处理引擎。 通用性:我们可以使用Spark SQL来执行常规分析, Spark ...

3889
来自专栏个人分享

分布式系统常用思想和技术

感谢该作者的总结,转载地址:http://blog.arganzheng.me/  本人将重点进行加粗,便于大家一起查阅学习

703

扫码关注云+社区