微服务架构 (四): 提升微服务分布式远程调用的可靠性与性能; 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 条评论
登录 后参与评论

相关文章

来自专栏用户2442861的专栏

Java线程池管理及分布式Hadoop调度框架搭建

摘要:多线程一直不是件容易的事情,然而开发过程却又经常碰到,有时甚至还会被作为考校程序员实力的一个指标。这样一来,多线程已然成为一道必须迈过的砍!

553
来自专栏Java职业技术分享

后端技能树修炼:CAP 定理

近年来,CAP 定理已经成为分布式系统设计的基本准则之一,CAP 定理表明,任何分布式计算机系统只能同时满足一致性(Consistency),可用性(Avail...

390
来自专栏Java进阶

分布式相关基础理论

2658
来自专栏IT笔记

分布式与集群有什么区别

一个是3个字,另一个2个字 集群一般被分为三种类型,高可用集群(High-availability (HA) clusters )如RHCS、LifeKeepe...

3534
来自专栏编程一生

漫画:性能、可用性和锁

1073
来自专栏北京马哥教育

Linux下的CPU使用率与服务器负载的关系与区别

当我们使用top命令查看系统的资源使用情况时会看到load average,如下图所示,它表示系统在1,5,15分钟的平均工作负载。 那么什么是负载(l...

3127
来自专栏Java架构

干货:大型互联网公司分布式缓存的优秀实践和线上案例在此我在推荐一个学习架构框架的学习体系:

2436
来自专栏大宽宽的碎碎念

你对Redis的使用靠谱吗?Redis的性能高,吗?Redis可以保证原子性,吗?用Redis可以实现事务,吗?用Redis可以当队列,吗?Redis适合用来做什么?

35810
来自专栏lulianqi

为什么需要多线程

对于这个问题可能很多朋友会说是为了高性能,个人觉得这是误解,多线程不等于高性能,从cpu(单核)的角度上看单线程才能带来最高性能。

502
来自专栏EAWorld

微服务架构实践:服务注册与发现中负载方案选型

微服务架构不是银弹,在微服务架构中,我们将面临很多新的问题,这时候势必会引入一个服务注册发现问题。本文作者向大家介绍了随着负载均衡位置的不同,三种主要的服务注册...

34611

扫码关注云+社区