从0开始学微服务
胡忠想
微博技术专家
立即订阅
16289 人已学习
课程目录
已完结 42 讲
0/4登录后,你可以任选4讲全文学习。
开篇词 (1讲)
开篇词 | 微服务,从放弃到入门
免费
模块一 入门微服务 (10讲)
01 | 到底什么是微服务?
02 | 从单体应用走向服务化
03 | 初探微服务架构
04 | 如何发布和引用服务?
05 | 如何注册和发现服务?
06 | 如何实现RPC远程服务调用?
07 | 如何监控微服务调用?
08 | 如何追踪微服务调用?
09 | 微服务治理的手段有哪些?
10 | Dubbo框架里的微服务组件
模块二 落地微服务 (14讲)
11 | 服务发布和引用的实践
12 | 如何将注册中心落地?
13 | 开源服务注册中心如何选型?
14 | 开源RPC框架如何选型?
15 | 如何搭建一个可靠的监控系统?
16 | 如何搭建一套适合你的服务追踪系统?
17 | 如何识别服务节点是否存活?
18 | 如何使用负载均衡算法?
19 | 如何使用服务路由?
20 | 服务端出现故障时该如何应对?
21 | 服务调用失败时有哪些处理手段?
22 | 如何管理服务配置?
23 | 如何搭建微服务治理平台?
24 | 微服务架构该如何落地?
模块三 进阶微服务 (8讲)
25 | 微服务为什么要容器化?
26 | 微服务容器化运维:镜像仓库和资源调度
27 | 微服务容器化运维:容器调度和服务编排
28 | 微服务容器化运维:微博容器运维平台DCP
29 | 微服务如何实现DevOps?
30 | 如何做好微服务容量规划?
31 | 微服务多机房部署实践
32 | 微服务混合云部署实践
模块四 展望微服务 (4讲)
33 | 下一代微服务架构Service Mesh
34 | Istio:Service Mesh的代表产品
35 | 微博Service Mesh实践之路(上)
36 | 微博Service Mesh实践之路(下)
阿忠伯的特别放送 (4讲)
阿忠伯的特别放送 | 答疑解惑01
阿忠伯的特别放送 | 答疑解惑02
微博技术解密(上) | 微博信息流是如何实现的?
微博技术解密(下)| 微博存储的那些事儿
结束语 (1讲)
结束语 | 微服务,从入门到精通
从0开始学微服务
登录|注册

20 | 服务端出现故障时该如何应对?

胡忠想 2018-10-06
在专栏前面我讲过,单体应用改造成微服务的一个好处是可以减少故障影响范围,故障被局限在一个微服务系统本身,而不是整个单体应用都崩溃。那么具体到一个微服务系统,如果出现了故障,应该如何处理呢?
首先,我先来带你回顾一下微服务系统可能出现故障的种类,主要有三种故障。
集群故障。根据我的经验,微服务系统一般都是集群部署的,根据业务量大小而定,集群规模从几台到甚至上万台都有可能。一旦某些代码出现 bug,可能整个集群都会发生故障,不能提供对外提供服务。
单 IDC 故障。现在大多数互联网公司为了保证业务的高可用性,往往业务部署在不止一个 IDC。然而现实中时常会发生某个 IDC 的光缆因为道路施工被挖断,导致整个 IDC 脱网。
单机故障。顾名思义就是集群中的个别机器出现故障,这种情况往往对全局没有太大影响,但会导致调用到故障机器上的请求都失败,影响整个系统的成功率。
在我的实践过程中,这三种故障都经常遇到,因此相应的处理手段也可谓驾轻就熟,下面就把我应对故障的实战经验分享给你,希望对你有所帮助。

集群故障

一般而言,集群故障的产生原因不外乎有两种:一种是代码 bug 所导致,比如说某一段 Java 代码不断地分配大对象,但没有及时回收导致 JVM OOM 退出;另一种是突发的流量冲击,超出了系统的最大承载能力,比如“双 11”这种购物活动,电商系统会在零点一瞬间涌入大量流量,超出系统的最大承载能力,一下子就把整个系统给压垮了。
取消
完成
0/1000字
划线
笔记
复制
© 版权归极客邦科技所有,未经许可不得传播售卖。 页面已增加防盗追踪,如有侵权极客邦将依法追究其法律责任。
该试读文章来自付费专栏《从0开始学微服务》,如需阅读全部文章,
请订阅文章所属专栏。
立即订阅
登录 后留言

