互联网架构演化历程

早期的互联网系统架构都是很简单的单体架构，一台服务器上部署了所有应用的程序。当时，国内互联网正处于发展时期，接入互联网的用户也并不多，所以当时的互联网企业没有应对高并发的挑战和海量数据存储的问题。

最近几年随着互联网的不断发展，接入互联网的用户也越来越多，产生各类数据也越来越多，以前的单体架构已经不能很好的为大量用户提供高质量的服务了。为了解决这个问题，于是开始了架构演化的第一个阶段：

架构演化第一阶段：应用数据分离

将应用程序（代码）与数据库以及其他的一些辅助类服务分别部署在不同的服务器上，用以减轻单台服务器所承受的压力。使用此种方案在目前看来暂时缓解了服务器的压力，系统得以平稳运行一阵子。随着互联网用户的基数的不断增长，第一阶段的架构也显得有些稍许吃力，系统性能不足的问题逐渐显现出来。此时，就进入了架构演化的第二个阶段：

架构演化第二阶段：使用缓存改善系统性能

使用本地缓存加分布式缓存服务器来改善现有系统性能不足的问题，加上缓存之后系统的性能问题得以解决，但随之而来又出现了新的问题，那就是系统的并发处理能力不足，无法应对大量用户同一时间的集中请求或者某些操作。到这里，架构继续演进，来到了第三阶段：

架构演化第三阶段：使用应用服务器集群改善系统并发处理能力

为了解决系统并发处理能力不足的问题，为各个不同的服务部署多台服务器，以组成服务集群的方式为用户持续提供服务，在应用服务器的前面加上一层负载均衡服务器，根据负载均衡的调度算法，将不同的用户请求调度到不同的服务器。暂时系统并发处理能力不足的问题是解决了，接着数据库这块又出现了访问瓶颈，单台数据库不能很好的兼顾读与写的操作，特别是用户访问量剧增或者订单高峰期这类场景的时候，于是架构继续向下进行演化，来到了第四个阶段：

架构演化第四阶段：数据库读写分离

为了解决数据库的瓶颈，在这个架构就需要搭建高可用的数据库架构，为数据库构建一主多从，使用主从复制的方式同步数据。大部分的场景下，基本都是读多写少，所以在做完主从架构之后，数据的读写就要发生改变了，以前单台的时候读写都是在一台数据库上，对数据库造成了很大的压力。此时可以将写请求都直接放到主库上，接着读请求都直接从 从库里面去取数据。后续还有几个演化阶段：

架构演化第五阶段：使用反向代理和CDN加速网站响应

架构演化第六阶段：使用分布式文件系统和分布式数据库系统

架构演化第七阶段：使用NoSQL和搜索引擎

架构演化第八阶段：业务拆分

架构演化第九阶段：微服务及中台化

现在的大型互联网公司基本都已经到了这个阶段。



后续的几个演化阶段还没想好该怎么去描述，暂时先写到这里吧，后续有时间再补上其他的几个演化阶段说明。