一个大型网站架构的演变历程

Posted 2023-03-07 Champion-Dai

正序：

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、架构调优... 

结束语:

天下合久必分、分久必合，网站架构的演变是没有尽头的，也没有绝对的完美架构适配所有
公司，我们能做的就是不断的观察、思考、改变、总结，周而复始...