精选留言(18)

  • 叽歪
    文章深度不够,能不能在深入一点
    2018-10-10
    41
  • 叽歪
    单机故障重启,这个没有说服力,故障是肯定有原因的,应该找到根本原因.故障重启不是一个资深工程师的解决问题的方法.强烈不认同

    作者回复: 单机故障有多种原因,一切以恢复线上服务为首要目标,重启后可以发邮件告警,如果有机器出现频繁重启,运维就需要介入查看具体原因

    2018-10-10
    6
  • 拉欧
    只能通过最终一致性保证,比如MySQL的binlog复制
    2018-10-09
    2
  • godtrue
    嘿嘿😁,每逢大促,应急预案演练RPC这块也讲这些,确实不够深入,不过也能理解毕竟篇幅有限,深入还行看书。
    感谢!
    2019-06-15
    1
  • 波波安
    一般不保证实时一致性,只能保证最终一致性。
    1、两个中心中拉专线,进行数据底层同步。2、对于重要数据在做完底层同步后还可以通过消息队列再做一次异步同步来作为补偿。但是要控制好,防止数据重复写入。
    2018-10-14
    1
  • 大光头
    一致性分为弱一致性和强一致性。强一致性比如银行转账业务,就必须要求是强一致性。而对于微博评论,并不要求发出去之后立马看到,只要最终看到就可以,晚一点也没关系。
    对于强一致性系统,一般都会有读写分离,读可以从多个备份中取数据,而写必须要数据同步到所有备份之后返回。
    而弱一致性性,读写分离之后,写的话只写入主库就可以直接返回,然后异步同步到其它备份。这样就会出现某些请求拿不到最新数据
    2018-10-08
    1
  • 公号-代码荣耀
    拉光纤专线能否实现?但是数据完全一致似乎很难做到?
    2018-10-06
    1
  • 好好学习
    单机故障,重启过于暴力,硬件问题出现ping不可达,假死可以重启,其他软件层面还是要有其他层面的分析

    作者回复: 是的,可以设置最大重启次数,超过这个就不重启了

    2018-10-06
    1
  • ´◔ ‸◔)
    监控要到位,包括硬件及服务。根据收到的告警内容综合评估吧,可能是流量太大导致单机处理瓶颈。可能是物理机挂了导致的硬件故障。直接重启有点暴力。但最终大都离不开,重启,回滚,加机器。
    2019-07-02
  • 亚林
    现实中网络不可靠是一定的,所以,CAP理论中的P(分区容忍)一定会出现。所以,CAP理论告诉我们实现情况,我们只能够在CP和AP之间进行选择。
    2019-06-03
  • 张小男
    最大线线程数设置多少合理?我们高峰期有10000多,当然服务现在还没拆!这样8核16G都跑不满
    2019-04-16
  • 张小男
    线程数达到多少算瓶颈?我们高峰期现在是10000多,8核16G!cpu都跑不满
    2019-04-16
  • 松花皮蛋me
    负载均衡中健康检测可以应对单机故障的情况
    2019-02-17
  • 花生
    用九桥,在异地机房在数据实时备份
    2019-01-13
  • Liam
    能否讲讲具体的限流方法,例如有接入层限流,nginx的配置等

    作者回复: 限流有好几种算法,比如令牌痛算法,可以搜搜它的原理

    2018-10-18
  • malasang
    分布式数据库,通过分布式锁控制数据写入和更新删除。
    2018-10-08
  • 明天更美好
    异步不复制,最终一致性即可
    2018-10-07
  • vick
    如果没有很大实时性需求的话,两个idc之间保持后台数据同步,故障恢复后等数据同步完成再开启关闭的idc。
    2018-10-07
收起评论
18
返回
顶部