大型网站架构演变

前言

博主毕业后从事互联网领域研发工作也有些年头了，混迹过一些互联网公司，也参与过不少系统的研发。从本文开始，将对这些年的经历做一个回顾总结。同时结合自己多年电商领域经验，尝试完成从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调优等。

小结

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