一个大型网站架构的演变历程是什么（一个大型网站架构的演变历程）
正序：
Rome was not built in a day（罗马不是一天建成的 。）一个成熟的大型网站从来都不是一蹴而就的 ，需要经过多次架构的调整和升级 ，我们熟知的大型网站比如京东 、淘宝 、亚马逊 ，它们每天都有巨大的用户访问量也拥有非常大的数据体量 ，通过对大量数据进行收集 ，网站又进一步做大数据治理 、分析和应用 ，以此来提高网站的智能 ，增加用户的粘性 。总结一下这些大型网站基本都有以下几种特征：
①：高并发 、流量大 。 ②：高可用 ，7*24小时不间断的服务 。 ③：大数据 ，对海量数据进行分析 、治理 ，再次服务于业务 。 ④：敏捷开发 ，迭代快 ，一般来说1~2周就要迭代一次 。 ⑤：用户体系庞大 。 ⑥：可持续升级 ，技术服务于业务 ，随着业务量的升级架构也跟着升级 。 ⑦：安全防范 ，会面对更多的Web漏洞 、服务器漏洞等 。 ⑧：弹性拓展 ，可以进行动态扩缩容 。 ⑨：吞吐量高 ，响应速度快 。通过上述特性我们了解到了大型网站的厉害之处 ，但其实它的初始形态是简单的 ，就像人类演变
一样 ，网站也是一步步从单体 -> 集群 -> 分布式 -> 微服务/容器化 演变而来 ，都是为了更好的适配当前的用户体量和业务发展 。下来就进入到我们的正文环节 。
1. 单向
用户->浏览器->服务器
混沌初开 ，一个网站最初始的设计形态就是一个“静态网页 ” ，用户单向的在浏览器中进行 内容浏览 ，而浏览的内容就是服务器通过HTML对一些固定的 、已经写好了的“文章 ”的显示 。2. 双向
用户<->浏览器<->服务器<->数据库
单向的浏览对于用户来说是乏味的 ，随着技术的发展 ，我们可以实现用户和服务器之间的 双向交互 ，而实现的关键就是架构引入了数据库 ，网站可以对用户的数据进行存储和反馈 。3. 单体架构
用户<->服务器【war<-> (文件服务器 / 数据库)】
做过早期Java-Web项目兄弟 ，肯定对Tomcat特别熟悉 ，这是一款Web服务器 ，每次做完新的 需求我们都需要将项目打成War包并在Tomcat上进行部署 ，War包中包含了我们通过的MVC架 构写的后端Java代码也包含了前端的HTML 、JS 、CSS,比之前先进的是 ，我们还引入了文件 服务器 ，文件服务器可以存储我们用户的头像 、文件等 ，数据库还是和之前一样 ，保存用户的 信息 。4. 服务器分离
用户<-> 服务器（war）<-> 文件服务器 : 数据库 ;
Web服务器 、文件服务器 、 数据库分离 。 一个服务器的资源是有限的 ，为了承载更多的业务处理请求 ，我们将文件服务器和数据库 “搬离 ”原有服务器 ，找到新的服务器为他俩“安家 ” 。5. 服务器分离+缓存
服务器分离+数据库中间添加缓存中间件
数据库访问是所有性能瓶颈中最常见的 ，其中主要原因有： ①：数据库的连接数 。 ②：表数据量大（空间存储问题） 。 ③：硬件资源限制 ，硬件资源直接影响QPS每秒查询数/TPS每秒事务数 。 其中常见的数据性能优化方案：SQL优化 、缓存 、创建索引 、读写分离 、分库分表等 ，添加 缓存中间件就是缓存的方式 ，可有效减少对数据库的访问 ，较少了访问也就不存在上述的性 能瓶颈 。6. 负载均衡+集群
tomcat应用集群 、文件服务器集群 、缓存集群 、单数据库
孙悟空有很多本领 ，包括火眼金睛 、72变 、法天象地等等 ，但是我最喜欢的还是他的“身外身 ” 技能 ，使用此仙术可以以一化十 ，以十化百 ，百千万亿之变化 。集群也很好理解 ，就是进行自我复制 ，集群中的每个节点所干的活都是一样的 ，就算其中一个节点挂掉 ，也不会影响整个网站的正常使用 。
负载均衡就是通过nginx或者其他代理服务器 ，让每台web服务器所接受的负载（用户请求）能够平均一些 ，不要抓着一直羊疯狂薅羊毛 。
7. 负载均衡+集群+数据库读写分离 、主从复制
读写分离 ，主从复制：
如果加了缓存集群 ，数据库的压力还是很大的话 ，我们就会考虑对数据库进行读写分析 ， 即增删改的操作在主-数据库 ，查询的操作在从-数据库 。主库定时同步数据至从数据库 。这里主从复制可以推荐一片文章：数据库(mysql)主从复制与读写分离
8. 负载均衡+集群+分库分表
主数据库集群 、从数据库集群 、数据库集群间的同步
没啥可说的 ，单体的下一步永远都是集群 ，数据库也免不了俗 ，对数据库进行分库分表就会形 成我们的主-数据库集群（从-数据库集群是对应节点的复制） ，分库分表后我们数据库的主键 就不能采用自增的方式了 ，而应该是全局唯一主键 。全局唯一主键生成方式推荐文章：分布式系统全局唯一ID的几种实现方式
9. 负载均衡+集群+搜索引擎技术
如果我们的业务需求中有模糊查询的需求 ，我们需要引入搜索引擎技术 ，而不是直接将模糊 搜索的请求发到数据库 ，常用的搜索引擎技术就是Elasticsearch ，如果需要进行全文搜索 ，那么ES就是最好的解决方案 。10.微服务
淘宝为例 ，大型网站项目都会拆成微服务的一个个集群 ，数据库也需要进行拆分 ， 作为单独的商品 、订单的数据库 。此时需要考虑分布式事务 。推荐分布式事务的文章：分布式事务六种解决方案
11.调优
最后就是对JVM 、Tomcat 、数据库 、Linux 、架构调优...结束语:
天下合久必分 、分久必合 ，网站架构的演变是没有尽头的 ，也没有绝对的完美架构适配所有 公司 ，我们能做的就是不断的观察 、思考 、改变 、总结 ，周而复始...创心域SEO版权声明：以上内容作者已申请原创保护，未经允许不得转载，侵权必究！授权事宜、对本内容有异议或投诉，敬请联系网站管理员，我们将尽快回复您，谢谢合作！