原创声明
：本文系作者原创，谢绝个人、媒体、公众号或网站
未经授权
转载，违者追究其法律责任。
今日的互联网环境，已经是标准的大数据规模，各大主流互联网平台都是PB级别数据及准PB级。异地多活技术是随着互联网环境进步发展到PB量级后，出现并逐步完善的一种用于解决高并发、大流量、高可用、热灾备需求的分布式解决方案。近4、5年，随着互联网环境的不断进步，当前异地多活技术是仅次于微服务架构、区块链等领域之后的热门技术话题，并且已经逐渐形成一套稳定的分布式SOA化理论。本文参考当前全球主流互联网平台资料，整合异地多活技术进化过程中的来龙去脉。
一、数据中心(IDC)
电信部门利用已有的互联网通信线路、带宽资源，建立标准化的电信专业级机房环境，为企业、政府提供服务器托管、租用以及相关增值等方面的全方位服务，即是一种低于iaas的互联网基础环境设施服务。单IDC说就是为企业等提供服务器硬件、存储、宽带、链路监控、安全保障等软硬件服务的机房。一个IDC机房通常有如下拓扑结构：
二、光纤传输数据延迟问题
光的传输速度是
3.0×10^8m/s, 光纤中的数据传输速率远低于此，光纤传输延迟是互联网链路层的瓶颈。在IDC之间数据传输时更是如此，接下来讲到两地三中心方案、同城多活、异地多活等的底层方案，很大部分都是围绕解决数据传输延迟带来的问题。例如新浪微博北京的两个核心机房间延时在1ms左右，但北京机房到广州机房则有近40ms的延时。对比一下，微博核心Feed接口的总平均耗时也就在120ms左右。微博Feed会依赖几十个服务上百个资源，如果都跨机房请求，性能将会惨不忍睹等。
三、两地三中心技术方案
两地三中心方案是互联发展之初，主要用于解决银行、金融、金融级别等电算化平台的业务连续性保障(BCM)、数据灾备容灾等需求，以应对突发、致命性的灾难等问题,并且已经是政府指定的金融级系统的规范性灾备标准。直到现在，该方案虽然仍有很多不完善的地方及微升级方案，但仍是银行、金融等领域的标准灾备技术,如下是两地三中心技术方案的典型架构图:
这个架构方案在过去的20来年绝大多数解决过去互联网中的灾备等问题，满足银行、金融、政企等非高并发、强一致、强安全的业务连续需求。然而随着互联网数量级的提升，上述方案与现今的互联网环境高并发、高可用、大数据环境相对照，存在如下几个问题:
1. 冷灾备中心: 灾备中心是冷备份，在真正出现灾难性故障后，不能确定冷数据是否能及时恢复运行甚至及时恢复业务线
2. 浪费硬件资源，冷备份中心正常情况下始终全量备份，不对外提供业务，很可能是长期一直不使用的情况。
接下里的同城多活、异地多活就是为了尽可能减轻上述2个问题。
四、同城多活
传统两地三中心架构在互联网行业的早期实践成熟方案是同城多活。真正意思上的同城多活是指应用层多活和数据层同时多活，只有这2层多活，才能达到实际的流量切换与连续业务，当然在实施过程中从开发效率及商业目标等考虑，会使用一些伪同城多活的方案，如早期阿里为了应对双11购物，杭州机房与上海机房采用的就是伪同城多活，应用层多活，2个应用节点同时写一个机房数据，并且很好的解决双11大流量购物需求。同城多活里，同城应用可以跨机房写数据库，应用层面的多活就实现了。而在强化了应用层面的容错和故障处置手段之后，因为同城的数据传输延迟小，在主数据库故障时，应用可快速把主数据库切换到其他机房的从数据库。在这种机制下，不单可以实现数据库的多活，而且进一步实现了数据中心层面的同城多活，理论上任何一个数据中心中断都不会导致业务中断，切换过程也非常简单。
无论数据层多活还是伪同城多活，技术上基础关键问题都是高可用数据层支持和富有伸缩弹性的存储层，基于弹性的存储层，才能做良好的监控、运维、高效异常处理、运营等。
五、异地多活
异地多活是同城多活技术的高级阶段，上面提到，因为物理光纤的熟读传输限制，实际在同城使用的方案，几乎是不能完全使用在异地多活需求上。所谓异地多活，故名思义，就是在相距有一定远距离地点的数据中心有多个相同业务需求的交易平台，并且每个地点的交易平台都是用来支撑分担流量的。通常异地多活是跨地域的，而且距离一定要做到1000公里以上的范围。异地多活的每个多活数据中心都要承担用户的读写流量。如果只是备或只读业务来讲，作用不是很大。
异地多活，从整个业界的做法上来讲，主要有几家公司，比如Google、Facebook，这些是技术强悍切比较典型的，Google做到了全球多个数据中心，都是多活的。但是Google具体怎么做的，也没有多少人了解。另外就是Facebook，我们相对更了解一些，Facebook在做多个数据中心时，比如说美国和欧洲两个数据中心，确实都在支撑流量。但是欧洲的用户有可能需要访问美国的数据中心，当出现这种状况时，整个用户体验不好。国内目前将异地多活做成熟的公司比较多，像阿里的单元化异地多活、饿了么、新浪微博、京东购物等，都已经做得非常成熟。
如下是异地多活的拓扑图:
围绕上述的拓扑结构，所有程序员都要解决上述结构带来的问题，比如: 数据传输延时、请求延迟、消息延迟、专线、数据一致性、分布式事务、服务依赖、队列依赖、流量控制、部署便捷等等一系列问题及怎样解决。
六、异地多活的实施和运维成本
上面的章节我们提到了异地多活粗略的架构蓝图。今天的互联网，每个有一定规模的公司都在尽可能结合自己业务，实践自己的多活技术栈。互联网环境有一个很出名的定律，叫做墨菲定律(
Murphy's Law)：
1、任何事都没有表面看起来那么简单；
2、所有的事都会比你预计的时间长；
3、会出错的事总会出错；
4、如果你担心某种情况发生，那么它就更有可能发生。
其中第1、2条: "任何事情都没有表面看起来那么简单，所有的事都会比你预计的时间长"。即是描述了工程性项目的实施成本与时间成本，我想说的是，上面我们提到的异地多活设计蓝本虽然逻辑上很简单，但是我们的软件世界并不像自然社会，软件发展的当前阶段，围绕此多活蓝本去实施的成本远比设计成本多得多，一代代优秀的程序员在不断实践中总结这套设计理论，同时又不断从理论中去实践，努力构建出更稳定、更低成本的多活方案。
围绕多活技术，大致有如下比较大的实施和运维成本:
1.机房之间的延时。
2.专线问题: 机房专线成本巨大。同时单条专线的稳定性也很难保障，基本上每个月都会有或大或小的问题；
3.数据同步问题: MySQL如何做数据同步？HBase如何做数据同步？还有各种自研的组件，这些统统要做多机房数据同步。几十毫秒的延时，加上路途遥远导致的较弱网络质量（我们的专线每个月都会有或大或小的问题），数据同步最最大的挑战(不是之一)。
4.依赖服务部署问题: 如同阿里目前只做了交易单元的“异地双活”，微博部署时也面临核心服务过多依赖小服务的问题。将小服务全部部署改造成本、维护成本过大，不部署则会遇到之前提到的机房之间延时导致整体性能无法接受的问题；
5.运维体系问题: 服务部署没有流量引入就不能称为“双活”，而要引入流量就要求配套的服务和流程都能支持异地部署，包括预览、发布、测试、监控、降级等一系列高实施成本的运维改造方案。
七、结束语
多活的技术成本非常高，每家公司都不断在成本与业务之间综合平衡各种利弊，选择最好的方式服务业务。
总之， 多活技术并不能100%解决全部业务多活，只能尽量保证绝大部分用户的核心业务异地多活，希望学习者、实践者能尽可能评估到其中利弊，领会其中精粹。
现代多活方案常常会利用云计算平台的低部署和弹性运营成本与云计算平台搭建混合云环境，分布式多活数据中心与云计算建设的思路既有相同之处也有差别，云的形成可以基于数据中心的分布式技术，建设模型更接近互联网数据中心，而分布式多活数据中心的实现和实践门槛相对要低，用户在建设运维时更多的会关注于自身业务联系性的要求与业务的快速响应及IT建设的持续优化，对复杂的企业级应用提供更好的支撑，使得IT建设更多的基于自身现有资源和能力。总之使用混合方式，而不盲目追求先进，体现了企业对于自身IT建设的把握与未来方向的掌控，是大型企业数据中心、大型多活系统持续稳健前行的必经之路。
本文未讲述任何多活技术框架及技术细节，二从进化史的角度，讲述了多活发展各阶段的技术架构模型，希望能帮助更多学习和实践异地多活的技术者。
参考: