构建高可用可伸缩系统设计的一些方法论

本文提供一些方法论，希望这些方法论能够指导设计一个高可用的系统架构。后面有新的思考会持续更新

一、服务高并发设计

我们通常说的高并发是通过一定的设计提高系统可以并行处理很多很多请求。

常用用来衡量的指标包括几类:

1. 响应时间
2. 吞吐量（QPS）
3. 并发用户数

高并发系统设计的方法论上可以从两个方面入手：垂直扩展（Scale Up）和水平扩展（Scale Out）。垂直是提升单机的处理能力，水平扩展可以线性提升系统性能

1、应用层原则

1、无状态

应用设计应该是无状态，那么应用的扩容就比较容易，应用就可以无限扩容。

2、拆分

系统设计根据业务不同的维度对系统进行拆分。一般可以按照下面几个维度拆分

业务维度：以一个完整的业务系统作为拆分维度。比如收银系统、订单系统、账号系统、优惠券系统

功能维度：一个完整的业务系统作为基础，对业务系统进行功能维度的拆分。比如优惠券系统，有发券服务、券认领服务、券核销服务等

读写维度：按数据的读写维度对系统进行拆分，可以以业务维度的读写，也可以以功能维度的读写。比如按照订单系统，对订单系统进行订单读系统、订单写系统；优惠券的券认领服务，可以拆分为券认领写服务、券认领读服务

切面维度：与业务功能不耦合的系统可以独立出来，形成一个切面。例如权限系统

3、服务化

不用业务体量，发展到一定程度后可以选择不同的服务部署方案。

服务化程度：进程内部服务、单机远程服务、集群远程服务。服务程度程度不同，复杂程度不同，需要不同程度的服务治理。如重试、路由、限流、隔离、熔断、降级、故障转移、回滚等。

4、并行化

系统初始阶段，为快速完成功能迭代。一般会将系统按流程一步一步串行执行。当业务发展到一定程度后，可以将一些任务从串行化转向并行执行。

2、数据层原则

1、数据异构

这里的数据异构指的是不同维度的数据查询请求，需要聚合多个表，可提前生成。对于异构数据的采集可以采用监听MQ或者监听Mysql等方式要获取。

在设计数据库表时，尽量单表查询，可以在服务层做依赖。

数据一致性设计为强一致性还是弱一致性

2、缓存

缓存可以说是解决读服务的万能钥匙。从客户端缓存、CDN缓存、接入层缓存（如Nginx proxy_cache等）、应用缓存（如Tomcat内的进程缓存等）、数据层缓存（如Redis之类）

3、MQ

解耦应用。复杂的业务流程一定会出问题，可以利用MQ将部分复杂的流程异步化，简化同步的流程。消息队列还可以当做流量缓存，做流量削峰。

二、服务高可用设计

高可用服务设计是服务可以7*24h不间断的提供服务。比如我们常说的服务可以用性99.99%。

例如系统每运行100个时间单位，会有1个时间单位无法提供服务，我们说系统的可用性是99%。再如一些服务高可用目标是4个9，也就是99.99%，这就意味着，系统的年停机时间为8.76个小时。

高可用设计方法论上可以从两个方面入手：一是避免单点；二是故障恢复

1、降级

降级的最大原则是保证核心服务可以用，即使服务处于亚健康的状态、服务有损，核心服务也能正常运行。

1. 开关降级：一是自动开关，这种降级方式要设立好降级预案，采集各类降级指标，包括业务指标和系统运行环境指标（例如：CPU、内存、某个支付通道的成功率等）；二是手工开关，这类降级要做的是设立好精准的告警。
2. 读服务降级：出问题后一个接口从数据库读改成读缓存，或者读一些静态数据，前提是业务上可以容忍这类降级。
3. 写服务降级：写服务大多数场景比较难做降级。可以控制写流量、写数据库改写成MQ或者缓存之类。
4. 系统降级：业务中非核心的系统，流量大后可以关掉此类系统，将最好的资源留给最核心的服务。

2、熔断

熔断本质上也是一种降级，当某个服务不可用时，切断与其连接的链路，保证核心流程正常服务。

3、隔离

隔离主要通过将资源隔离开，其目的是某个系统发生问题后，避免事故传播扩散，以大小。

上述说的资源泛指以下几类：

1. 线程
2. 进程
3. 集群
4. 机房
5. 业务
6. ......

在高并发设计中也谈到了服务拆分，其实也是服务隔离的一类。所以通过线程隔离、进程隔离、集群隔离、机房隔离、业务系统（读写服务、按功能拆分）等进行隔离，防止某个服务扩散故障。

4、限流

限流通过对请求访问限速，在一定的时间窗内限定通过的请求来保护系统。

限流的算法有令牌桶算法和漏桶算法。计数器也可以

跟缓存一样，可以从客户端、CND、接入层、应用层、业务接口级别限流、数据层进行限流等。

5、容灾

容灾与隔离的方法有点类似，但两者的目的不同。容灾目的是当多个系统或者机房down集后，仍然保证系统还是可用。

接入层、应用层、数据层各个服务进行处理，异地多活，同城双机房或多机房，等

6、快速回滚

在解决系统故障层面，最快速最有利的解决办法是将程序运行回滚动上一个稳定的版本。

参考资料：

1. http://www.csdn.net/article/2015-10-27/2826042========================================================
2. 张开涛《亿级流量网站架构核心技术》
3. https://blog.coding.net/blog/architecture-concept-and-practice-from-Google
4. http://ifeve.com/%E5%A6%82%E4%BD%95%E5%BB%BA%E8%AE%BE%E9%AB%98%E5%8F%AF%E7%94%A8%E7%B3%BB%E7%BB%9F/