如果有一天，抖音微信微博支付宝淘宝都不可用了

对于互联网服务来说，关键业务7*24小时不间断的服务非常重要。作为一个享受互联网服务的人，你能想象到抖音微博七分钟无法加载、微信五分钟无法打开、支付宝3分钟无法支付的情况吗？简直无法想象，生活在微信、微博、QQ、抖音、支付宝、淘宝、美团外卖、滴滴打车的我们已经习惯了打开app就可以聊天、购物、刷视频、打车、点外卖了。而在这些服务时时可运行的背后，全都是一线大厂的开发人员、运维人员努力工作的保障。

 

那么一线大厂人员是如何保障系统高可用的呢？四个字：服务多活。所谓“活”指的是业务随时提供服务，多活是指业务在多个地方都可以随时提供服务。我们知道服务都是部署在服务器上，而服务器都是安装在机房内的。我们更知道，没有什么事情是万无一失的，机房也可能会不工作，比如机房断电、机房火灾、机房地震等等，所有的这些不可抗拒因素都会导致机房内所有的服务器崩塌，进而导致业务崩溃，因此我们需要服务多活。

 

服务多活如果落地到解决方案上，那便是同城双活架构、两地三中心架构、异地多活架构。

 

所谓同城双活，指的是在同城或相近区域内建立两个机房。这样的好处是机房与机房之间距离比较近，通信链路的质量很好，数据传输快，容易保障数据的一致性。在同城双活架构中，前端的请求数据来了之后，会根据请求所发起的地理位置进行就近分发，请求分发在最近的机房后，机房内的应用就互相调用，数据写入数据库，完成业务的请求。在应用所部署的机器集群有内有zookeeper集群，将机房内的生产者消费者节点数据实时双向同步，数据库集群的部署采取Master&Slave模式，通过读写分离，将读数据路由到就近机房内节点，写数据路由到master节点所在机房。如果有某个机房出现了故障，运维人员只需要改动路由方式将流量路由到另外一个机房即可。

 

同城双活架构的优点有两个，第一是服务同城双活、数据同城备份，保障了服务高可用、数据高一致性性，第二是架构比较简单，同城之间距离较近，网络通信质量好。但是也存在一些缺点，第一是数据库写数据的时候跨机房的调用增加了响应时间，会带来一定程度的用户体验影响，第二是如果该城市发生了地震火灾等情况，整个服务都会瘫痪。

 

所谓两地三中心，指的是同城双中心、一个异地灾备中心。这是同城双活架构的升级版，解决了如果同城发生了火灾地震等不可抗力因素时应用提供服务的情况。但其实也存在一个风险，就是灾备中心的数据都是“冷”的，平时只是定期同步了中心机房的数据，并没有真实的用户请求过来，如果真的到了同城双中心都无法对外提供服务的时候，灾备中心去进行业务的恢复，对外提供服务需要一定的耗时。

 

所谓异地多活，指的是在不同的地域有多个机房对外提供服务。在异地多活架构中，存在很多挑战，比如物理距离带来的延时、数据的一致性、数据的完整性等等。在异地多活架构中，我们采用了更巧妙的方法，即根据业务数据将业务应用分为三类，第一类是对延时不敏感但对数据一致性要求非常高的应用，第二类是对延时敏感但对数据一致性要求不高的应用，第三类是在一次操作内要完成所有业务操作的应用。在服务高可用方面，根据应用的特性进行不同的方案部署即可。在请求分发方面，为了保障用户请求都能正确进入自己所属的业务模块，我们在机房的入口都会部署一个网关，根据用户请求类型把流量分发到对应的模块。在数据同步方面，还是根据业务类型以及业务部署模式进行读写备份。

 

异地多活架构有三个优点、两个缺点。第一个优点是服务异地多活、数据异地多活，有多个地域的机器随时在提供服务，带来了容灾能力的大幅度提高。第二个优点是服务可以水平扩展，业务增长快，那么就多部署几个地域的机房就好了。第三个优点是防风险能力高，用户请求分发到了多个机房、地区，能避免断电火灾地震等情况带来的服务不可用，降低了故障影响范围。它的第一个缺点是部署和运维成本高，我们可以看到在应用分类、异地部署、数据同步上是多个地方多个机房多台服务器之间同时进行的。第二个缺点是跨地域、跨机房、跨服务之间的调用带来的延时。

 

至此，对于同城双活、两地三中心、异地多活我们就介绍完了。讲真的，我们生活在互联网时代，真的无法想象抖音微信微博支付宝淘宝都不能用了是什么样子？还好还好，有一个又一个的互联网后浪们为我们搭建了高可用的服务架构，保障了我们的正常互联网生活。如果你也是致力于服务互联网网民，那就赶紧加入吧～