内容简介:“高可用性”(High Availability)通常来描述一个系统经过专门的设计,从而减少停工时间,而保持其服务的高度可用性。简而言之,就是不间断对外提供服务。这类架构比较适用于初创企业或流量较小的平台。 此种架构一般都是在平台运行之初所用到的架构,日均PV不大,简单的架构足以能够应对用户的流量请求,比如前端网站使用Apache/nginx都可以,APP服务器直接使用JAVA环境如tomcat应用,互联网平台的数据库大部分使用Mysql,备份服务器一般都备份一些常用的配置、代码、数据库数据的备份文件等。
“高可用性”(High Availability)通常来描述一个系统经过专门的设计,从而减少停工时间,而保持其服务的高度可用性。简而言之,就是不间断对外提供服务。
架构之初
架构图
架构简述
这类架构比较适用于初创企业或流量较小的平台。 此种架构一般都是在平台运行之初所用到的架构,日均PV不大,简单的架构足以能够应对用户的流量请求,比如前端网站使用Apache/nginx都可以,APP服务器直接使用 JAVA 环境如tomcat应用,互联网平台的数据库大部分使用Mysql,备份服务器一般都备份一些常用的配置、代码、数据库数据的备份文件等。因此,民工哥称它为架构之初。
架构中期
随着用户数量的增长、访问量的增加,随之而来的问题就是单台服务器已无法承受用户的访问流量,因此前期的基础架构就需要面临一定的调整,大概调整如下
架构图
架构简述
这类架构就此引入了负载均衡的概念,关于应用的负载均衡,前面也有相关的文章介绍,具体文章链接如下 nginx负载均衡与反向代理 Nginx+Tomcat多实例及负载均衡配置
负载均衡的开源软件较多,通常会有以下两种方式
- 硬件负载——F5 7层或者4层网络代理
- 软件负载——nginx、haproxy开源负载均衡软件
负载均衡的算法通常有:
- 轮询法
- 随机法
- 源地址哈希法
- 加权轮询法
- 加权随机法
- 最小连接数法
具体使用何种方式,一切以企业实际需求、投入与产出比(成本考虑)为主,但是此类架构也有一定的缺点存在,暂时不考虑前端负载设备的高可用,比如用户的上传与查看文件问题(通过A服务访问上传,然后负载查看时是通B服务器的,就会造成用户无法查看的问题),APP服务器同理;数据库服务器存在主、从库单点问题,一旦故障,可以手工进行故障切换,但是可能会造成数据丢失或不统一,并且会在一定程度上给用户造成不好的体验;因此仍需演变。
架构图
架构简述
此架构在上面的架构基础,以应对各类问题做出的修改,增加了数据存储服务器( NFS共享存储 Linux 系统NFS网络文件系统 ),对于存储架构及源件,其实挺多的,具体有以下几种开源软件服务
- 1、NFS网络共享存储文件系统
- 2、FastDFS 轻量级网络文件系统(参考文章: 分布式文件系统FastDFS详解 )
- 3、分布式文件系统MooseFS
- 4、GlusterFS文件系统
并配置负载均衡、并且还解决了单点故障的问题,对于数据库服务器做出了一定的架构调整,为双主多从的架构,对于数据库的各种高可用架构,前面也有文章做过分析,具体如: 浅谈 MySQL 集群高可用架构
但是所有架构都是要以实际需求(如对数据完整性、一致性的要求为主),从而解决主库单点问题、从库读取量大的性能问题,保证在一定量用访问时的平台性能与高可用
架构终期
架构图
架构简述
架构演变到一定程度,仅通过平行的扩展或增加服务器数量可能已无法解决相关的性能问题,因此
第一,在用户访问初始阶段就会使用CDN加速技术,来提高用户的访问体验度;
第二,按照业务来拆分成不同的服务,通过拆分服务、相同服务布署多个实例的架构来达到扩展的目的,来提高一定的性能,也能保证平台的高可用性;服务拆分后,也能一定限度的解决发布问题,因为服务之间彼此独立,服务之间耦合性不强,也比较方便平时的维护;
第三,对于用户与数据库之间的瓶颈问题,考虑加上缓存技术来提高一定的访问性能与高可用性,让用户的访问流量在到达数据库之前直接过滤掉一部分,甚至一大半,从而减轻数据库访问压力,在查多写少的场景,非常适用使用缓存来提升查询服务的性能,减轻对数据库的压力。通常使用 redis 作为缓存服务器,redis的一些集群机制能很大程度上保证缓存服务的高可用性( Redis集群生产环境高可用方案实战过程 ),缓存服务故障时,还能从数据库获取信息。然后对于备份服务器也简单的做调整保证数据的完整性,一方面也能及时保障应用的高可用性;其实一些大型分布式的系统在缓存这块还是比较倾向于 memcached 服务( Linux系统Memcached服务介绍 ),比如像一些用户的登录信息同步到其它系统此种场景,一般布署在前台应用层与数据存储层中间,应对前端应用大量请求与快速响应,从而减少数据库的访问压力,也能提高用户的访问体验度。
也有一部分平台架构是采用分层的方式
前端应用层:
-
给用户提供页面展示、查找、搜索的界面及相关的最终结果显示页面 复制代码
后端服务层:
-
一般包括像常用的后台服务、用户管理、接口管理、支付管理等,都是给前端应用提提供服务的 复制代码
** 数据存储层:**
-
这个就很容易理解,像数据库、文件系统、缓存等一系列提供数据访问与存储的 复制代码
所以因此也有下面的这类架构产生
以上所述就是小编给大家介绍的《高性能、高可用平台架构演变史》,希望对大家有所帮助,如果大家有任何疑问请给我留言,小编会及时回复大家的。在此也非常感谢大家对 码农网 的支持!
猜你喜欢:- 一文了解自然语言生成演变史!
- 基于 Spring Cloud 的微服务架构演变史?
- 基于Spring Cloud的微服务架构演变史
- 矿机演变史:从散兵游勇到集团军
- 一文尽览推荐系统模型演变史(文末可下载)
- 微软回顾 Windows 命令行演变史,力证 DOS 未过时
本站部分资源来源于网络,本站转载出于传递更多信息之目的,版权归原作者或者来源机构所有,如转载稿涉及版权问题,请联系我们。
新媒体革命——在线时代的媒体、公关与传播
仇勇 / 电子工业出版社 / 2016-2-1 / CNY 50.00
这既是传统媒体的大裂变年代,也是在线媒体开启的新闻业的黄金时代。 信息流动的新法则不仅改变了媒体业,也在重塑公关、传播和商业的面貌。总之,这个世界的连接方式不仅不再相同,而且这一改变不可逆转。在这个全新重启的在线时代里,无论是信息的获取还是商业本身,信任都变得比以往更重要。 从告别传统媒体的那一刻起,我就有着两个小小的“野心”:一是探寻适合在线时代的媒体生产方式;二是让优质内容有权获得......一起来看看 《新媒体革命——在线时代的媒体、公关与传播》 这本书的介绍吧!