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

导语

在分布式微服务的架构下, 架构师往往面临著可靠性与性能间的抉择。 Circuit Breaker 提供了一个可同时兼顾可靠性与性能的解决方案。

前言

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

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

架构师假如只是根据 Time Out 来决定此笔交易的成功与失败, 则整体的微服务的整体架构, 便会很难能同时兼顾性能与可靠性。

本文

当来自某个微服务外部 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 了

C. 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 的作法与实现。

图一: Circuit Breaker

原创声明,本文系作者授权云+社区发表,未经许可,不得转载。

如有侵权,请联系 yunjia_community@tencent.com 删除。

编辑于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏程序猿DD

秒杀系统解决方案

感谢于霆霖的投稿,本文摘自:http://yutinglin.cn/2017/08/01/秒杀系统解决方案/ 我看了二十篇左右的秒杀系统设计及解决方案的文章,从...

2297
来自专栏IT笔记

记一次JavaWeb网站技术架构总结

题记 工作也有几多年了,无论是身边遇到的还是耳间闻到的,多多少少也积攒了自己的一些经验和思考,当然,博主并没有太多接触高大上的分布式架构实践,相对比较零碎,随时...

34511
来自专栏散尽浮华

linux负载均衡总结性说明(四层负载/七层负载)

在常规运维工作中,经常会运用到负载均衡服务。负载均衡分为四层负载和七层负载,那么这两者之间有什么不同? 废话不多说,详解如下: 一,什么是负载均衡 1)负载均衡...

4988
来自专栏北京马哥教育

Web APP编程模型和IO策略

现代大型高性能网站诸如淘宝,京东,微博,FB,知乎等等,网站架构涉及很多知识。像业务分层,软件分割模块化,分布式部署,集群服务器,负载均衡等技术可以帮助架构师将...

3387
来自专栏java闲聊

浅谈架构(单体架构、 SOA架构、微服务架构)

* 一个典型的单体应用就是将所有的业务场景的表示层、业务逻辑层和数据访问层放在一个工程中,最终经过编译、打包,部署在一台服务器上。

1684
来自专栏叁金大数据

存储是怎样炼成的?

什么FAT,NTFS,NFS,DAS,SAN,NAS,OSD这些名词我一个都不认识。

1043
来自专栏无题

秒杀系统解决方案

从架构、产品、前端、后端四个层面针对秒杀场景(可以扩展到所有高并发场景)分别总结了一些解决方案。 要点总结: 1.架构:扩容,业务分离,数据分离 2.产品:下...

3374
来自专栏SDNLAB

数据中心网络架构—VL2

一、背景 随着网络技术的发展,数据中心已经成为提供IT网络服务、分布式并行计算等的基础架构。数据中心应用范围愈加广泛,应用需求不断增加,业务数据量达T/P级以上...

3654
来自专栏美团技术团队

服务容错模式

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

3554
来自专栏Golang语言社区

网络服务器并发编程的几种方案对比

工作几年来,历经多种编程语言进行服务器端的开发,对几种方案优劣对比整理如下: 一 多进程 优势:1 具有很好的可靠性,其中一个进程挂掉后,系统在整体上仍...

32710

扫码关注云+社区