张雪峰对话_15_14_不够坚定异地多活没有一步到位的遗憾
雪峰老师你好，今天想聊一聊关于饿了么做异地多活的一些问题。
饿了么异地多活一次成功，算是互联网技术圈，挺浓墨重彩的一笔。
当时你们决定在做这件事之前，经历了一个什么样的过程可以讲一讲吗？二零一七年之前，整个公司所有的业务系统都是部署在北京机房服务器，大概有四千多台。
另外还有栽备的机器是在云端，都是虚拟机，大概有三千多台。
当时我们分值的业务订单数量已接近千万级别，但是基本上北京机房已经无法再扩容了。
也就是说没有空余的机架啊，没有办法添加新的服务器了，必须再建一个新机房。
于是我们在上海建了一个新的机房，做多活之前，其实这里面有一个失误啊，当然这个失误我认为大部分团队呢可能都会会犯啊，就是先搞栽备，不敢一下子上异地多活啊，没能一步到位。
其实当时我也提过啊，我们是不是一步到位的这个问题。
虽然外界感觉饿了么一步到位了，其实我们之前还做过一个栽培，花了不少钱。
嗯，所以一开始是先做了栽培，然后才做了一粒多活，对吧？对，这是常规路径。
中国绝大部分公司啊都是做了在背后才想做多活。
当然能不能做成另说啊，有的最终没做成，或者说不敢做，或者内部阻力很大。
美团当年啊就没做成或在有没有彻底搞定异地多活，我不太清楚。
其实美团技术理域挺强的啊，因为跟着王鑫早期创业的人不少，包括美团还曾做过美团云。
只要做过原因，哪怕这个云资态烂，都储备了一批做基础设施挺强的人，这不是一般公司的技术领域能比的。
但是美团业务太强势，停几个月业务需求或只能做些无关核心的边角料需求。
不可能的。
饿了么好在技术这块拧成一股绳，基本啊就是我一个决断声音，说难听点啊，也是一言堂，或者我跟团队即使吵得再凶，他们在挑战我，但最后出去都是一个声音。
我跟他们说，你们当场挑战我都没问题，我也无所谓面子。
但是既然我们吵架炒出结果，或你就不要再回去反悔，不允许反悔，你跟团队被反悔，抱怨也是不允许的。
曾经有一个同学当场同意回去呢，就开始磨磨唧唧，在群里乱发啊，这个不行，那个不行，哪怕这件事事后证明错的，在当时你就得错到底啊，证明他是个错，也是有价值的。
更何况，异地多活，最终一次上线成功之后，更是挽救饿了么线上系统无数次当初有意义的同学，也包括外部知道这事，但不看好饿了么技术团队能搞定的同学，也都无话可说。
虽然最初下这个决断有一定的赌博成唯一一次美团跟我们做过的官方技术交流。
就是我们做了异地多活之后，大家知道。
虽然我们两家商业上竞争白热化，但技术同学之间还可以，大家不敌视交流，比较坦诚。
嗯，栽倍和多活的区别是什么呀？栽备什么意思啊？栽备是我有一套一模一样的系统，每次发布的时候两边多发一次。
但是生产的流量或者实际的数据不经过栽备系统，只经过主系统，然后通过数据同步模块全部同步过来。
但它有很大缺陷和风险。
如果做到极致啊，全是AI控制或机器人，控制理论上的精度会很高。
但实际上很多环节还是人来控制。
我们发布很多一天上千次多的时候超过两千次，还有依赖。
比如你发了AA点一a点一点一，那这里面只要有一个漏发，可能你生产系统没问题啊，因为你要用流量灰度切换的，但是那边是没有灰度的，没有流量，今天忘了就忘了。
运气好，明天又发了，这个就OK.但万一来一个事故流量一下子进来，那反而把数据搞乱了，结果不应该发的补贴发了啊，这也就算了，赔点钱。
但是如果数据错了，就大麻烦了。
所以它没有经过真实流量考验。
很多业务场景并不是发布系统，默双发或多发就能解决的，还是需要大量人工验证或灰度流量验证，才能保证万无一失。
做灾备，你要解决两个问题，备份和恢复，备份和恢复永远是一对的，不能切嗨。
一般的企业更多在备份上画功夫啊，这只做了一半或常态化做恢复演练的团队或公司已经有太多的成通教训嘛。
而多活呢既解决了备份，又解决了恢复问题。
因为不需要恢复数据始终在跑。
换句话说，就是只要确认是我可不可工作了就可以了。
所以在做多活之前，做灾备其实没有必要是吗？不是这个要具体问题具体分析的，不时我们为什么做灾备啊？因为直接上异地多活，我是有犹豫的。
跟我很熟的人啊，会经常质疑我在公开的会上也会挑战。
我说峰哥啊，你当时不应该做栽培，但我当时理由是说啊，中农工建都做了，美团也做了，滴滴也做了，除了阿里系，他们确实直接搞了一地多活。
那么除了阿里系，在全中国，大家想做交易类系统的第二只螃蟹吗？我说我不敢冒这个险，所以代价就是你做了一个用处不大的东西，但它也有一定用处。
万一被勒索软件盯上了，我们还有一份数据备份。
但是从现实意义来看啊，就好像没有太大用处，这个其实也很难评价。
就比如说你做各种形形色色的监控软件，你投入很多资源搞中间件应该很有作用吧。
但只要没出事，大家可能看不出来业务团队或者CEO,估计就更难体会到这方面进行投入的价值。
所以在国内有一个很怪的现象，而这确实跟发达国家不一样。
在国内，不管什么行业，救火英雄永远得到最大赞扬，幕后英雄却无人问津，导致很多真正牛逼的人，防患于未然的人反而委屈的走了。
我在饿了么尽可能去扭转这个局面，但也没有完全扭转过来。
因为你很难界定什么叫防患于未然，什么是因为基础设施投入还带来的巨大价值，或者避免了巨大风险。
在技术决策上，这是我的一次偏差，但后来还是做了异地多活。
当然，内很管健健康们们让坚坚定决决值。
我当时不是反对，而是犹犹豫，我在你不敢下决心搞异地多活，具体原因是什么呢？你纠结或者说犹豫的点具体是什么？没样，就是我吃不准中间线，这个团队能不能承担并搞定。
在这种规模下的交易系统上去实现一地多活。
更何况，一地多活，几乎只有一次上线，机会不成功，则成人。
只不过后面我下了决心，我们也不用立什么军令状了。
如果干砸，那从我开始，核心团队在收拾完烂摊子后全部下台，做一地多活的话，业务要耽误三个月，接不了。
涉及核心系统的大需求或大变更。
业务部门压力非常大我要去说服，而且上线后如果出问题，那就是致命的问题。
因为数据是分开的，我们原本就一份数据档期了可以恢复，至少数据不会乱，所以档期不是最可怕的，就怕你连档期的机会都没有，数据错乱或丢失，这是最可怕的因果。
按我对自己的要求的话，这件事我认为算是一个失误，说的好听点叫偏差，应该一步到位，搞一地多活。
因为做灾备也投入很多的，所以媒体说说钱水水漂。
但但当事多后多活异务多始也没有这样的勇气，因为确实饿了么，那时经不起任何大的波浪。
虽然这是给自己找的理由，但我感觉如果说要苛刻一点的话，确实是一个不正确的决定。
决定做异地多活之后，当时找了碧璇阿里云交流。
但是后来发现啊不能直接用阿里那套啊，因为阿里是适配全网应用，淘宝是没有网格概念的，三亚和哈尔滨是没有本质区别的。
但我们不行，我们是一个表面广域网，实际却由无数局域网构成的特殊业务网格。
而且我们网格之间是有重叠的，还比较复杂，所以后来决定只能自研。
那即使这样啊，我们第一批上线的异地多活，还是把物流给落下来啊，这是后话。
嗯，那如果你现在来选的话，直接就搞多活了，是吗？对，如果我回到当年啊，我就知道这个团队是能承担这个使命的那肯定直接搞多活。
当时我也不是太有底气，如果直接搞多活啊，也能省好多钱，异地多活。
当时做完之后，其实效果还是非常好的，是吧？是的，这件事事是我最为团队骄傲的。
不是说异地多活，后面帮我们挡了很多以前挡不住的灾难啊，而是我们有金无险，一次切换成功。
因为一旦切换不成功啊，就是灾难打补丁都很难。
那核心团队散架，我直接下台几乎是必然。
支付宝有一次严重失故，宁愿宕期不敢骄傲啊，就是因为不能出现一分钱的差错，这个简直就像银行卡里面出问题一样的一分钱就致命。
所以其实当时我不是很有信心能一次搞定异地多活又是做的跟阿里不一样的套路。
如果真出事啊，必全，阿里云也帮不上我们啊，都是我们自研适配的架构。
那一次啊真的是大家连续几天彻夜不眠，打个不恰当的比方双十一或者六幺八出事儿，那最多是稳定性层面的故障，舆论压力大啊，但不至于对公司产生致命影响。
但如果异地多活切换出事儿，舆论初期或许感觉不到。
但一旦短时间内不能恢复，对公司绝对是致命影响。
呃，CTO中的o的价值倒是体现出来的超级负面价值。
或许应了我之前说过的一句话，你可能连宕机的机会都不会。
再有了。
你刚刚也讲到第一批上线，异地多活，把物流给落下了。
这个是什么事情呀？后来我反思啊，这也是我另外一个不够坚定的地方吧。
啊也不能说我心软吧，就是不坚定。
因为当时物流业务老大，也就是联合创始人康佳，还有技术负责人，刘浩敏都犹豫了，但我能不能把他们放第二批物流出问题啊，他们都得跳楼。
但这样就等于帮物流填了个临时坑，但为整个技术团队挖了个更大的很。
后来我们要兼容第二批上异地多活的物流，在这期间要随时保证物流那边的顺畅，就做了很多开关。
然后我们中心件团队、架构师团队，还有PMO团队把杂七杂八这两套东西并线。
如果是两套业务系统并线还好一点啊，只要切个数据库就行了。
但做两套一多活就很麻烦啊，有一堆的风险要考虑，等于我们维持了几个月的大部分多活加物流非多活并行，切换时呢又胆战心惊的担心物流切换出问题，还得切回去，继续并行。
我们原来设想异地多活只能一次性切换，因为我们的业务是强耦合，不像携程啊，携程机票酒店关联度不大的。
你要订机票加酒店，那做个简单的聚合就行了。
但我们不一样，饿了么是用户下了单，商户接了单，物流就要送单，该内游的其实是强耦合。
程序员可能会说，现实业务没你说的那么理想，该抢耦合就抢耦合。
其实不是强耦合，另一个词叫高内聚。
该内聚的时候啊，你不要去追求什么微服务，那些乱七八糟的东西啊，就应该搞内聚。
因为就是一个业务形态，业务才是最重要的。
判断耦合或内聚的依据啊，谁也离不了谁，你每次调用都涉及到它，那干嘛非强扯开来啊，没太大好处，当然可以分开发布，算有好处。
但这也仅仅是技术上的好处，不是业务或领域上的好处。
最后送大家一句话，也是我对当年多活改造迁就物流团队的一个教训。
总结用英文描述比较贴切，avoid的solving one problem by creating啊的耦合，希望大家今后啊都能顺利跨过这里坎不再重蹈我当年覆辙。
你刚刚说美团也想做异地多活是吗？相当于他们也是呃走了你之前说的这个常规的路线，先做了栽备，然后再想做多活。
是美团做了异地栽备，美团现在没有CTO了。
在王慧文之前，CTO叫罗道丰，他原来是大众点评的CTO.后来美团和大众点评合并之后，他就做了美大的CTO之前提过我们团队和道丰团队间呃做过技术交流。
美团一直想做异地多活，但规划了几年，一直没做成。
后来我问了那边，相关同学，为什么他们说道分？虽然是CTO,但主要管公共的技术啊，也就是搞搞技础设施，大数据之类。
业务那边的技术团队非常独立啊，业务对自己的技术团队影响更大。
美团业务的强势度远远超过饿了么，技术要影响业务团队需求比较难。
因为如果要做改造啊，就要有很多的技术资源投入，那一定会影响业务交付业务不干了，他们业务团队的技术负责人直接汇报给业务老大。
但饿了么不是这样，我进去之后，先是所有的技术都在我这一边。
但后来发现这样有问题，这个模式不太好啊，我就跟汪源商量，把业务的技术跟业务的产品都实现汇报给他。
但业务的技术呢虚线汇报给我，虽然是虚线，但因为汪渊和团队的信任，这个虚线啊还是比较强的。
所以倒不是说罗道芬他搞不定是业务，根本不鸟你。
我们这边呢就比他要好一点，我几乎能完全掌控。
即使业务技术团队只是虚线。
嗯，好的，那异地多活背后的故事就先分享到这里，感谢你的收听。
如果你觉得这篇文章对你有帮助的话，欢迎把它分享给更多的朋友，我们下次再见。