说到零宕机架构,真是让人又爱又恨啊!你永远不知道下一个坑会出现在哪里(别问我怎么知道的,一把辛酸泪)。想想去年那次大版本升级,我们的服务整整宕了47分钟,客户投诉电话都快被打爆了。从那次教训后,我们团队算是真正明白了”零宕机不是目的,只是底线”这句话的分量。
服务冗余:别把所有鸡蛋放在一个篮子里
不知道你们有没有类似的经历——明明用了Kubernetes做横向扩展,结果一个AZ(可用区)出问题还是全挂了。我们后来采用了跨AZ+跨区域双活部署,虽然要多花点成本,但至少再也不用半夜被叫起来处理故障了。AWS的数据显示,单个AZ的年故障概率大概在0.1%左右,但当你有3个AZ并行时,这个数字会降到百万分之一。
流量管理:灰度发布只是个开始
我特别认同原文说的”灰度发布需要配套基础设施”这个观点。我们现在采用了一种叫”渐进式流量切换”的策略,配合着使用Istio的流量权重控制。比如说新版本上线时,会先从1%的内部员工流量开始,然后慢慢扩大到5%的测试用户,最后才是全量。过程中监控各种业务指标,稍有风吹草动就能立即回退。有意思的是,我们发现P99延迟是最灵敏的指标之一,往往比错误率更早暴露问题。
数据库迁移:最危险的环节
说实话,应用层的零宕机还相对容易实现,真正要命的是数据库迁移。上周我们刚用了一个”双写+消费者偏移量”的方案来做MySQL到MongoDB的迁移:先同时写入两个数据库,然后对比数据一致性,最后切换读流量。中间出了个小插曲——忘了考虑事务问题,要不是及时发现差点就翻车了。建议大家在设计这类方案时,一定要把回滚时数据一致性考虑进去。
说到底,零宕机架构就像保险——平时觉得投入太大,出事时才知道有多值。你现在投入的每一分钱、每一小时,都是在为未来的某个深夜省下那个报警电话。不过话说回来,要是真能做到99.99%的可用性,那点投入又算什么呢?你们有什么特别的零宕机经验吗?欢迎在评论区交流!
评论