文章插图
要做到这一点 ， 就需要让服务B“自杀” ， 如果应用侧发现B-C之间的网络出现异常 ， 就让B返回失败错误码 ， 不再进行重试 。
需要注意的点不能脱离业务众所周知 ， 开发大部分的时间都需要赶需求 ， 一方面需求多到无法挤出时间完成灾备的任务 ， 另一方面灾备工作如果不完成 ， 出现故障之后就会影响业务了 。因此通常会将这类需求当作技术需求来完成 ， 业务开发人员没有时间完成灾备工作时 ， 就会让一些负责技术需求的开发来直接完成灾备 。上面提到 ， 完成灾备最重要的一点就是需要梳理业务 ， 如果由一个完成不懂该业务的开发去完成灾备 ， 那么至少需要花1-2天去阅读代码 ， 理清业务逻辑和列出可能出现的坑才能完成这份工作 。但是笔者觉得这样做的效率是比较低的 。首先 ， 人无完人 ， 虽然代码大家都能看懂 ， 但是由一个未参与过业务的开发重新梳理 ， 难免会有遗漏的地方（即使问相应的业务开发 ， 也有可能会遗漏）；其次 ， 重新熟悉业务也需要投入一定的时间 。
所以 ， 做灾备是不能脱离业务的 ， 应该给业务开发匀出相应的时间完成服务灾备 ， 提高服务稳定性 ， 这对业务而言 ， 出现故障时不影响用户的使用 ， 用户无感知 ， 就是提高用户的体验 。
自动化运维在笔者的灾备经历中 ， 如果机器出现故障/机房故障/流量暴涨 ， 都需要运维和相应的业务开发人工介入判断是否需要扩容或摘除机器 。但是人的判读是主观的 ， 对是否需要扩容以及机器的选择可能会有判断出错的时候 ， 灾备的工作 ， 如果能结合现在较成熟k8s进行自动化运维 ， 那么将达到事半功倍的效果 。
总结灾备 ， 对于服务稳定性而言十分重要 ， 但是也不是一朝一夕能完成的 。个人觉得核心要点就是尽最大努力消除单点故障：服务单点、数据系统单点等等 。
以上的文字理论仅仅是笔者经历过的小小总结 ， 也许仍未做到最好的灾备级别 ， 还需要日后不断实践来提升这部分的知识 ， 如果有说错的地方 ， 还望各位指正 。
推荐阅读
- 茶园灌溉新渠道,康记古树中山渠道服务商隆重开业
- 淘宝买家消费者保障服务在哪里 淘宝支持卖家
- 怎么入驻淘宝 淘宝服务商怎么入驻
- 聊聊DOS操作系统中的文件系统FAT12
- 服务器被DDoS攻击最佳解决方案是什么？
- 天猫价保服务规则 天猫规定保价多少天
- 淘宝服务商代运营靠谱吗 淘宝店铺代运营公司靠谱吗
- 服务器基础知识
- 数据库服务器主机重启故障诊断分析
- 淘宝开通信用卡支付怎么收取费用 淘宝店铺开通信用卡支付服务费是多少