
课程咨询: 400-996-5531 / 投诉建议: 400-111-8989
认真做教育 专心促就业
微服务架构开发是目前大多数Java程序员都需要熟练掌握的一个软件架构方法,而本文我们就通过案例分析来简单了解一下,微服务架构故障处理方法都有哪些。
故障快速定位和止损的理想处理方式是将故障定位和预案执行打通,当出现故障时,能够判断出故障的大体类型以及对应的预案,并触发预案的自动执行。
当然实际的故障处理过程中有很多地方需要考虑,虽然并不是所有故障都能提前建立相应的预案,但我们可以根据历史故障和一些先验知识将故障进行归类,建立相应的预案。
另外,建立预案时应尽量方便执行和触发,如果不方便执行,很难短时间内处理故障,关键的问题是判断预案触发的时机,以及当前是否应该执行预案。线上服务稳定性故障大体可以归类为如下原因。
变更引起的故障
变更是稳定性故障的主要来源,系统广义的变更源很多,常见的服务变更一般包含应用变更、配置变更和数据变更。除了服务变更之外,环境和硬件的变化,比如网络带宽变化、机房链路变化等,也可以归为广义的变更范畴。
流量和容量变化引起的故障
这类故障对应于之前稳定性保障中分析的输入流量突变,如果服务提前没有足够的应对机制,会导致一定的稳定性隐患。
依赖故障
依赖服务故障会影响调用依赖服务的上游服务,依赖服务故障又分为强依赖服务故障和弱依赖服务故障,这两者会有相应的处理方式。
机房、网络等硬件和环境故障
硬件和环境故障的特点是没有办法预测,随机性和偶然性因素很大,并且一旦发生往往是系统级别的问题,会产生很严重的后果。
其他
比如ID生成器溢出导致的故障。
故障的场景化是指根据上述稳定性故障的大类,再细化出一些方便识别判断的场景,比如入口流量突增、接入层故障、强依赖服务故障、弱依赖服务故障等细分的场景。划分这些场景的目的是发生故障时,进一步识别故障的根因(不一定是根本原因,而是从止损的角度进行归类)。因此可以对那些比较容易通过可观测性指标判断出故障的场景类型,并且方便制定相应的场景化预案的故障,进行场景化归类。
【免责声明】本文系本网编辑部分转载,转载目的在于传递更多信息,并不代表本网赞同其观点和对其真实性负责。如涉及作品内容、版权和其它问题,请在30日内与管理员联系,我们会予以更改或删除相关文章,以保证您的权益!更多内容请加danei0707学习了解。欢迎关注“达内在线”参与分销,赚更多好礼。