互联网高可用架构技术实践

标签: | 发表时间:2018-04-08 11:28 | 作者:
出处:http://gitbook.cn

一、什么是高可用

高可用HA(High Availability)是分布式系统架构设计中必须考虑的因素之一,它通常是指, 通过设计减少系统不能提供服务的时间。

假设系统一直能够提供服务,我们说系统的可用性是100%。如果系统每运行100个时间单位,会有1个时间单位无法提供服务,我们说系统的可用性是99%。很多公司的高可用目标是4个9,也就是99.99%,这就意味着,系统的年停机时间为8.76个小时。

百度的搜索首页,是业内公认高可用保障非常出色的系统,甚至人们会通过www.baidu.com能不能访问来判断“网络的连通性”,百度高可用的服务让人留下啦“网络通畅,百度就能访问”,“百度打不开,应该是网络连不上”的印象,这其实是对百度HA最高的褒奖。

二、如何保障系统的高可用

我们都知道,单点是系统高可用的大敌,单点往往是系统高可用最大的风险和敌人,应该尽量在系统设计的过程中避免单点。 方法论上,高可用保证的原则是“集群化”,或者叫“冗余”:只有一个单点,挂了服务会受影响;如果有冗余备份,挂了还有其他backup能够顶上。

保证系统高可用,架构设计的核心准则是:冗余。有了冗余之后,还不够,每次出现故障需要人工介入恢复势必会增加系统的不可服务实践。所以,又往往是 通过“自动故障转移”来实现系统的高可用。接下来我们看下典型互联网架构中,如何通过冗余+自动故障转移来保证系统的高可用特性。

三、常见的互联网分层架构

enter image description here

常见互联网分布式架构如上,分为:

  • (1)客户端层:典型调用方是浏览器browser或者手机应用APP
  • (2)反向代理层:系统入口,反向代理
  • (3)站点应用层:实现核心应用逻辑,返回html或者json
  • (4)服务层:如果实现了服务化,就有这一层
  • (5)数据-缓存层:缓存加速访问存储
  • (6)数据-数据库层:数据库固化数据存储

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

四、分层高可用架构实践

1. 客户端层->反向代理层的高可用

enter image description here

客户端层反向代理层的高可用,是通过反向代理层的冗余来实现的。以nginx为例:有两台nginx,一台对线上提供服务,另一台冗余以保证高可用,常见的实践是keepalived存活探测,相同virtual IP提供服务。

enter image description here

自动故障转移:当nginx挂了的时候,keepalived能够探测到,会自动的进行故障转移,将流量自动迁移到shadow-nginx,由于使用的是相同的virtual IP,这个切换过程对调用方是透明的。

2. 反向代理层->站点层的高可用

enter image description here

反向代理层站点层的高可用,是通过站点层的冗余来实现的。假设反向代理层是nginx,nginx.conf里能够配置多个web后端,并且nginx能够探测到多个后端的存活性。

enter image description here

自动故障转移:当web-server挂了的时候,nginx能够探测到,会自动的进行故障转移,将流量自动迁移到其他的web-server,整个过程由nginx自动完成,对调用方是透明的。

3. 站点层->服务层的高可用

enter image description here

站点层服务层的高可用,是通过服务层的冗余来实现的。“服务连接池”会建立与下游服务多个连接,每次请求会“随机”选取连接来访问下游服务。

enter image description here

自动故障转移:当service挂了的时候,service-connection-pool能够探测到,会自动的进行故障转移,将流量自动迁移到其他的service,整个过程由连接池自动完成,对调用方是透明的(所以说RPC-client中的服务连接池是很重要的基础组件)。

4. 服务层>缓存层的高可用

enter image description here

服务层缓存层的高可用,是通过缓存数据的冗余来实现的。 缓存层的数据冗余又有几种方式:第一种是利用客户端的封装,service对cache进行双读或者双写。

enter image description here

缓存层也可以通过支持主从同步的缓存集群来解决缓存层的高可用问题。

以redis为例,redis天然支持主从同步,redis官方也有sentinel哨兵机制,来做redis的存活性检测。

enter image description here

自动故障转移:当redis主挂了的时候,sentinel能够探测到,会通知调用方访问新的redis,整个过程由sentinel和redis集群配合完成,对调用方是透明的。

