网站推广填空题,用织梦系统做网站产权,汕头住房和城乡建设厅网站,业务推广网站转载自 究竟啥才是互联网架构“高可用”一、什么是高可用
高可用HA#xff08;High Availability#xff09;是分布式系统架构设计中必须考虑的因素之一#xff0c;它通常是指#xff0c;通过设计减少系统不能提供服务的时间。
假设系统一直能够提供服务#xff0c;我们说…转载自 究竟啥才是互联网架构“高可用”一、什么是高可用
高可用HAHigh Availability是分布式系统架构设计中必须考虑的因素之一它通常是指通过设计减少系统不能提供服务的时间。
假设系统一直能够提供服务我们说系统的可用性是100%。
如果系统每运行100个时间单位会有1个时间单位无法提供服务我们说系统的可用性是99%。
很多公司的高可用目标是4个9也就是99.99%这就意味着系统的年停机时间为8.76个小时。
百度的搜索首页是业内公认高可用保障非常出色的系统甚至人们会通过www.baidu.com 能不能访问来判断“网络的连通性”百度高可用的服务让人留下啦“网络通畅百度就能访问”“百度打不开应该是网络连不上”的印象这其实是对百度HA最高的褒奖。二、如何保障系统的高可用
我们都知道单点是系统高可用的大敌单点往往是系统高可用最大的风险和敌人应该尽量在系统设计的过程中避免单点。方法论上高可用保证的原则是“集群化”或者叫“冗余”只有一个单点挂了服务会受影响如果有冗余备份挂了还有其他backup能够顶上。
保证系统高可用架构设计的核心准则是冗余。
有了冗余之后还不够每次出现故障需要人工介入恢复势必会增加系统的不可服务实践。所以又往往是通过“自动故障转移”来实现系统的高可用。
接下来我们看下典型互联网架构中如何通过冗余自动故障转移来保证系统的高可用特性。三、常见的互联网分层架构
常见互联网分布式架构如上分为
1客户端层典型调用方是浏览器browser或者手机应用APP
2反向代理层系统入口反向代理
3站点应用层实现核心应用逻辑返回html或者json
4服务层如果实现了服务化就有这一层
5数据-缓存层缓存加速访问存储
6数据-数据库层数据库固化数据存储
整个系统的高可用又是通过每一层的冗余自动故障转移来综合实现的。四、分层高可用架构实践
【客户端层-反向代理层】的高可用
【客户端层】到【反向代理层】的高可用是通过反向代理层的冗余来实现的。以nginx为例有两台nginx一台对线上提供服务另一台冗余以保证高可用常见的实践是keepalived存活探测相同virtual IP提供服务。自动故障转移当nginx挂了的时候keepalived能够探测到会自动的进行故障转移将流量自动迁移到shadow-nginx由于使用的是相同的virtual IP这个切换过程对调用方是透明的。【反向代理层-站点层】的高可用
【反向代理层】到【站点层】的高可用是通过站点层的冗余来实现的。假设反向代理层是nginxnginx.conf里能够配置多个web后端并且nginx能够探测到多个后端的存活性。自动故障转移当web-server挂了的时候nginx能够探测到会自动的进行故障转移将流量自动迁移到其他的web-server整个过程由nginx自动完成对调用方是透明的。【站点层-服务层】的高可用
【站点层】到【服务层】的高可用是通过服务层的冗余来实现的。“服务连接池”会建立与下游服务多个连接每次请求会“随机”选取连接来访问下游服务。自动故障转移当service挂了的时候service-connection-pool能够探测到会自动的进行故障转移将流量自动迁移到其他的service整个过程由连接池自动完成对调用方是透明的所以说RPC-client中的服务连接池是很重要的基础组件。【服务层缓存层】的高可用
【服务层】到【缓存层】的高可用是通过缓存数据的冗余来实现的。
缓存层的数据冗余又有几种方式第一种是利用客户端的封装service对cache进行双读或者双写。缓存层也可以通过支持主从同步的缓存集群来解决缓存层的高可用问题。
以redis为例redis天然支持主从同步redis官方也有sentinel哨兵机制来做redis的存活性检测。自动故障转移当redis主挂了的时候sentinel能够探测到会通知调用方访问新的redis整个过程由sentinel和redis集群配合完成对调用方是透明的。说完缓存的高可用这里要多说一句业务对缓存并不一定有“高可用”要求更多的对缓存的使用场景是用来“加速数据访问”把一部分数据放到缓存里如果缓存挂了或者缓存没有命中是可以去后端的数据库中再取数据的。
这类允许“cache miss”的业务场景缓存架构的建议是
将kv缓存封装成服务集群上游设置一个代理代理可以用集群冗余的方式保证高可用代理的后端根据缓存访问的key水平切分成若干个实例每个实例的访问并不做高可用。缓存实例挂了屏蔽当有水平切分的实例挂掉时代理层直接返回cache miss此时缓存挂掉对调用方也是透明的。key水平切分实例减少不建议做re-hash这样容易引发缓存数据的不一致。【服务层数据库层】的高可用
大部分互联网技术数据库层都用了“主从同步读写分离”架构所以数据库层的高可用又分为“读库高可用”与“写库高可用”两类。【服务层数据库层“读”】的高可用
【服务层】到【数据库读】的高可用是通过读库的冗余来实现的。
既然冗余了读库一般来说就至少有2个从库“数据库连接池”会建立与读库多个连接每次请求会路由到这些读库。自动故障转移当读库挂了的时候db-connection-pool能够探测到会自动的进行故障转移将流量自动迁移到其他的读库整个过程由连接池自动完成对调用方是透明的所以说DAO中的数据库连接池是很重要的基础组件。【服务层数据库层“写”】的高可用
【服务层】到【数据库写】的高可用是通过写库的冗余来实现的。
以mysql为例可以设置两个mysql双主同步一台对线上提供服务另一台冗余以保证高可用常见的实践是keepalived存活探测相同virtual IP提供服务。自动故障转移当写库挂了的时候keepalived能够探测到会自动的进行故障转移将流量自动迁移到shadow-db-master由于使用的是相同的virtual IP这个切换过程对调用方是透明的。五、总结
高可用HAHigh Availability是分布式系统架构设计中必须考虑的因素之一它通常是指通过设计减少系统不能提供服务的时间。
方法论上高可用是通过冗余自动故障转移来实现的。
整个互联网分层系统架构的高可用又是通过每一层的冗余自动故障转移来综合实现的具体的
1【客户端层】到【反向代理层】的高可用是通过反向代理层的冗余实现的常见实践是keepalived virtual IP自动故障转移
2【反向代理层】到【站点层】的高可用是通过站点层的冗余实现的常见实践是nginx与web-server之间的存活性探测与自动故障转移
3【站点层】到【服务层】的高可用是通过服务层的冗余实现的常见实践是通过service-connection-pool来保证自动故障转移
4【服务层】到【缓存层】的高可用是通过缓存数据的冗余实现的常见实践是缓存客户端双读双写或者利用缓存集群的主从数据同步与sentinel保活与自动故障转移更多的业务场景对缓存没有高可用要求可以使用缓存服务化来对调用方屏蔽底层复杂性
5【服务层】到【数据库“读”】的高可用是通过读库的冗余实现的常见实践是通过db-connection-pool来保证自动故障转移
6【服务层】到【数据库“写”】的高可用是通过写库的冗余实现的常见实践是keepalived virtual IP自动故障转移末了希望文章的思路是清晰的希望大家对高可用的概念和实践有个系统的认识感谢大家。
【完】
