前言
衡量一个系统设计好坏通常可以从性能，可用性，扩展性方面进行评价，围绕着这3个主题也诞生了一系列解决方案，今天我们就来梳理一下这个历程，并聊一聊异地多活。
单体应用
最初的应用都是部署在同一台服务器，此时的应用比较简单，部署发布通常手工或脚本完成，业务数据也存储在本地磁盘或本机的数据库，一旦出现磁盘损坏或者系统故障，服务不可用，数据完整性也得不到保障。
主从副本
为了解决单机宕机服务不可用问题，可以在另外一台服务器部署数据库作为从库，原来的数据库作为主库，主库可读写数据，从库备份数据也可以读数据。当主库出现故障，可以将从库提升为主库，这样就大大提高了业务的可用性。当然，也可以多在几个服务器部署多个从库，扩展业务可用性。
对于大多数体量不是很大的业务，这种设计已经足够了，但当业务发展起来后就要考虑更高级别的系统可用性。多个服务器在一个机房，如果机房出问题，比如断电，水灾等那服务照样要出问题，如果解决这个问题，这就要说到同城灾备。
同城灾备
冷备
为了防备一个机房出问题而导致宕机，可以在城市另一个机房做一套数据备份，两个机房之间用同城专线进行连接，这样一个机房出问题，数据还在，需要做的就是数据恢复。 当然，冷备也有缺点，恢复数据慢，恢复期间产生的数据会丢失，恢复期间服务也不可用，同时备机房只做备份也浪费资源，如何破，当然是在备机房部署一套完整的应用，随时准备切换。
热备
为了解决冷备的一些问题，可以在备机房部署完整应用，主机房做数据读写并同步到备机房，备机房数据只读，当主机房故障，立刻将CDN指向备机房，同时将备机房提升为主机房。
同城双活
同城灾备有一个问题，当主机房出故障切到备机房，但由于备机房是做备用的，平时并不使用，当切换流量时并不能保证不出问题，而且机房投入很大，平时只是放着岂不是浪费资源，那有没有好的方式既可以提高资源利用率，又能提高可用性呢，这就是同城双活要做的。
同城双活可以在流量入口处做一层负载，将一部分流量分配到备机房，从而测试备机房的稳定性和可用性，在这种架构下，主从机房都有流量，主机房可以读写数据，从机房读数据并同步主机房数据，系统实现了高可用。
两地三中心
同城双活的系统抗风险能力已经很强了，但还是有不可抗风险，因为机房都是在同一个城市，如果出现城市级别的不可抗力，如地震等，那该宕机的还得宕机，大的一些金融，政府机构会采用两地三中心。
两地指两个城市，三中心指三个机房，展开来说就是在同城双活的基础上在另一个城市部署一个机房，用于数据备份，也就是冷备，当然这种架构也会和同城灾备存在一样问题。
异地双活
将主机房和备机房分开部署在两个城市，是不是就是异地双活了呢，答案没这么简单。由于跨地域部署，机房间的通信成了最大问题，会存在很严重的网络延迟，对业务来说这是不可接受的，那要怎么办呢？ 要解决距离带来的延迟问题，那就就近访问，最好是本地的，可以根据用户的IP来决定访问哪一个中心，但是别忘了，我们其中一个机房是备用机房，并不能写数据，要满足要求就要搭建双主机房。Mysql是支持双主的，其他可能要通过中间件来实现，此时两个机房都提供服务，并且都可以读写数据，它们之间再实时同步数据。 当然，异地双活还有很多需要考虑的细节，比如数据怎么避免冲突，是按业务还是按地理路由啊等等，在次不再展开。
异地多活
再复杂的业务可能就要异地多活来解决了，异地多活就是把异地多活进行扩展，但有一个问题要考虑，多个中心之间互相同步数据会使架构变得很复杂，而且响应时间变长，解决方法就是把网状拓扑改为星形拓扑，部署一个公共中心节点，个分中心只和公共中心同步数据，层而简化部署。
总结
软件架构总是和业务相匹配的，好的架构不在于其有多先进而在于能否很好支撑业务，合适的才是最好的。从单机部署到异地多活，架构的演讲还是围绕着“高性能，高可用，可扩展”来展开的，本文只是简单讨论了一些典型架构模式，没有深入分析，希望对你有所帮助。