说完缓存的高可用,这里要多说一句,业务对缓存并不一定有“高可用”要求,更多的对缓存的使用场景,是用来“加速数据访问”:把一部分数据放到缓存里,如果缓存挂了或者缓存没有命中,是可以去后端的数据库中再取数据的。

这类允许“cache miss”的业务场景,缓存架构的建议是:

enter image description here

将kv缓存封装成服务集群,上游设置一个代理(代理可以用集群的方式保证高可用),代理的后端根据缓存访问的key水平切分成若干个实例,每个实例的访问并不做高可用。

enter image description here

缓存实例挂了屏蔽:当有水平切分的实例挂掉时,代理层直接返回cache miss,此时缓存挂掉对调用方也是透明的。key水平切分实例减少,不建议做re-hash,这样容易引发缓存数据的不一致。

5. 服务层>数据库层的高可用

大部分互联网技术,数据库层都用了“主从同步,读写分离”架构,所以数据库层的高可用,又分为“读库高可用”与“写库高可用”两类。

  • 服务层>数据库层“读”的高可用

    enter image description here

服务层数据库读的高可用,是通过读库的冗余来实现的。

既然冗余了读库,一般来说就至少有2个从库,“数据库连接池”会建立与读库多个连接,每次请求会路由到这些读库。

enter image description here

自动 故障转移:当读库挂了的时候,db-connection-pool能够探测到,会自动的进行故障转移,将流量自动迁移到其他的读库,整个过程由连接池自动完成,对调用方是透明的(所以说DAO中的数据库连接池是很重要的基础组件)。

  • 服务层>数据库层“写”的高可用

    enter image description here

服务层数据库写的高可用,是通过写库的冗余来实现的。

以mysql为例,可以设置两个mysql双主同步,一台对线上提供服务,另一台冗余以保证高可用,常见的实践是keepalived存活探测,相同virtual IP提供服务。

enter image description here

自动 故障转移:当写库挂了的时候,keepalived能够探测到,会自动的进行故障转移,将流量自动迁移到shadow-db-master,由于使用的是相同的virtual IP,这个切换过程对调用方是透明的。

五、总结

高可用HA(High Availability)是分布式系统架构设计中必须考虑的因素之一,它通常是指,通过设计减少系统不能提供服务的时间。

方法论上,高可用是通过冗余+自动故障转移来实现的。

整个互联网分层系统架构的高可用,又是通过每一层的冗余+自动 故障转移来综合实现的,具体的:

  • (1) 客户端层反向代理层的高可用,是通过反向代理层的冗余实现的,常见实践是keepalived + virtual IP自动故障转移。
  • (2) 反向代理层站点层的高可用,是通过站点层的冗余实现的,常见实践是nginx与web-server之间的存活性探测与自动故障转移。
  • (3) 站点层服务层的高可用,是通过服务层的冗余实现的,常见实践是通过service-connection-pool来保证自动故障转移。
  • (4) 服务层缓存层的高可用,是通过缓存数据的冗余实现的,常见实践是缓存客户端双读双写,或者利用缓存集群的主从数据同步与sentinel保活与自动故障转移;更多的业务场景,对缓存没有高可用要求,可以使用缓存服务化来对调用方屏蔽底层复杂性。
  • (5) 服务层数据库“读”的高可用,是通过读库的冗余实现的,常见实践是通过db-connection-pool来保证自动故障转移。
  • (6) 服务层数据库“写”的高可用,是通过写库的冗余实现的,常见实践是keepalived + virtual IP自动故障转移。

末了,希望文章的思路是清晰的,希望大家对高可用的概念和实践有个系统的认识,希望对得住这20块的打赏,however,未尽事宜后续小范围讨论沟通。


相关 [互联网 架构 技术] 推荐:

中大型移动互联网公司技术架构选择

- - 五四陈科学院
以下内容由 [五四陈科学院]提供. 总结这些年经验,进行构架演进的方向选择时,大致要做到下面的目标:. 可快速开发部署 (五分钟写出来一个经过测试的hello world并可访问/调用,并可在公网访问). 天然可扩展(业务层无状态,尽可能全部放到最后). 自动化(内存不足了,除了报警,应该自动加点机器进去; 新的项目,基础代码应该都不用写,自动生成即可).

互联网高可用架构技术实践

- -
高可用HA(High Availability)是分布式系统架构设计中必须考虑的因素之一,它通常是指,. 通过设计减少系统不能提供服务的时间. 假设系统一直能够提供服务,我们说系统的可用性是100%. 如果系统每运行100个时间单位,会有1个时间单位无法提供服务,我们说系统的可用性是99%. 很多公司的高可用目标是4个9,也就是99.99%,这就意味着,系统的年停机时间为8.76个小时.

