高性能、高可用平台架构演变史

开篇概述

在现在移动互联网、互联网+、大数据的时代，各种的互联网网站、平台异常突起，如同雨后春笋，有种“忽如一晚上春风来，千树万树梨花开”感受。 对于移动互联网时代的平台来讲，用户的体验感是否良好？平台的稳定性是否良好？估计是对全部互联网平台来讲两大头等要素吧，的确，移动互联网时代，流量就是市场价值，说白了就是收益，就是RMB，失去了流量，那么你也就失去了赚取收益的机会与机遇。

所以，对于互联平台或网站来讲，网站的高可用、不间断服务也是平台运营过程当中的一个重大决定因素，好比说某平台，三天两头的故障，打不开，又或者说，常常性的出现错误、访问超时等等问题，那么用户的流失机率就会随之增长。 那么今天咱们就来聊一聊各种高可用架构的一个演变过程究竟是如何的？此文民工哥用时三小时总结写做完成，但愿对你们有所帮助，欢迎你们拍砖、留言、点赞、转发分享以支持。

什么是高可用？

“高可用性”（High Availability）一般来描述一个系统通过专门的设计，从而减小停工时间，而保持其服务的高度可用性。简而言之，就是不间断对外提供服务。

架构之初

架构图

架构简述

这类架构比较适用于初创企业或流量较小的平台。 此种架构通常都是在平台运行之初所用到的架构，日均PV不大，简单的架构足以可以应对用户的流量请求，好比前端网站使用Apache/nginx均可以，APP服务器直接使用JAVA环境如tomcat应用，互联网平台的数据库大部分使用Mysql，备份服务器通常都备份一些经常使用的配置、代码、数据库数据的备份文件等。所以，民工哥称它为架构之初。

架构中期

随着用户数量的增加、访问量的增长，随之而来的问题就是单台服务器已没法承受用户的访问流量，所以前期的基础架构就须要面临必定的调整，大概调整以下

架构图

架构简述

这类架构就此引入了负载均衡的概念，关于应用的负载均衡，前面也有相关的文章介绍，具体文章连接以下 nginx负载均衡与反向代理 Nginx+Tomcat多实例及负载均衡配置

负载均衡的开源软件较多，一般会有如下两种方式

• 硬件负载——F5 7层或者4层网络代理
• 软件负载——nginx、haproxy开源负载均衡软件

负载均衡的算法一般有：

• 轮询法
• 随机法
• 源地址哈希法
• 加权轮询法
• 加权随机法
• 最小链接数法

具体使用何种方式，一切以企业实际需求、投入与产出比（成本考虑）为主，可是此类架构也有必定的缺点存在，暂时不考虑前端负载设备的高可用，好比用户的上传与查看文件问题（经过A服务访问上传，而后负载查看时是通B服务器的，就会形成用户没法查看的问题），APP服务器同理；数据库服务器存在主、从库单点问题，一旦故障，能够手工进行故障切换，可是可能会形成数据丢失或不统一，而且会在必定程度上给用户形成很差的体验；所以仍需演变。

架构图

架构简述

此架构在上面的架构基础，以应对各种问题作出的修改，增长了数据存储服务器（NFS共享存储Linux系统NFS网络文件系统），对于存储架构及源件，其实挺多的，具体有如下几种开源软件服务

• 一、NFS网络共享存储文件系统
• 二、FastDFS 轻量级网络文件系统(参考文章：分布式文件系统FastDFS详解)
• 三、分布式文件系统MooseFS
• 四、GlusterFS文件系统

并配置负载均衡、而且还解决了单点故障的问题，对于数据库服务器作出了必定的架构调整，为双主多从的架构，对于数据库的各类高可用架构，前面也有文章作过度析，具体如： 浅谈MySQL集群高可用架构

MySQL集群高可用架构之MHA

可是全部架构都是要以实际需求（如对数据完整性、一致性的要求为主），从而解决主库单点问题、从库读取量大的性能问题，保证在必定量用访问时的平台性能与高可用

架构终期

架构图

架构简述

架构演变到必定程度，仅经过平行的扩展或增长服务器数量可能已没法解决相关的性能问题，所以

第一，在用户访问初始阶段就会使用CDN加速技术，来提升用户的访问体验度；

第二，按照业务来拆分红不一样的服务，经过拆分服务、相同服务布署多个实例的架构来达到扩展的目的，来提升必定的性能，也能保证平台的高可用性；服务拆分后，也能必定限度的解决发布问题，由于服务之间彼此独立，服务之间耦合性不强，也比较方便平时的维护；

第三，对于用户与数据库之间的瓶颈问题，考虑加上缓存技术来提升必定的访问性能与高可用性，让用户的访问流量在到达数据库以前直接过滤掉一部分，甚至一大半，从而减轻数据库访问压力，在查多写少的场景，很是适用使用缓存来提高查询服务的性能，减轻对数据库的压力。一般使用redis做为缓存服务器，redis的一些集群机制能很大程度上保证缓存服务的高可用性（Redis集群生产环境高可用方案实战过程），缓存服务故障时，还能从数据库获取信息。而后对于备份服务器也简单的作调整保证数据的完整性，一方面也能及时保障应用的高可用性；其实一些大型分布式的系统在缓存这块仍是比较倾向于memcached服务（Linux系统Memcached服务介绍），好比像一些用户的登陆信息同步到其它系统此种场景，通常布署在前台应用层与数据存储层中间，应对前端应用大量请求与快速响应，从而减小数据库的访问压力，也能提升用户的访问体验度。

也有一部分平台架构是采用分层的方式

前端应用层：

• 给用户提供页面展现、查找、搜索的界面及相关的最终结果显示页面
  复制代码

后端服务层：

• 通常包括像经常使用的后台服务、用户管理、接口管理、支付管理等，都是给前端应用提提供服务的
  复制代码

** 数据存储层：**

• 这个就很容易理解，像数据库、文件系统、缓存等一系列提供数据访问与存储的
  复制代码

因此所以也有下面的这类架构产生

最终总结

高可用、高性能只能说是一个阶段、一个时期的，**没有完美的架构，只有不断演变、不断完善的架构。**所以，今天所说的高性能、高可用架构，可能不尽完美，但归根结底总结成一句话：“让用户的访问流量尽可能靠前，一步步分层去过滤用户流量，快速响应用户的请求，从而达到比较好的用户体验”。

民工哥所发文章，如无其它说明均为原创做品，转载需注明原处、做者信息。