深入理解互联网架构"高可用(HA)"

前言:
从进入这一行开始,“高并发、高可用”无论是在工作中,还是在各个博客中出现的频率都非常的高,最近跟我的小伙伴们在讨论一个项目的架构设计中就频繁的使用了这个名称。有的小伙伴可能刚接触互联网行业所以有些并不了解这些概念,所以查阅了资料,特意系统的理解梳理这一概念和相关设计知识,一来给自己总结梳理,二来也为有需要的人提供一点点个人的参考。该文来自沈龙的《何为互联网架构的高可用》。

通过这篇博文你可以收获如下:
1.什么是高可用?
2.如何保障系统高可用?
3.典型互联网分层架构
4.如何进行高可用设计?


1.什么是高可用?

通常我们所指的高可用是:通过设计减少系统不能提供服务的时间。理想目标就是:7*24不间断提供服务。比如说我100个单位时间内,有99个单位时间可用,1单位时间不可用,那么就说该系统是99%的可用性。很多大公司都是标榜4个9的高可用目标(99.99%),这意味着一年停机时间不能超过8.6小时。比如说百度搜索首页,这是公认的高可用保障非常出色的系统。通常我们都会通过ping百度首页来判断网络是不是通的,给人的印象就是:网络通畅,百度就能访问。

2.如何保障系统高可用?

我们都知道,单点系统是高可用的大敌。所以往往在系统设计过程中就要尽量避免单点。在方法论上,高可用保障的原则就是“集群化”(通俗的说就是冗余)。如果单点,在很多人为、不可控制等因素下,系统容易over,或者不能提供服务,如果有备份,那么就算服务受到影响,备份还是可以继续顶上。
保障系统高可用,在架构设计中的核心准则就是:冗余。,因为单点,不管如何可靠都不会比冗余更可靠。假设单点系统正常运行的概率是99.99%,而出现问题的概率万分之一或者更低,就算你把单点系统可靠性提高到出问题概率为亿分之一,但只要一旦出问题,服务就将完蛋。纵向的可靠性是有限的,横向的可靠性是无限的。

有了冗余,如果每次出现故障还是人工介入的去恢复服务,这样还是不够的,这样就变相的给系统增加了不可服务时间。通过自动故障转移来实现系统高可用是解决这一问题的有效方案。所以现在:冗余+自动故障转移的解决方案。

3.常见的互联网分层架构

深入理解互联网架构"高可用(HA)"
备注:图片来自58到家。
上面就是互联网分布式架构的典型:
(1)客户端层:浏览器、APP
(2)反向代理层:系统入口、反向代理
(3)站点应用层:实现核心的业务逻辑,返回json或者html
(4)服务层:如果进行了服务化,那么就在这一层
(5)数据-缓存层:缓存加速访问存储
(6)数据-数据库:数据库固化数据存储

整个系统的高可用,就是通过每一层的冗余+自动故障转移实现。

4.分层高可用实践

客户端到反向代理层:例如nginx,两台nginx,一台对线上提供服务,一台提供冗余。keepalive进行存活检测,相同virtual IP 提供服务。keepalive是自动故障转移的核心,它会检测nginx是否存活,一旦down了,那么就自动将流量迁移到冗余的nginx上。因为使用的virtual IP所以这个过程对于调用方是透明的。

反向代理层到站点应用层:通过冗余站点应用层来实现,在nginx的配置文件中配置多个web后端,并能探测多个web后端的存活性。一旦web-server挂了,nginx就会自动的进行故障转移,将流量自动迁移到备用web后端,整个过程是nginx自动完成,对调用方是透明的。

站点应用层到服务层:通过服务层的冗余进行实现,服务连接池会建立与下游服务的多个连接,每次请求通过某种策略选取连接访问下游服务。故障转移是通过service-connection-pool进行检测,会自动进行流量迁移,整个过程是连接池自动完成,对于调用方完全透明。

服务层到缓存层:通过缓存数据的冗余进行实现。这个地方的实现有多种方式,一种是service对cache进行双读或者双写。或者采用主从同步的缓存集群。比如redis,如果说主redis挂了,那么sentinel就会探测到,会通知调用新的redis,整个过程是由sentinel和redis集群配合完成,对调用方是透明的。
备注:这里所谓的缓存的高可用,其实更多的是用来加速数据访问,如果缓存挂了,或者没有命中,都是可以去后端数据库进行获取的。

服务层到数据库:
因为通常数据库的集群会采用“主从同步,读写分离” 架构。所以这里的高可用分为:读高可用,写高可用。
读高可用:通常备份库都是至少2个,一旦读库挂了,那么db-connection-pool就会自动将流量迁移到其他的读库上,整个过程由数据库连接池自动完成。对于调用方完全透明。
写高可用:对写库进行冗余,双主同步,一台对线上提供服务,一台冗余保障高可用,故障转移的话通常是通过keepalive进行存活检测,相同virtual IP提供服务,对于调用方完全透明的。

总结:
每一层之间提供高可用都是通过对被调用层的冗余+故障自动转移来实现的。这里知识提供的典型互联网分层架构的高可用设计的思路,但每一层高可用实现都会带来一些列的问题,在这里不展开说。另外这篇博文是我看了沈龙的《何为互联网架构的高可用》,我感觉这篇文章说的就是非常符合当下的互联网架构,也说明白了高可用这一概念以及如何实现高可用的准则,并且提供了很好的贴近工作的说明。上述内容非我原创,来自《何为互联网的高可用》一文。

转载于:https://blog.51cto.com/4837471/2164476

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值