本文转载自微信公众号「Cone的编程屋」，作者Cone。转载本文请联系Cone的编程屋公众号。
你好，我是Cone。
最近在读大型互联网架构这本书，今天想你一起唠嗑唠嗑架构，你可能耳熟能详的高并发、大流量、海量数据、分布式等等这些词汇，但是每个词汇背后其实都是为了解决当前所出现的问题所总结出的一套架构范式，今天一起来扒一扒架构。
读完本文，能够让你理解单一应用到大型应用的架构演进历程。
文本大纲
单一应用服务阶段
所有的大型网站都是由最小型的网站架构演变而来的。回想一下你最开始写服务端代码，是不是数据库MySQL在本地，服务器也是本地，那最初阶段也是这样的，网站的流量也不大，通常就将应用服务、数据服务、文件资源等所有资源都放在一台服务器上，比如我们学java web的时候，都是利用Tom??等Web容器开始运行应用服务程序，比如JSP，然后需要数据库的时候用JDBC去连接本地Mysql Server。一图胜千言：
应用与数据服务分离阶段
经过业务发展迭代增加，用户量、日活的上升，简单的一台服务器就搞不定了。比如可能由于用户产生的数据量过多导致存储空间不够，而一台服务器同时得处理数据服务和用户的应用web响应，CPU资源有限的情况下，是无法满足用户想要快速响应需求的，网站的访问数据变得越来越慢，而数据服务和应用服务所对计算机资源的需求是不一样的，比如应用服务器需要更多的CPU资源，给这台服务器配上多几核的CPU，数据服务可能需要与磁盘打交道，配备更多的闪存。
这时候就将应用服务和数据服务进行分离。将应用服务器单独出来，专注于响应web请求，提高用户的访问速度，将数据库单独放在一台服务器，专注于处理与应用服务器打过来的数据请求，将文件资源放在一台服务器上，与应用服务器打交道，为其提供文件服务，一图胜千言：
利用缓存提高性能阶段
随着用户的再增加，业务的再次升级。网站有面临了一个数据库服务的压力太大而导致整体的访问效率下降，再次影响用户的访问体验。
你可以想象，我们日常的微博、抖音那些热点数据，是几个每个打开这些应用的人会请求到的。所以二八定律永远存在，80%的请求在20%的数据上。所以这个时候将这20%的数据进行高校的缓存起来，这样网站整体的性能又可以提升了。
缓存可以分为两种：一种的直接缓存在应用服务器上，另外是一种开一台缓存服务器进行缓存。后者可以进行很好的弹性伸缩，而前者会受到本地容量的限制。我们称后者服务器为：分布式缓存服务器。
目前笔者写的后端程序也在这个阶段，也在尝试往后续集群方向演进。一图胜千言：
应用服务集群阶段
当使用缓存后，数据库的访问压力得到有效缓解。再次随着业务的增加，单一应用服务器能够并发处理的请求连接有限，在流量的高峰期，应用服务器开始成为整个系统的性能瓶颈。
因此这个时候就开始组件应用服务器集群，不仅应用服务器有集群，缓存服务器等也可以组成集群。那么既然有了服务器集群，那对于这些请求，到底应该有哪台服务器响应呢。所以负载均衡调度服务器就出现了。
通过负载均衡调度服务器，可将来自浏览器的访问请求分发到应用的集群中的任何一台服务器上。使用服务器集群也有个好处，Web 应用程序更新可以做到用户无感知，当有一个节点的服务器宕机之后，也不影响整体的请求。
一图胜千言：
数据库读写分离阶段
虽然增加了数据缓存这一层。比如利用redis缓存，但是随着用户量的不断增加。总有一些是无法通过缓存提高的，比如还可能出现缓存过期、缓存没有命中等情况。那么这些请求全部会打到数据库服务器上，这个时候数据库服务成为了整个系统的瓶颈。所以数据读写分离就出现了。
目前大部分的数据库都提供了一个主从热备的功能。通过配置主从两台服务器，当应用服务器往主服务器写入诗句时，利用主从复制机制将数据更新同步到从数据库上。读写分离之后，数据库的性能瓶颈就解决了。一图胜千言：
反向代理与CDN加速阶段
当网站业务再次升级，用户规模再次扩大，为了满足不同地区的用户访问速度，提高响应速度，CDN和反向代理就出现了，两者基本原因都是缓存。
CDN就是内容分发网络，你的请求响应服务器会从距离你最近的一个服务器集群上响应回来，比如你在云南，可能就从云南的机房响应。
而反向代理则部署在中心机房，当请求来到中心机房后，首先访问的时候反向代理服务器，看看是否名字缓存，如果命中则直接返回。一图胜千言：
分布式数据库阶段
分布式数据库是系统数据库拆分的最后手段，这只有在单表数据规模非常大的时候才会用，一般的数据库拆分都是对业务拆分后将不同的业务数据部署在不同的服务器上。如下图：
NoSQL与搜索引擎阶段
当成为大型系统的时候，搜索成为了日常需求，这时会采用NoSQL和搜索引擎来提高搜索效率，缓存的时候redis也是NoSQL类型的。如下图：
业务拆分阶段
当业务日渐的增多，可能团队人员也不利于管理，这个时候大型的系统都会进行业务拆分，比如抖音就拆了很多很多业务线。每条业务线服务不同的服务，每个服务都单独进行部署，可以通过消息队列进行数据分发。如下图：
分布式服务阶段
随着业务拆分越来越小，存储系统越来越庞大，应用系统的整体复杂度呈指数级增加，部署维护越来越困难。
既然每一个应用系统都需要执行许多相同的业务操作，比如用户管理、商品管理等，那么可以将这些共用的业务提取出来，独立部署。由这些可复用的业务连接数据库，提供共用业务服务，而应用系统只需要管理用户界面，通过分布式服务调用共用业务服务完成具体业务操作。如下图：
总结
目前很少有人能经历上面的系统演进，大部分大型的系统已经成型，而小系统可能又很可能撑不到成为大系统，所以很少有人能经历这些，不过了解这些，我们对于整个系统架构的理解非常有帮助。
