站在架构师的角度看：高性能、高可用平台架构演变史
开篇概述：
在如今移动互联网、互联网+、大数据的时代，各类的互联网网站、平台异常突起，如同雨后春笋，有种“忽如一夜春风来，千树万树梨花开”感觉。
对于移动互联网时代的平台来说，用户的体验感是否良好？平台的稳定性是否良好？估计是对所有互联网平台来说两大头等要素吧，的确，移动互联网时代，流量就是市场价值，说白了就是收益，就是RMB，失去了流量，那么你也就失去了赚取收益的机会与机遇。
因此，对于互联平台或网站来说，网站的高可用、不间断服务也是平台运营过程中的一个重大决定因素，比如说某平台，三天两头的故障，打不开，又或者说，经常性的出现错误、访问超时等等问题，那么用户的流失机率就会随之增加。
那么今天我们就来聊一聊各类高可用架构的一个演变过程到底是如何的？此文民工哥用时三小时总结写作完成，希望对大家有所帮助，欢迎大家拍砖、留言、点赞、转发分享以支持。
什么是高可用？
“高可用性”（High Availability）通常来描述一个系统经过专门的设计，从而减少停工时间，而保持其服务的高度可用性。简而言之，就是不间断对外提供服务。
架构之初
架构图
架构简述
这类架构比较适用于初创企业或流量较小的平台。
此种架构一般都是在平台运行之初所用到的架构，日均PV不大，简单的架构足以能够应对用户的流量请求，比如前端网站使用Apache/nginx都可以，APP服务器直接使用JAVA环境如tomcat应用，互联网平台的数据库大部分使用Mysql，备份服务器一般都备份一些常用的配置、代码、数据库数据的备份文件等。因此，民工哥称它为架构之初。
架构中期
随着用户数量的增长、访问量的增加，随之而来的问题就是单台服务器已无法承受用户的访问流量，因此前期的基础架构就需要面临一定的调整，大概调整如下
架构图
架构简述
这类架构就此引入了负载均衡的概念，关于应用的负载均衡，前面也有相关的文章介绍，具体文章链接如下
nginx负载均衡与反向代理
Nginx+Tomcat多实例及负载均衡配置
负载均衡的开源软件较多，通常会有以下两种方式
硬件负载——F5 7层或者4层网络代理
软件负载——nginx、haproxy开源负载均衡软件
负载均衡的算法通常有：
轮询法
随机法
源地址哈希法
加权轮询法
加权随机法
最小连接数法
给大家推荐一个架构群：698581634 进群即可免费获取资料。
具体使用何种方式，一切以企业实际需求、投入与产出比（成本考虑）为主，但是此类架构也有一定的缺点存在，暂时不考虑前端负载设备的高可用，比如用户的上传与查看文件问题（通过A服务访问上传，然后负载查看时是通B服务器的，就会造成用户无法查看的问题），APP服务器同理；数据库服务器存在主、从库单点问题，一旦故障，可以手工进行故障切换，但是可能会造成数据丢失或不统一，并且会在一定程度上给用户造成不好的体验；因此仍需演变。
架构图
架构简述
此架构在上面的架构基础，以应对各类问题做出的修改，增加了数据存储服务器（NFS共享存储Linux系统NFS网络文件系统），对于存储架构及源件，其实挺多的，具体有以下几种开源软件服务
1、NFS网络共享存储文件系统
2、FastDFS 轻量级网络文件系统(参考文章：分布式文件系统FastDFS详解)
3、分布式文件系统MooseFS
4、GlusterFS文件系统
给大家推荐一个架构群：698581634 进群即可免费获取资料。
并配置负载均衡、并且还解决了单点故障的问题，对于数据库服务器做出了一定的架构调整，为双主多从的架构，对于数据库的各种高可用架构，前面也有文章做过分析，具体如：
浅谈MySQL集群高可用架构
MySQL集群高可用架构之MHA
但是所有架构都是要以实际需求（如对数据完整性、一致性的要求为主），从而解决主库单点问题、从库读取量大的性能问题，保证在一定量用访问时的平台性能与高可用
架构终期
架构图
架构简述
架构演变到一定程度，仅通过平行的扩展或增加服务器数量可能已无法解决相关的性能问题，因此
第一，在用户访问初始阶段就会使用CDN加速技术，来提高用户的访问体验度；
第二，按照业务来拆分成不同的服务，通过拆分服务、相同服务布署多个实例的架构来达到扩展的目的，来提高一定的性能，也能保证平台的高可用性；服务拆分后，也能一定限度的解决发布问题，因为服务之间彼此独立，服务之间耦合性不强，也比较方便平时的维护；
第三，对于用户与数据库之间的瓶颈问题，考虑加上缓存技术来提高一定的访问性能与高可用性，让用户的访问流量在到达数据库之前直接过滤掉一部分，甚至一大半，从而减轻数据库访问压力，在查多写少的场景，非常适用使用缓存来提升查询服务的性能，减轻对数据库的压力。通常使用redis作为缓存服务器，redis的一些集群机制能很大程度上保证缓存服务的高可用性（Redis集群生产环境高可用方案实战过程），缓存服务故障时，还能从数据库获取信息。然后对于备份服务器也简单的做调整保证数据的完整性，一方面也能及时保障应用的高可用性；其实一些大型分布式的系统在缓存这块还是比较倾向于memcached服务（Linux系统Memcached服务介绍），比如像一些用户的登录信息同步到其它系统此种场景，一般布署在前台应用层与数据存储层中间，应对前端应用大量请求与快速响应，从而减少数据库的访问压力，也能提高用户的访问体验度。
也有一部分平台架构是采用分层的方式
前端应用层：
给用户提供页面展示、查找、搜索的界面及相关的最终结果显示页面
后端服务层：
一般包括像常用的后台服务、用户管理、接口管理、支付管理等，都是给前端应用提提供服务的
** 数据存储层：**
这个就很容易理解，像数据库、文件系统、缓存等一系列提供数据访问与存储的
所以因此也有下面的这类架构产生
原文链接：https://www.cnblogs.com/youkanyouxiao/p/9834791.html
最终总结
高可用、高性能只能说是一个阶段、一个时期的，没有完美的架构，只有不断演变、不断完善的架构。因此，今天所说的高性能、高可用架构，可能不尽完美，但归根结底总结成一句话：“让用户的访问流量尽量靠前，一步步分层去过滤用户流量，快速响应用户的请求，从而达到比较好的用户体验”。