应用架构和技术架构

- - 人月神话的BLOG
在这里再谈下应用架构和技术架构的关系和边界问题,这里的说明和标准的TOGAF会有一些区别,仅为个人理解的一些点滴记录. 首先再说下应用架构,应用架构是和业务架构有强烈的映射关系的一个架构,应用架构要说明的是整体企业内部信息化建设和规划应该分为哪些应用系统去建设,应用系统间的集成关系是如何的. 即我们常说的应用架构和应用集成架构.

淘宝的可伸缩高性能互联网架构

- 浪客 - 博客园-首页原创精华区
一 应用无状态(淘宝session框架).          假如在session中保存了大量与客户端的状态信息,保存状态信息的server宕机时.          通常通过集群解决,不仅有负载均衡,更重要的是要有失效恢复failover.          tomcat用集群节点广播复制,jboss用配对复制等session状态复制策略,但严重影响系统的伸缩性,不能通过增加更多的机器达到良好的水平伸缩.

一个移动互联网应用地图服务架构

- Ian - 出家如初,成佛有余
    在移动互联网中,各种与位置相关的服务都严重依赖于地图服务,地图服务质量的好坏很大程度决定了所提供服务的高低. 尽管有Google Map等免费或收费的地图服务可供使用,但没有那一家地图服务提供商能够完整提供移动互联网应用所必须的各种地图服务及数据,尤其是针对那些垂直行业应用.     在中国特色的制度下,除了技术因素外,值得注意的是由于地图牌照发放问题带来的政策上的不确定性对架构实现的冲击和挑战.

[转][转]互联网系统架构的演进

- - heiyeluren的blog(黑夜路人的开源世界)
来源: http://www.csdn.net/article/2013-08-27/2816716. 摘要:多终端接入、开放平台给互联网带来了前所未有的用户数量和访问规模,信息之多、传播速度之快,是传统网站难以想象的. 本文将从发展演进的角度,解读高性能互联网系统架构. 多终端接入、开放平台给互联网带来了前所未有的用户量级和访问规模,SNS网站产生了海量的UGC(用户产生内容),而且这些内容依托关 系链扩散速度之快、传播范围之广是传统网站难以想象的,海量数据的计算存储也一直是近年互联网领域的热点.

移动互联网系统架构十大陷阱

- - 五四陈科学院-坚信科学,分享技术
以下内容由 [五四陈科学院]提供. 过去的三年,54chen一直奋斗在中国移动互联网一线,历经各种坑爹的情况. Top 1.时不我待 连通性. cmwap cmnet这样的词语以后应该都会消失在人世间. 三年前,经常性地有移不动联不通手机连不上服务器机房的情况. 相信未来会越来越好,时代在召唤. Top 2.生不逢时 HTML5.

[转]各大互联网公司架构演进之路汇总

- - 鸟窝
原文地址: 各大互联网公司架构演进之路汇总 by HollisChuang. 请转载时务必保留文章的上述原始出处. 支付宝和蚂蚁花呗的技术架构及实践. 支付宝的高可用与容灾架构演进. 聚划算架构演进和系统优化 (视频+PPT). 淘宝交易系统演进之路 (专访). 淘宝技术发展历程和架构经验分享(视频+PPT)(2.3日更新).

互联网时代,我眼中的架构变迁

- - SegmentFault 最新的文章
作者简介:黄庆兵,网易蜂巢首席技术布道师,浙大硕士毕业,从事云计算、Docker、Go等相关开发及技术布道工作;喜欢开源,乐于分享,勤于布道,折腾过开源小工具,制作过Docker课程,分享过 Gopher Meetup. 互联网在变,架构也在变,架构的变迁亦是互联网的变迁. 所以,我们有必要来聊聊互联网的架构及其变迁.

互联网架构,如何进行容量设计?

- -
互联网公司,这样的场景是否似曾相识:. 场景一:pm要做一个很大的运营活动,技术老大杀过来,问了两个问题:. (2)如果扛不住,需要加多少台机器. 场景二:系统设计阶段,技术老大杀过来,又问了两个问题:. (2)如果需要分库,需要分几个库. 技术上来说,这些都是系统容量预估的问题,容量设计是架构师必备的技能之一.