后台管理服务项目能够 区划为两大类，有情况和无状态。高可用性针对无状态的运用而言是非常简单的，无状态的运用，只必须根据 F5 或是一切代理商的方法就可以非常好的处理。后文叙述的主要是对于有情况的服务项目开展剖析。
服务器端开展情况维护保养主要是根据硬盘或运行内存开展储存，例如 MySQL 数据库查询，redis 等内存数据库。除开这二种种类的维护保养方法，也有 jvm 的运行内存的情况保持，但jvm的情况生命期一般很短。
1、高可用性的一些解决方法
高可用性，从发展趋势看来，大概历经了这好多个全过程：
在聊外地多活的情况下，還是首先看一些别的的计划方案，这有益于大家了解许多设计方案的原因。
冷备
冷备，根据终止数据库查询对外开放服务项目的工作能力，根据文档复制的方法将数据信息迅速开展备份数据存档的实际操作方法。简单点来说，冷备，便是拷贝，在 linux 上根据 cp 指令就可以迅速进行。能够 根据人为因素实际操作，或是定时执行脚本制作开展。有以下益处：
之上的益处，针对之前的手机软件而言，是非常好的方法。可是针对目前的许多情景，早已不太好用了，由于：
双机备份
热备，和冷备比起來，关键的区别是无需关机，一边备份数据一边出示服务项目。但复原的情况下還是必须关机的。因为大家探讨的是和储存有关的，因此 不将共享资源硬盘的方法当作双机备份。
Active/Standby方式
等同于1主1从，主连接点对外开放出示服务项目，从连接点做为backup。根据一些方式将数据信息从主连接点同歩到从连接点，当常见故障产生时，将从连接点设定为工作中连接点。数据库同步的方法能够 是偏手机软件方面，还可以是偏硬件配置方面的。偏手机软件方面的，例如mysql的master/slave方法，根据同歩binlog的方法；sqlserver的定阅拷贝方法。偏硬件配置方面，根据磁道和硬盘的阻拦等镜像系统技术性，将数据信息拷到此外的硬盘。偏硬件配置的方法，也被称为数据信息级容灾；偏手机软件的，被称为运用级容灾。下文谈得大量的是运用级容灾。
两机互备
实质上還是Active/Standby，仅仅互为主导进而已。两机互备并不可以工作中于同一个业务流程，仅仅在网络服务器视角看来，更强的榨取了能用的資源。例如，2个业务流程各自有库A和B，根据2个设备P和Q开展布署。那麼针对A业务流程，P主Q从，针对B业务流程，Q主P从。总体上看上去是2个设备互为主导备。这类构架下，读写分离是非常好的，单写多读，降低矛盾又提升了高效率。
别的的高可用性计划方案还能够参照各种数据库查询的多种多样布署方式，例如mysql的主从关系、双主多从、MHA；redis 的主从关系，卫兵，cluster 这些。
前边提到的几类计划方案，基础全是在一个局域网络内开展的。市场拓展到后边，拥有同城网多活的计划方案。和前边比起來，不信任的粒度分布从设备变为了主机房。这类计划方案能够 处理某一IDC机房总体挂了的状况（断电，断开连接等）。
同城网双活实际上和上文提及的双机备份沒有实质的差别，仅仅“间距”更远了，大部分還是一样（同城网专线运输网络速度還是迅速的）。双机备份出示了容灾工作能力，两机互备防止了太多的資源消耗。
在编程代码的輔助下，有的业务流程还能够保证真实的双活，即同一个业务流程，双主，另外出示读写能力，只需解决好矛盾的难题就可以。必须留意的是，并非是全部的业务流程都能保证。
业内大量选用的是两地三中心的作法。远端备份数据主机房能更高的出示容灾工作能力，能更强的抵御地震灾害，恐袭等状况。双活的设备务必布署到同城网，间距更长远的大城市做为容灾主机房。容灾主机房不是对外开放出示服务项目的，只做为备份数据应用，产生常见故障了才切总流量到容灾主机房；或是是只做为备份数据。缘故关键取决于：间距很远，网络延时很大。
图1 两地三中心
如圖，客户总流量根据web服务，将服务项目A的总流量发送至IDC1，网络服务器集A；将服务项目B的总流量发送至IDC2，网络服务器B；另外，网络服务器集a和b各自从A和B开展同城网专线运输的数据库同步，而且根据远距离的外地专线运输往IDC3开展同歩。当一切一个IDC当机后，将全部总流量切到同城网的另一个IDC机房，完成了failover。
当大城市1产生大规模常见故障时，例如发生地震造成 IDC1和2另外停止工作，则数据信息在IDC3得到保护。另外，假如web服务依然合理，还可以将总流量所有分享到IDC3中。但是，这时IDC3主机房的间距十分远，网络延时越来越很严重，一般客户的感受的会遭受比较严重危害的。
图2 两地三中心主从关系方式
图中是一种根据Master-Slave方式的两地三中心平面图。大城市1中的2个主机房做为1主1从，外地主机房做为从。还可以选用同城网双主 keepalived vip的方法，或是MHA的方法开展failover。但大城市2不可以（最好是不必）被挑选为Master。
同城网双活能够 解决绝大多数的容灾状况，可是遇到大规模断电，或是洪涝灾害的情况下，服务项目仍然会终断。对上边的两地三中心开展更新改造，在外地也布署前面通道连接点和运用，在大城市1终止服务项目后将总流量切到大城市2，能够 在减少客户体验的状况下，开展退级。但客户的感受降低水平十分大。
因此 大部分的互联网公司选用了外地双活的计划方案。
图3 简易的外地双活平面图
图中是一个简易的外地双活的平面图。总流量历经LB后派发到2个大城市的集群服务器中，集群服务器只联接当地的数据库集群，仅有当当地的全部数据库集群均不可以浏览，才failover到外地的数据库集群中。
在这类方法下，因为外地网络问题，双重同歩必须花销大量的時间。更长的同步时间可能造成 更为比较严重的货运量降低，或是发生数据信息矛盾的状况。货运量和矛盾是2个对立面的难题，你需要在这其中开展衡量。比如，为了更好地处理矛盾，引进分布式锁/分布式事务；为了更好地处理做到高些的货运量，运用中间状态、不正确再试等方式，做到最后一致性；减少矛盾，将数据信息开展适当的sharding，尽量在一个连接点中进行全部事务管理。
针对一些没法接纳最后一致性的业务流程，饿了么外卖选用的是下面的图的方法：
针对某些一致性规定很高的运用，大家出示了一种强一致的计划方案（Global Zone），Globa Zone是一种跨主机房的读写分离体制，全部的写实际操作被定项到一个 Master 主机房开展，以确保一致性，读实际操作能够 在每一个主机房的 Slave库实行，还可以 bind 到 Master 主机房开展，这一切都根据大家的数据库查询浏览层（DAL）进行，业务流程基础无认知。
——《饿了么异地多活技术实现（一）总体介绍》
换句话说，在这个地区是不可以开展双活的。选用主进而并不是双写，当然解决了矛盾的难题。
事实上，外地双活和外地多活早已很像了，双活的构造更加简易，因此 在程序流程构架上无需做太多的考虑到，只必须做传统式的过流保护，failover等实际操作就可以。但实际上双活仅仅一个临时性的流程，最后的目地是转换到多活。由于双活除开有数据信息矛盾上的难题出现意外，还没法开展横着拓展。
图4 外地多活的平面图
依据外地双活的构思，我们可以绘制外地多活的一种平面图。每一个连接点的出度和入度全是4，在这类状况下，一切连接点退出都不容易对业务流程有影响。可是，充分考虑间距的难题，一次写实际操作将产生更高的時间花销。時间花销除开危害客户体验之外，还产生了大量的数据信息矛盾。在比较严重的数据信息矛盾下，应用分布式锁的成本也更高。这将导致的复杂性升高，货运量降低。因此 图中的计划方案是没法应用的。
追忆一下我们在处理网状结构网络拓扑结构的情况下是怎么优化的？引进正中间连接点，将网状结构改成星状：
图5 星状的外地多活
更新改造为图中后，每一个大城市退出都不容易对数据信息导致危害。针对原来要求大城市的总流量，会被再次 LoadBalance 到新的连接点（最好LB到近期的大城市）。为了更好地处理网络信息安全的难题，大家只必须对于管理中心连接点开展解决就可以。可是那样，针对区域中心城市的规定，比别的大城市会高些。例如修复速率，备份数据一致性等，这儿临时不进行。大家先假设管理中心是彻底安全性的。
如果我们早已将外地多活的业务流程布署为图中的构造，非常大水平解决了数据信息四处同歩的难题，但是仍然会存有很多的矛盾，矛盾的状况能够 简易觉得和双活类似。那麼还有没有更强的方法呢？
这儿能够 关系一下饿了么外卖的 GlobalZone 计划方案，整体构思便是“去分布式系统”，换句话说将写的业务流程放进一个连接点的（同城网）设备上。阿里巴巴是那么思索的：
阿里巴巴理想化中的外地多活构架
事实上我猜想许多业务流程也是依照图中去完成的，例如滴滴顺风车业务流程这类，全部的业务流程全是按城市划分开的。客户、买车人、到达站，她们的地理坐标一般全是在同一个大城市的。单独大数据中心并不一定和别的大数据中心开展数据信息互动，仅有在统计分析出表格的情况下才必须，但表格不是太重视实用性的。那麼，在这类状况下，全国各地的业务流程实际上能够 被非常好的sharding的。
可是针对电子商务这类繁杂的情景和业务流程，依照前文写的方法开展sharding早已没法满足需求了。由于业务流程线比较复杂，数据信息依靠也比较复杂，每一个大数据中心互相开展数据库同步的状况在所难免。淘宝网的处理方法和大家分割微服务架构的方法有点儿相近：
淘宝网依照模块分割的外地多活构架
留意看图片中的数据库同步箭头符号。以买卖模块为例子，归属于买卖模块的业务流程数据信息，将与管理中心模块开展双重同歩；不属于买卖模块的业务流程数据信息，单边从管理中心模块同歩。管理中心模块担负了最繁杂的业务场景，业务流程模块担负了相对性单一的情景。针对业务流程模块，能够 开展延展性伸缩式和容灾备份；针对管理中心模块，拓展工作能力较弱，可靠性规定高些。能够 遇上，绝大多数的常见故障都是会发生在管理中心模块。
依照业务流程开展模块分割，早已必须对编码和构架开展完全的更新改造了（很有可能这也是为什么阿里巴巴要先从双活再切出多活，历经三年）。例如，业务流程分拆，依靠分拆，网状结构改星状，分布式事务，缓存文件无效等。除开针对编号的规定很高之外，对检测和运维管理也是有十分大的挑戰。
这般繁杂的状况，怎样开展自动化技术遮盖，怎样开展演习，怎样更新改造生产流水线。这类等级的容灾，并不是一般企业敢做的，产出率都不正相关。但是還是能够 把这类情景作为大家的“假想敌”，去思索我们自己的业务流程，将来会如何发展趋势，必须保证哪些等级的容灾。相对来说，饿了么外卖的多活计划方案很有可能更合适大部分的公司。
文中仅仅根据绘图的方法开展了简易的叙述，实际上外地多活是必须许多很强劲的基本工作能力的。例如，传输数据，数据信息校检，数据信息实际操作层（简单化手机客户端操纵写和同歩的全过程）等。
