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

时间:2023-02-28 08:55:47

正序:

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代码也包含了前端的HTMLJSCSS,比之前先进的是,我们还引入了文件
服务器,文件服务器可以存储我们用户的头像、文件等,数据库还是和之前一样,保存用户的
信息。

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

4. 服务器分离

用户<-> 服务器(war)<-> 文件服务器 : 数据库 ;
Web服务器、文件服务器 、 数据库分离。

一个服务器的资源是有限的,为了承载更多的业务处理请求,我们将文件服务器和数据库
“搬离”原有服务器,找到新的服务器为他俩“安家”。

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

5. 服务器分离+缓存

服务器分离+数据库中间添加缓存中间件

数据库访问是所有性能瓶颈中最常见的,其中主要原因有:
①:数据库的连接数。
②:表数据量大(空间存储问题)。
③:硬件资源限制,硬件资源直接影响QPS每秒查询数/TPS每秒事务数。
其中常见的数据性能优化方案:SQL优化、缓存、创建索引、读写分离、分库分表等,添加
缓存中间件就是缓存的方式,可有效减少对数据库的访问,较少了访问也就不存在上述的性
能瓶颈。

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

6. 负载均衡+集群

tomcat应用集群、文件服务器集群、缓存集群、单数据库

孙悟空有很多本领,包括火眼金睛、72变、法天象地等等,但是我最喜欢的还是他的“身外身”
技能,使用此仙术可以以一化十,以十化百,百千万亿之变化。

一个大型网站架构的演变历程
集群也很好理解,就是进行自我复制,集群中的每个节点所干的活都是一样的,就算其中一个节点挂掉,也不会影响整个网站的正常使用。

负载均衡就是通过nginx或者其他代理服务器,让每台web服务器所接受的负载(用户请求)能够平均一些,不要抓着一直羊疯狂薅羊毛。

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

7. 负载均衡+集群+数据库读写分离、主从复制

读写分离,主从复制:

如果加了缓存集群,数据库的压力还是很大的话,我们就会考虑对数据库进行读写分析,
即增删改的操作在主-数据库,查询的操作在从-数据库。主库定时同步数据至从数据库。

这里主从复制可以推荐一片文章:数据库(mysql)主从复制与读写分离
一个大型网站架构的演变历程

8. 负载均衡+集群+分库分表

主数据库集群、从数据库集群、数据库集群间的同步

没啥可说的,单体的下一步永远都是集群,数据库也免不了俗,对数据库进行分库分表就会形
成我们的主-数据库集群(从-数据库集群是对应节点的复制),分库分表后我们数据库的主键
就不能采用自增的方式了,而应该是全局唯一主键。

全局唯一主键生成方式推荐文章:分布式系统全局唯一ID的几种实现方式
一个大型网站架构的演变历程

9. 负载均衡+集群+搜索引擎技术

如果我们的业务需求中有模糊查询的需求,我们需要引入搜索引擎技术,而不是直接将模糊
搜索的请求发到数据库,常用的搜索引擎技术就是Elasticsearch,如果需要进行全文搜索
,那么ES就是最好的解决方案。

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

10.微服务

 淘宝为例,大型网站项目都会拆成微服务的一个个集群,数据库也需要进行拆分,
 作为单独的商品、订单的数据库。此时需要考虑分布式事务。   

推荐分布式事务的文章:分布式事务六种解决方案
一个大型网站架构的演变历程

11.调优

最后就是对JVMTomcat、数据库、Linux、架构调优... 

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

结束语:

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