高可用架构的设计方法
概述
高可用(High Availability)，简称HA，是衡量IT系统服务质量的一个极其重要的参考，高可用一直是IT系统设计中需要重点关注的点。本文总结高可用架构中的一些关键设计思想。
衡量指标SLA
SLA是衡量网站服务可用性的一个关键指标，现在互联网公司一般以X个9来表示在系统1年时间的使用过程中，系统可正常使用时间与总时间（1年）之比，9越多代表全年服务可用时间越长、服务更可靠、停机时间越短，反之亦然。
一般而言，如果系统达到4个9就非常优秀了，需要在设计上做足功夫。
冗余
冗余是构建高可用的重要手段。其核心思想是对分布式系统中的节点进行备份。备份会分为冷备和热备。
-
冷备，一般会有主数据中心和备数据中心，正常情况下是主数据中心提供业务服务，备份中心不会有提供业务服务，而是会定期从主数据中心进行备份（非实时备份），也就是说如果主数据中心出现故障，业务也就中断了，需要人工进行干预，将流量从主数据中心切换到备数据中心。
-
热备，主要是对主数据中心进行实时性的备份，以保证在主数据中心出现故障后可以及时的切换，让用户不受影响的继续使用。 关于主数据中心到备数据中心的复制方式，分为同步和异步两种分式。
- 同步方式，当主节点处理完请求后，会同步向多个备节点实时备份数据，只有所有节点数据同步完成，主节点才会向客户端返回成功。这种方式对可用性有较大损耗，一般不推荐使用，
- 异步方式，当主节点处理请求后，会向客户端返回成功，同时会异步触发向多个备节点实时备份数据。该情况下，主备节点的数据会存在数据不一致或者延时，业务上需要能容忍一定程度的数据延迟。互联网系统一般会采用这种方式。
从备节点的工作方式划分，又可以分为双机互备和双机热备。
- 双机热备，从狭义上讲是使用互为备份的两台服务器共同执行同一服务，在正常情况下，工作机为应用系统提供服务，备份机监视工作机的运行情况，出故障时备机可迅速接管服务。
- 双机互备，是指主机和备机互为备份，备机上运行与主机不同的应用，例如两台server安装相同的系统、应用软件，主机备机同时工作，主机跑ORACLE，备机跑IIS，任意一台服务器故障时，所有服务会自动切换到正常的服务器上。
集群
集群是相对单机而言的，集群部署是分布式系统的典型特征。集群的作用其实就是分流，这里面不得不提核心的分流技术。
负载均衡
分为硬件负载和软件负载。
- 硬件负载：通过硬件来进行分流，常见的硬件有比较昂贵的F5和Array等商用的负载均衡器，它的优点就是有专业的维护团队来对这些服务进行维护、缺点就是花销太大，一般在互联网系统较少使用，主要用于金融行业的核心服务；
- 软件负载：通过软件实现分流，如Nginx/LVS/HAProxy的基于Linux的开源免费的负载均衡软件，这些都是通过软件级别来实现，费用非常低廉。
按所处OSI模型的工作层级，可分为7层负载和4层负载。
- 7层负载，是指工作在网络7层，基于URL等应用层信息的负载均衡，主要代表有Nginx。
- 4层负载，就是基于IP+端口的负载均衡，主要代表有LVS。
DNS
Domain Name System，“域名系统”的英文缩写，是一种组织成域层次结构的计算机和网络服务命名系统，它所提供的服务是用来将主机名和域名转换为IP地址的工作。一般大型网站的域名，背后会绑定多个vipServer的地址，DNS可以通过智能域名解析系统，返回离用户最近的vipServer 的ip。
容错
容错能力也是影响IT系统可用性的一个关键要素。
- 狭义的容错，一般会在设计上体现在以下方面:
- 对用户的输入进行尽早的校验，不信任外部的输入。
- 程序中尽可能的考虑边界及异常的情况。
- 广义的容错应该是两个具有明确边界的事物（如服务间，系统间）交互时候针对可能发生的一切主客观异常情况的防御性手段。常见的容错机制有failsafe、failback、failover、failfast。
failfast
快速失败，尽可能的发现系统中的错误，使系统能够按照事先设定好的错误的流程执行，避免资源耗尽或积压导致系统滚雪球式崩溃。我们通常讲的熔断就是这个思想。
failover
失效转移，它和前面提到的冗余备份关联很紧密。当主要组件异常时，其功能迅速转移到备份组件。MYSQL的双主模式、Zookeeper的自动选举、Redis的哨兵模式，都是基于这种思想，目的是尽量减少部分节点故障对用户服务的影响
failback
自动恢复，是相对failover而言的，簇网络系统（有两台或多台服务器互联的网络）中，由于要某台服务器故障进行维修，需要网络资源和服务暂时重定向到备用系统。在此之后将网络资源和服务器恢复为由原始主机提供的过程，称为自动恢复。一般依赖心跳探测技术来实现自动恢复，例如dubbo服务中的应用实例出现down机后，在服务恢复后会自动注册到config server，重新对外提供服务。
failsafe
失效安全，即在故障的情况下也不会造成伤害或者尽量减少伤害。并非所有的故障对用户都是致命的，当这类非关键的故障出现时可以忽略，因为这种故障不会造成损失或损失在可接受范围内。
多活
双活/多活架构，关键点是指不同地理位置上的系统都能够提供服务。“活”是指实时提供服务，与“活”对应的是字是“备”——备是备份，正常情况下对外是不提供服务或只提供部分服务（例如DB读写分离），如果需要提供服务，则需要大量的人工干预和操作，花费大量的时间才能让“备”变成“活。
实现多活有较高的成本，要考虑数据一致性、网络延时问题。
常见的多活方案有同城双活、两地三中心、三地五中心、异地多活等多种技术方案，不同多活方案技术要求、建设成本、运维成本都不一样。
同城双活
是在同城或相近区域内建立两个机房。同城双机房距离比较近，通信线路质量较好，比较容易实现数据的同步复制 ，保证高度的数据完整性和数据零丢失。同城两个机房各承担一部分流量，一般入口流量完全随机，内部RPC调用尽量通过就近路由闭环在同机房，相当于两个机房镜像部署了两个独立集群，数据仍然是单点写到主机房数据库，然后实时同步到另外一个机房。
该架构优点是方案简单、成本较低、网络延时小，缺点是由于双机房都在同城，所在城市出现网络故障或自然灾害时，服务可用性无法保障。
两地三中心
指 同城双中心 + 异地灾备中心。异地灾备中心是指在异地的城市建立一个备份的灾备中心，用于双中心的数据备份，数据和服务平时都是冷的，当双中心所在城市或者地区出现异常而都无法对外提供服务的时候，异地灾备中心可以用备份数据进行业务的恢复。
该架构的优点是相比同城双活，增加了异地灾备能力；缺点是异地的备份数据中心是冷的，出故障时异地机房是否能顺利接管流量是个大问题。
异地多活
异地的一个核心问题是物理距离带来的延时，因此要避免一次请求在异地的多个机房之间流转，因此异地多活的核心是单元化，要保证单次请求在一个固定机房内封闭。
单元化，在技术上的核心挑战在于流量路由和数据同步。这里还需注意，有些应用和数据是没法单元化的，因此还会衍生出中心机房和单元机房的概念，对于没法单元化的数据必须在中心机房。 阿里的淘宝是国内最早完整成功实施单元化的系统，其在全球化部署上也有较多成功的实践，在此就不展开了。
去中心化
在一个分布有众多节点的系统中，每个节点都具有高度自治的特征。节点之间彼此可以自由连接，形成新的连接单元。任何一个节点都可能成为阶段性的中心，但不具备强制性的中心控制功能。节点与节点之间的影响，会通过网络而形成非线性因果关系。去中心化架构的特征：
- 去中心化，不是不要中心，而是由节点来自由选择中心、自由决定中心。
- 任何中心都不是永久的，而是阶段性的
- 任何中心对节点都不具有强制性
常见的中心化设计：
- ESB
- 单体系统
- 网关
常见的去中心化设计：
- DUBBO、MESH等
- 用SDK替代服务