大型网站架构演变

前言

博主毕业后从事互联网领域研发工作也有些年头了,混迹过一些互联网公司,也参与过不少系统的研发。从本文开始,将对这些年的经历做一个回顾总结。同时结合自己多年电商领域经验,尝试完成从0到1的电商项目,从单体应用到逐步实现集群、分布式、再到微服务的架构演变~希望能有所沉淀,温故而知新,下面我们开始吧~

什么是大型网站?

有时候要下个定义挺难的,那么就从具体来说吧。博主曾经在京东工作过,大家都知道京东是个大型网站,这点应该没有异议。那它有哪些特点呢?

第一,用户体系庞大、活跃

几年前,早就过亿了,日活也至少几千万。

第二,拥有海量数据,支持大数据分析

每天产生的用户浏览、收藏、订单等数据,存储了不知道多少,背后大数据进行离线、实时计算、模型训练,得到用户画像、进行个性化智能推荐,实现千人千面。

第三,高并发、高可用、响应速度快

这是必须的,618、11.11,都是购物狂欢节,不能影响用户体验。

第四,安全

正所谓树大招风,安全第一,需要有相应团队来防范,用户的各种数据,要防止攻击和泄露。

演变的那些事

在web1.0时代,用户是通过浏览器,单向的访问服务器上的静态网页资源的。

到后来,出现了数据库,用户和服务器之间可以双向交互,可以进行一些增加、修改的操作,并保存到数据库中,进行持久化存储。

在早期,比如传统的Java Web开发,使用MVC模式,通过把应用打成一个war包部署到服务器上,注意到这样的网站早期是没有多少流量的,一般文件服务器和数据库服务器也在应用服务器上,即是一个单体应用。

随着业务的发展,我们知道单体应用面临诸多问题,比如,由于文件服务器、数据库服务器和应用服务器都部署在同一台,会导致网站的并发能力、存储能力受到限制,而且一旦应用服务器挂掉,意味着文件服务器和数据库服务器将无法访问了。为了避免这样的毁灭性打击,于是出现了分离的方式,也就是把上面的各个不同角色的服务器分离成不同节点,分开部署。

我们知道,用户的大部分请求如果都直接落到数据库上,那么db的压力将变大,请求延时将增加,用户体验会下降,并发也提不上去,导致用户流失。为了提高请求、响应速度,一定程度上保护db,同时提升并发能力,我们可以使用缓存中间件(比如redis)。

到这里,我们会发现,不论是我们的应用服务器,还是文件、缓存服务器,都是单点的,如果挂了的话,对我们的网站将是灾难性的,因此,又走向了集群的方式:

虽然,我们使用到了缓存中间件,但是一部分读操作、全部的更新操作,依然会落到数据库这边。当我们的网站用户达到千万级别以上的时候,数据库负载能力就成为了瓶颈。既然数据库同时进行读、写操作压力很大,那么我们可以考虑进行读写分离。

用户的大概20%的是写操作,80%的是查询操作,即“二八原则”。通过采用数据库读写分离模式,主库负责写请求,从库负责读请求,这样2波不同类型的流量被分配到不同节点上,从而改善了数据库的负载能力。需要重点注意的是,主从之间需要数据同步。

到这里,就结束了么?不是的,大型网站随着业务越来越多,越来越复杂,数据量也很大,如果采用上面的架构,显然一旦db扛不住了,那就over了。于是,又需要对db进行分库分表操作了。

所谓分库分表,即把同一张表的数据,根据一定的规则算法,散列到不同库上,有点分布式数据库的味道,这也是我们对db进行拆分的一种手段。这里需要特别注意的是,进行分库分表的话,每一张表的主键问题,不可以自增长,而是需要使用全局主键,也就是分布式全局id。

到这里,我们还可以想一下,如何为db继续减负呢?我们知道,用户的搜索请求其实蛮多的,如果利用缓存中间件和db来实现的话,其实比较费劲的。

通过使用es/solor等搜索引擎,能让海量搜索变的简单易用,也保护了db。

让我们继续,如果我们的网站是一个电商类的,那么会有商品业务、订单业务、库存业务、物流业务等等。那我们应该将这些业务独立拆分成产品线,成为一个个独立的子系统(or 服务),交给不同团队进行维护。

到这里,其实我们的网站,就处于一个微服务的阶段了。由于用户的一些请求,需要到达多个业务系统来完成,所以这里又出现分布式事务的问题。在不同的服务集群进行通信的时候,可能涉及到一些分布式中间件,比如mq,zookeeper等。在演变的过程中,除了架构的调整,我们还可能涉及到一些调优,比如JVM/db调优等。

小结

到这里,我们可以看到大型网站,并非一蹴而就,而是逐步演变、迭代升级的。朋友们,下篇见(详情可以参见,我的公众号:丰哲同学 )~

你可能感兴趣的:(大型网站架构演变)