软件架构之高可用性设计 _软件架构

现在而今眼目下，互联网越来越发达，大家不管是几乎每天24小时不离手的手机，还是工作时每天要打开的电脑，还是我们使用的各种社会工具和衣食住行的方方面面，各种软件应用已经成为我们生活中必不可少的一部分。软件的功能是否能满足需求，是我们关心的首要问题，软件是否稳定，也是一个重要的指标，也就是软件系统的可用性如何，在遇到一些问题时，系统的容错性如何，是否仍然能够对外提供服务，以及服务的效率如何，是迅速就能返回还是要等待很久。
回顾刚过去的2019年一年，全球大型互联网公司发生了数十起宕机事故，google、Microsoft、Amazon 、Facebook、阿里、腾讯等无一幸免，短则数分钟，长则数小时，有的是天灾，有的是人祸。对于用户上亿的商业应用来说，哪怕是一分钟的宕机，损失都非常巨大，一个中等严重的故障可能会让你损失一辆车，一个outage可能就会让你损失数座房子了。腾讯2018年宕机4小时，据估算损失了5000多万。

文章插图

如何衡量软件的可用性呢？
其度量方式，是根据系统损害、无法使用的时间，以及由无法运作恢复到可运作状况的时间，与系统总运作时间的比较。计算公式为:
A=MTBF/(MTBF+MDT)
A（可用性），MTBF(平均故障间隔)，MDT(平均修复时间)
可用性为99.999%的系统，一年故障时间为5分15秒；可用性为99.99%的系统，一年故障时间为5分34秒；可用性为99.9%的系统，一年故障时间为8小时46分。
在线系统和执行关键任务的系统通常要求其可用性要达到5个9标准(99.999%) 。
当然，除了这个数据之外，我们也要看宕机发生在什么时候，才能综合评估事故影响的严重性，造成的损失到底有多大。当我们不得不主动的关闭或重启一些服务的时候，如何把影响减到最小。
软件应用一旦进入生产系统，接入了大量的用户，我们就得尽量保证它是24小时可用的，为用户提供不间断的服务。软件的高可用性（High availability -- HA）,是一项非功能特性，在大型产品的架构设计阶段就需要专门纳入进来考虑。软件系统会划分为多个不同的模块，重要的组件或模块，都需要列出HA的Feature实施计划。
为了实现软件系统的高可用性，都有哪些关注点和技术手段呢？
1. 冗余设计和Fail over
冗余设计的核心目的是为了避免单点故障导致整个系统不可用，在不同的层级增加冗余，当单点故障发生时，可动态的把服务切换到正常的上面，从而能够继续为用户提供服务。冗余设计可以从几个方面进行考量：
1. 地理环境，如果你的所有服务器都在同一个地方，一场洪水或地震将让你的整个系统和数据化为乌有。大型系统通常都会把服务器或数据中心分布在不同的地域。这将有助于提高系统的可用性。
2.硬件，高可用的服务器必须对诸如停电，硬件损坏(如硬盘损坏，网卡损坏)等具有承受能力。
3. 软件，从操作系统到应用程序本身的整个软件栈，都需要设计来能应对非预期的失败而必须重启的情况。
4.数据，由于硬盘故障带来的数据丢失和数据不一致的情况，如何处理。高可用性系统必须要把故障情况下的数据安全考虑进来。
5.网络，非预期的网络中断是系统可能遇到的另一个问题。网络冗余策略也是非常有价值的。
先来看看软件设计层面应当如何考虑冗余，一个比较典型的B/S 架构的应用如下图所示。

文章插图

我们在其每一层，都可以做冗余处理。
在网关层，我们可以配置多个网关，用keepalived管理起来，给它们分配一个浮动IP,当主网关出问题时，我们可以把浮动IP分配给备用网关，这样仍然可以继续对外提供服务。
在Web应用层，可以配置多个web后端，比如使用Nginx做网关层的反向代理时，它可以配置多个web后端，并且能够检测到多个后端的存活性，当一个web服务挂了时，nginx可以自动进行故障转移，将流量迁移到其他的web服务上。
【软件架构之高可用性设计】业务服务层也可以实现冗余，在web应用层通过建立服务连接池来与下游的服务建立多个连接，每次请求可以随机的选择连接来访问下层的服务。当某一个service挂了的时候，连接池的管理器能够检测到，并自动进行故障转移。
大型系统的服务层下通常会有一个缓存层，数据缓存也可以实现冗余来达到高可用，