服务器架构演变之路学习

一直对网站从无到有、从小到大的后端架构支持的演变过程感兴趣，最近梳理了一番整个过程，在将来如果自己也要对网站架构进行优化的时候也知道方向

第一种演变过程

最基础架构
–> 进阶
替换 Apache 为 Nginx，并在数据库前加上 cache 层
–> 进阶
CGI 无法匹配上 Nginx 的高 IO 性能，这时候可以通过写扩展来替代脚本程序来提升性能，用 C / Lua 写扩展是个好办法
–> 进阶
随着用户的增多，Mysql 的写入速度成了又一大瓶颈，要在 Nginx 和 Mysql 中间加入一层写缓存，队列系统就出场了,例如 RabbitMQ
–> 进阶
分布式存储数据库，分布式缓存池，增加负载均衡调度节点来提高并发性能
–> 进阶
多节点调度，使用 keepalived
–> 进阶
缓存池换用一致性哈希，提高命中率

第二种演变过程

基础形态
–> 进阶
应用服务和数据服务分离，不同的服务器根据需求选用不同的侧重点，应用服务器处理业务逻辑需要强大的 CPU；数据库服务器频繁硬盘读写需要更快的硬盘和更大的内存；文件服务器需要更大容量的硬盘
–> 进阶
往往 80% 的业务访问集中在 20% 的数据上，将频繁访问的数据缓存到内存中，网站部分则需要分布式缓存服务器来解决本地缓存内存不够的问题
–> 进阶
数据访问的压力得到了极大的缓解，但是单一服务器能够处理的请求连接数量有限，当应用服务器成了整个网站的效率瓶颈，使用分布式集群是网站解决高并发、海量数据问题的常用手段。通过负载均衡调度服务器，可以将来自用户浏览器的访问请求分发到应用服务器集群中的任何一台服务器上，以此缓解应用服务器能力不足
–> 进阶
缓存数据库后大部分的读操作都不通过数据了，但是全部的写操作都压在数据库中，利用主从热备来实现数据库读写分离。写操作在主数据库服务器中，读操作在从数据库服务器中
–> 进阶
为了让任何地域的人访问体验一致，需要使用 CDN / 反向代理来进行缓存
–> 进阶
分库分表之后还是不行，就要采取分布式文件服务器和分布式数据库
–> 进阶
采用一些非关系数据库技术如 NoSQL 和非数据库查询技术如搜索引擎
–> 进阶
将共用的业务提取出来，独立部署。由这些可复用的业务连接数据库，提供共用业务服务

推荐阅读：《大型网站技术架构-核心原理与案例分析》