高并发系统高可用设计方案(一)

什么是高可用

互联网应用是面向大众的应用系统，他们可能会随时会被使用，那么应用就必须要保持随时可用，也就是我们常说的7x24小时可用，但是互联网应用有可能会遇到硬件故障，软件故障等多种问题，可能导致服务的不可用，所以要想保证服务100%可用是一件几乎不可能实现的事情。所以业界通常用多少个9来说明互联网应用的可用性，比如说某宝的可用性4个9,4个9是说服务可用性是99.99%可用，也就是说某宝的服务可以实现在运行时间内只有0.01%不可用，换句话说，当遇到上述的故障后，可在0.01%的时间内解决。如果以年为运行时间单位的化，那么不可用时间就是53分钟(3652460*0.01%)不同应用的可用性差别主要就体现在面对各种故障时，高可用设计做的是否足够好。

目前系统架构设计方面常用的高可用设计方案主要有以下几种：解耦，隔离，异步，备份，重试，熔断，补偿，降级，限流，多活等。下面我们逐一讨论以下。

解耦

我们都知道系统耦合度过高时软件设计的万恶之源，也是造成系统可用性的罪魁祸首，以为一个高度耦合的系统，牵一发动全身，任何微小的改动都可能导致意想不到的bug和系统崩溃，连最基本的功能维护都很吃力，更别提什么高可用了。

看整个软件的进化史，就是一部软件开发解耦的历史，各种编程框架的出现也几乎都是为了同一个目标，使公用的基础技术开发和业务功能开发进行解耦，以Web服务器为例，它是HTTP协议处理与业务开发解耦，开发者不用关系网络通信协议的处理，只需要关注请求处理和相应对象构建即可。而我们常用的MVC框架进一步将视图逻辑和业务逻辑解耦，使前后端进一步分离。

常用的低耦合原则原则主要有两种：
组件的低耦合原则：无循环依赖原则，即技术组件之间不能循环依赖，不能 A 依赖 B，B 又依赖 A；稳定依赖原则，即被依赖的组件尽量稳定，尽量少因为业务变化而变化；稳定抽象原则，即要想使组件稳定，组件就要更加抽象。

面向对象的低耦合原则：开闭原则，即对修改封闭、对扩展开放，对象可以扩展新功能，但是不能修改代码；依赖倒置原则，即高层对象不能依赖低层对象，而是要依赖抽象接口，而抽象接口属于高层；接口隔离原则，不要强迫使用者依赖它们不需要的方法，要用接口对方法进行隔离。

隔离

如果说解耦是逻辑上的分割，那么隔离就是物理上的分割。即将低耦合的组件进行独立部署，将不同组件在物理上隔离开来。每个组件有自己独立的代码仓库；每个组件可以独立发布，互不影响；每个组件有自己独立的容器进行部署，互不干扰。所以，隔离就是分布式技术在业务上的应用，最常见的就是我们前面案例中也多次使用的微服务技术方案。微服务将一个复杂的大应用（单体架构系统）进行拆解，拆分成若干更细粒度的微服务，这些微服务之间互相依赖，实现原来大应用的功能逻辑。然后将这些微服务独立开发和发布，独立部署，微服务之间通过 RPC（远程过程调用）进行依赖调用，就是微服务架构。隔离使得系统间关系更加清晰，故障可以更加隔离开来，问题的发现与解决也更加快速，系统的可用性也更高。不过，还要强调一下，隔离必须在低耦合的基础上进行才有意义。如果组件之间的耦合关系千头万绪、混乱不堪，隔离只会让这种混乱更雪上加霜。

异步

异步可以认为是在隔离的基础上进一步解耦，将物理上已经分割的组件之间的依赖关系进一步切断，使故障无法扩散，提高系统可用性。异步在架构上的实现手段主要是使用消息队列。比如用户注册的场景。新用户提交注册请求后，需要给用户发送邮件，发送短信，保存数据库，还要将注册消息同步给其他产品等等。如果用微服务调用的方式，那么后续操作任何一个故障，都会导致业务处理失败，用户无法完成注册。使用消息队列的异步架构，新用户注册消息发送给消息队列就立即返回，后续的操作通过消费消息来完成，即使某个操作发生故障也不会影响用户注册成功。如下图：

备份

备份冗余，是解决高可用的最基本的手段，即一个服务部署在多个服务器上，一份数据冗余备份多份，当一个服务出现故障或者一份数据丢失，还有其他服务可以提供，还有其他数据提供支持。但是这里有一个比较重要的机制，就是故障转移，也就是，能够感知到服务故障，数据丢失后，将请求转发到其他服务上，访问访问其他数据。
常用的故障转移的手段是负载均衡，其实负载均衡不仅可以实现高可用，还是实现呢高性能的主要手段。在一个多备份的服务集群中，当一个服务出现故障后，通过负载均衡，可以将请求转移到其他健康的服务上，具体如下图：

由于应用服务器上只运行服务，不存储数据，通常来说这些服务都是无状态的，请求转发到集群中其他服务器上，处理结果是相同，对于存储数据的服务器，如数据库。互相备份的服务器之间要能通过数据同步保证数据的一致性。主从同步的示意图：

多活

多活，即异地多活，在多个地区建立数据中心，并都可以对用户提供服务，任何地区级的灾难都不会影响系统的可用。异地多活最极端的案例，是某应用准备将自己的服务器发射到太空，即使地球毁灭也能保证系统可用。异地多活的架构需要考虑的重点是，用户请求如何分发到不同的机房去。这个主要可以在域名解析的时候完成，也就是用户进行域名解析的时候，会根据就近原则或者其他一些策略，完成用户请求的分发。另一个至关重要的技术点是，因为是多个机房都可以独立对外提供服务，所以也就意味着每个机房都要有完整的数据记录。用户在任何一个机房完成的数据操作，都必须同步传输给其他的机房，进行数据实时同步。数据库实时同步最需要关注的就是数据冲突问题。同一条数据，同时在两个数据中心被修改了，该如何解决？某些容易引起数据冲突的服务采用类似 MySQL 的主主模式，也就是说多个机房在某个时刻是有一个主机房的，某些请求只能到达主机房才能被处理，其他的机房不处理这一类请求，以此来避免关键数据的冲突。

总结

上文介绍了高可用方案，在系统架构设计过程中的使用，对于高可用系统中，服务间交互过程中的高可用手段，我们放在下一篇文章高并发系统高可用设计方案(二)中讨论。