简介（未完成）
毕玄：异地多活的难点是因为全世界完全没有可参考方案。Google 虽然有全球部署，但广告搜索不一样，比较简单，腾讯也有，但腾讯是社交也比较简单，交易类型的网站一家都没有，我们最早本来想看亚马逊，结果发现他也不做了。到这里我们就很痛苦。我们第一次开会，下面各方技术都问我，这个项目的方案是什么？我说这个方案现在还不知道，等我们先摸索一下。下面全听傻了，说还能这样。所以这个项目就很槽糕，我们花了一年左右来摸索方案到底是什么。做这种大的架构，一般是你首先有了一个系统全貌，其次你有了解决的思路，你就可以大概知道我需要哪些人来帮我，然后你去找各领域的人，告诉他我的思路是这个，你看这个系统里怎么改能做成这样，慢慢拼出一张图。所以我们先有了个大概想法，但这个想法多成熟肯定是不知道的，只能先做一部分看看。但是因为没有全貌，不知道要改哪些，一开始就漏掉了很多，第一版设计方案最后要上线了我们才发现还有一堆要改的东西漏改了，然后临时去做那堆的方案。所以主要问题就是漏，漏这漏那。花了半年多，我们逐步把方案试出来了，方案清楚了后面就很简单。但是前面比较难，如果有参考，你也有信心，大概也知道怎么做，一切都会好很多。
边试边做，不会有人质疑你吗？我现在觉得跟信任有很大关系。当时做这个项目，我上面所有的 Leader 没有一个人过问我，也没有人挑战我，否则一定会很多人挑战，这啥也不知道就敢上线，你胆子也太大了。会不会因为别人没法挑战？他也不知道方案。对，所有人都没有方案，但即使后面有了方案，还是有人会挑战觉得你们这方法也不好，不靠谱，有没有更简单的？但我们比较强硬。当时异地多活我是面对上千人，做完我刚好 P9P10 晋升，面试就有人问：这些人都不向你汇报，为什么要听你的？我说最关键的就一点：因为我还掌握着所有人的机器。你要机器是我给你的，我给你的就是异地的机器，所以你必须配合我做异地的方案，如果你不做，我无所谓，但你上线肯定会出问题，反正你想逼我给同一个地方的机器我是给不了的，没有，你找谁都给不了。所以我后来跟很多人总结说，这个项目做得不算非常好。而且从团队层面上来讲也不好。当然大家都认为很成功，项目组得到了很高的评价，也能看到我因为这个被晋升了，但这个项目里同样被晋升的人太少了，当然还有一些低级别的晋升，但高级别的差不多就我一个。这就是最大的败笔。一个项目，如果对公司有非常大的价值，理论上应该有非常多的人被晋升，这也是你在公司能更好做成项目很重要的方面，因为各方都获得了利益。你想，如果只有你一个人获得利益，肯定是有问题的。所以异地多活做的整个过程，抱怨非常大，只是因为我们确实相对强势，但这种强势后面其实也会引发一些问题。如果没做成，那肯定挂了。但即使成了，还是会有人有很多看法，这个我也认。因为对一家公司来讲，以战养兵是最重要的，你一个这么大的战斗，竟然没有培养出很多的人，这确实有问题，我是承认的。因为一个这么大的项目，总不可能是一个人就干成了，肯定是有很多人一起，但是就看这些人有没有机会被更多高层知道。说实话高级别晋升，贡献很重要。但高层会认为那不就是他吗？其他人做了什么？高层认为就因为他，所以做成了。其实不是这样。越是大项目，越要把大家团结住。你想，大家一起做了一个很大的事情，对公司有很大贡献，但是只有你有成绩，下面的人没有被认可，那这些人会很受不了，我明明干了很多事情，最后为什么还是没有得到认可。业务方就更不爽，因为他觉得这又不是我主要的事，浪费了我很多时间，我什么也没得到，然后你们都得到了，替你打工。再加上光环如果过度集中在一个人身上，那个人会成为众矢之的，肯定是这样。因为其他人会觉得我无非是成就了你，所以后来做很大的项目我们会特别注意，不要塑造一个神，不是好事。
揭开腾讯云原生同城双活的秘密 对四个阶段的架构设计及特点做了详细介绍
- 数据冷备：实现简单，无需业务改造
- 在线热备：因为冷备只备了数据，故障恢复的时候需要把业务布起来，恢复的时间比较久，所以出现了在线的热备，但是热备常态下备份不提供在线服务，导致资源大量浪费，且可靠性难保障
- 同城双活：相比于异地多活实现起来较简单，业务改动较少，可以提供在线服务，让资源有效利用，故障恢复时间比较短
- 异地多活：多活实现比较复杂，需要业务去做Set化的改造，同时运维也比较复杂，但它的优势是故障恢复时间非常短。每个地域或者每个数据中心都会同时接入写入流量，用户的请求或者访问在单个数据中心去实现交易的闭环。
- 仅业务层多活。 存储层主集群部署在一个机房，业务层写请求还是写到主机房。
- 业务层多活，存储层支持多主多从。
同城双活
前置条件是：
- 数据服务支持实时增量同步，
- 接入层/应用层无状态，
- 应用层可接受跨区访问数据层增加的网络/数据延迟； 改造代价是：
- 中间件实现自动流量调度，以及数据层故障HA自动切换，
- 本可用区应用无跨区访问，或优先访问本可用区实例。
