前往小程序,Get更优阅读体验!
立即前往
首页
学习
活动
专区
工具
TVP
发布
社区首页 >专栏 >Facebook + Instagram + WhatsApp 同时故障,损失上亿美金

Facebook + Instagram + WhatsApp 同时故障,损失上亿美金

作者头像
业余草
发布2019-04-09 11:10:20
5690
发布2019-04-09 11:10:20
举报
文章被收录于专栏:业余草

Facebook 做为全球少有的几大互联网巨头,发生点故障就能引起巨大的波澜。Facebook 全球十几亿用户,一时间大家上不了 Facebook。除此之外,Facebook 的 Instagram、WhatsApp 等热门应用也同时发生故障。

这就是一个典型的故障雪崩效应。一个系统故障,发生雪崩,蔓延至其他系统。这也说明了,Facebook 的熔断机制,断路器,短路保护机制做的不够好!

640
640

系统崩了之后,各大用户疯狂的上 Twitter 进行吐槽。并且 Facebook 自己也在 Twitter 上发布消息承认了此次服务中断,该公司称:“我们知道,目前有些人在访问 Facebook 旗下各个应用程序时遇到了困难。我们正在努力尽快解决这个问题。“

并且 Facebook 证实,这个问题不是 DDoS 攻击带来的结果。DDoS 攻击即“分布式拒绝服务攻击”,是指黑客通过向一个站点输送大量虚假流量来发动攻击。

640
640

有网站统计了 Facebook 的问题的报告,多达 1.1 万多份。用户报告的问题,呈现各种各样的,从根本无法加载网站到无法发布评论等。

也有广告主吐槽,准备好的广告,也无法展现。广告主工具同样也遭遇了故障,有些广告主们试图投放“黑色星期五”(Black Friday)和“网络星期一”(Cyber Monday)广告。但是,这些广告都不能进行展现和营销了。

为此,有人预估了,Facebook 的这次故障,损失至少上亿美金。

参考其他互联网的故障损失,谷歌 2013 年故障 5 分钟损失 55 万美元,并且全球流量下跌!另外 2018 年 Prime Day 故障让亚马逊损失 $9900 万。2015 年 App Store 等服务故障导致苹果损失 2640 万美元。

微服务转型,雪崩效应是绕不过的一道坎。Hystrix 的隔离和熔断,线程池隔离和信号量隔离建议大家多学习学习!Facebook 这是多么疼的代价。

线程隔离技术,也称是线程池隔离技术。最著名的使用者算 Hystrix 了。Hystrix 提供了两种隔离策略,分布式:线程隔离和信号量隔离。Hystrix 默认的隔离技术就是线程池隔离,因为隔离技术有一个除网络超时以外的额外保护层。

  • THREAD(线程隔离):使用该方式,HystrixCommand将会在单独的线程上执行,并发请求受线程池中线程数量的限制。
  • SEMAPHORE(信号量隔离):使用该方式,HystrixCommand将会在调用线程上执行,开销相对较小,并发请求受信号量的个数的限制。

之所以,信号量隔离 SEMAPHORE 不是 Hystrix 的首选(默认隔离)的原因是,信号量隔离一般仅适用于非网络调用的隔离。比如,操作内存等。而对于跨网络的,调用负载非常高的(例如每个实例每秒调用数百次)才需要使用信号量隔离,因为这种场景下使用 THREAD 开销会比较高。

所谓的线程隔离主要有线程池隔离,在实际使用时我们会把请求分类,然后交给不同的线程池处理,当一种业务的请求处理发生问题时,不会将故障扩散到其他线程池,从而保证其他服务可用。

打个比方,在我们的电商系统中,假设现在有 3 个业务调用分别是查询订单、查询商品、查询用户,且这三个业务请求都是依赖第三方服务-订单服务、商品服务、用户服务。三个服务都需要跨网络请求调用,可以是 RPC 调用,也可以是 Rest 的 HTTP 调用。当查询订单服务出现故障时,假如线程阻塞了,这个时候后续有大量的查询订单请求过来,那么容器中的线程数量则会持续增加直致 CPU 资源耗尽到 100%,整个服务对外不可用,集群环境下就是雪崩。

640
640

如果这个故障进行隔离,那么最终回导致当前业务提供的服务也不可以使用。

640
640

如果通过线程隔离,那么就可以避免这种情况。通过设置线程池大小来控制并发访问量,当线程饱和的时候可以拒绝服务,防止依赖问题扩散。

640
640

对于电商系统来说,如果不做隔离,对于整个系统来说简直就是灾难。故障一秒,损失的就是钱啊。

对于 Hystrix 来说,用它来做服务隔离,是在简单不过了。看下面的代码:

640?wx_fmt=png
640?wx_fmt=png

线程隔离的优点:

  • 一个服务可以给予一个线程池,这个服务的异常不会影响其他的依赖。
  • 使用线程可以完全隔离第三方代码,请求线程可以快速放回。
  • 当一个失败的服务再次变成可用时,线程池将清理,并立即恢复可用,而不是一个长时间的恢复。
  • 可以完全模拟异步调用,方便异步编程。
  • 使用线程池,可以有效的进行实时监控、统计和封装。

线程隔离的缺点:

  • 使用线程池的缺点主要是增加了计算的开销。每一个依赖调用都会涉及到队列,调度,上下文切换,而这些操作都有可能在不同的线程中执行。

尽管有了线程隔离,但是并不意味着我们的代码可以随便写。必要的规范,超时机制还是要有的。

本文参与 腾讯云自媒体同步曝光计划,分享自作者个人站点/博客。
原始发表:2019年03月15日,如有侵权请联系 cloudcommunity@tencent.com 删除

本文分享自 作者个人站点/博客 前往查看

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

本文参与 腾讯云自媒体同步曝光计划  ,欢迎热爱写作的你一起参与!

评论
登录后参与评论
0 条评论
热度
最新
推荐阅读
相关产品与服务
容器服务
腾讯云容器服务(Tencent Kubernetes Engine, TKE)基于原生 kubernetes 提供以容器为核心的、高度可扩展的高性能容器管理服务,覆盖 Serverless、边缘计算、分布式云等多种业务部署场景,业内首创单个集群兼容多种计算节点的容器资源管理模式。同时产品作为云原生 Finops 领先布道者,主导开源项目Crane,全面助力客户实现资源优化、成本控制。
领券
问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档