淘宝网站的架构技术演进

jacket1
342 阅读8分钟

一、说在前面

本文以淘宝作为示例，介绍从一百个并发到千万级并发情况下服务端的架构的演进过程，同时列举出每个演进阶段会遇到的相关技术。希望大家有收获

二、须知技术概念

分布式

系统中的多个模块在不同服务器上部署，即可称为分布式系统，如Tomcat和数据库分别部署在不同的服务器上，或两个相同功能的Tomcat分别部署在不同服务器上

高可用

系统中部分节点失效时，其他节点能够接替它继续提供服务，则可认为系统具有高可用性

集群

一个特定领域的软件部署在多台服务器上并作为一个整体提供一类服务，这个整体称为集群。如 Zookeeper 中的 Master 和 Slave 分别部署在多台服务器上，共同组成一个整体提供集中配置服务。在常见的集群中，客户端往往能够连接任意一个节点获得服务，并且当集群中一个节点掉线时，其他节点往往能够自动的接替它继续提供服务，这时候说明集群具有高可用性

负载均衡

请求发送到系统时，通过某些方式把请求均匀分发到多个节点上，使系统中每个节点能够均匀的处理请求负载，则可认为系统是负载均衡的

正向代理和反向代理

系统内部要访问外部网络时，统一通过一个代理服务器把请求转发出去，在外部网络看来就是代理服务器发起的访问，此时代理服务器实现的是正向代理；

当外部请求进入系统时，代理服务器把该请求转发到系统中的某台服务器上，对外部请求来说，与之交互的只有代理服务器，此时代理服务器实现的是反向代理。

简单来说，正向代理是代理服务器代替系统内部来访问外部网络的过程，反向代理是外部请求访问系统时通过代理服务器转发到内部服务器的过程。

三、架构演进

3.1 单机架构

在这里插入图片描述

在淘宝的应用数量与用户数都较少的时时候，淘宝就把 Tomcat 和数据库部署在了同一台服务器上。当用户(浏览器)输入 www.taobao.com 发起请求时，请求首先经过 DNS 服务器（域名解析服务器），由 DNS 把域名转换为淘宝主机的公网 IP 地址 10.102.4.1，浏览器转而访问该IP对应的 Tomcat。

但随着用户量的日益增多，淘宝的那一台服务器(单机)中 Tomcat 与数据库又存在资源的竞争（具体表现为数据库占用内存日趋增大，请求存储数据也越来越多，以及 Tomcat 接受和响应的用户请求也越来越频繁），所以有了第一次技术演进 --->

3.2 应用分开部署

在这里插入图片描述
分开部署后，Tomcat 和数据库应用之间不存在资源的抢占，所以性能稍有提高

随着淘宝的流行，用户数量自然也就提上去了，多人同时请求同一商品页面的几率大大增加，这就要考验数据库的并发读写能力了。推进第二次技术演进 --->

3.3 引入本地、分布式缓存

在这里插入图片描述
通过再Tomcat服务器和 JVM 内部加入本地缓存和在 redis 中增加分布式缓存：缓存热门商品的信息、热门商品的 html 页面，可以提前在请求到达数据库之前，把数据返回给请求页面，减轻数据库的读写压力

数据库的读写压力是降低了，但是 Tomcat 依旧要接受越来越多的请求，所以它的压力并没有降低。第三次架构技术演进 --->

本次演进存在的问题：缓存一致性、缓存穿透/击穿、缓存雪崩、热点数据集中失效等。

3.4 引入反向代理实现负载均衡

在这里插入图片描述
使用代理软件 Nginx，把请求平均分发到部署在不同服务器的 Tomcat 上，比如 Nginx 支持10000个并发请求，Tomcat支持2000个并发(假如 Tomcat 有5个)，那么通过代理服务器就可以挡住这10000个并发。这就是负载均衡。

反向代理使应用服务器可支持的并发量大大增加，但并发量的增长也意味着更多请求穿透到数据库，单机的数据库最终成为瓶颈引进了第四次架构技术演进 --->

本次演进存在的问题：应用的 Nginx 和 HAProxy 软件都是工作在网络第七层的反向代理软件，主要支持 http 协议，还会涉及 session 共享、文件上传下载的问题。

Nginx (engine x) 是一个高性能的 HTTP 和反向代理web服务器，同时也提供了 IMAP/POP3/SMTP 服务
HAProxy 是一个使用C语言编写的自由及开放源代码软件[1]，其提供高可用性、负载均衡，以及基于TCP和HTTP的应用程序代理。

3.5 数据库读写分离

在这里插入图片描述
通过分开安装读取库与写入库，并通过同步机制使写入库的数据实时更新到读取库中，这样就分担了数据库的读写压力，涉及的技术有数据库中间件 Mycat

Mycat 可以实现读写分离下的读操作负载均衡，将大量的读操作均衡到不同的从库上，主要出现在一主多从情形下。
Mycat 的工作原理就是：拦截用户发来的SQL语句，对SQL语句做了一些特定的分析，如分片分析，路由分析，读写分离分析，缓存分析等，然后将此SQL发往后端的真实数据库，并将返回的结果做适当处理，最终返回给用户。
详情参考 ---> 此文章

业务逐渐变多，不同业务之间的访问量差距较大，不同业务直接竞争数据库，相互影响性能 ---> 第5次技术架构演进

3.6 按业务分离数据库

在这里插入图片描述

把不同业务的数据保存到不同的数据库中，使业务之间的资源竞争降低，对于访问量大的业务，可以部署更多的服务器来支撑。

本次演进存在的问题：可能会导致跨业务的表无法直接做关联分析，需要通过其他途径来解决 ---> 第6次演进

3.7 数据库分表

在这里插入图片描述
当查询、存储某件商品的评论数据时，可按照商品ID 进行 hash，路由到对应的表中存储；针对 user 的支付记录，可按照小时(时间单位)创建表，每个小时表继续拆分为小表，使用用户ID或记录编号来路由数据。

只要实时操作的表数据量足够小，请求就能够足够均匀的分发到多台服务器上的小表，数据库从而就能通过水平扩展的方式来提高性能。其中前面提到的Mycat也支持在大表拆分为小表情况下的访问控制。

本次演进存在的问题：这种做法显著的增加了数据库运维的难度。数据库设计到这种结构时，已经可以称为分布式数据库，但是这只是一个逻辑的数据库整体，数据库里不同的组成部分是由不同的组件单独来实现的，如分库分表的管理和请求分发，由bMycatn实现，sql 的解析由单机的数据库实现，读写分离可能由网关和消息队列来实现，查询结果的汇总可能由数据库接口层来实现等等，这种架构其实是 MPP（大规模并行处理）架构的一类实现。

MMP 数据库主要作用：能把一个查询解析为分布式的执行计划分发到每台机器上并行执行，最终由数据库本身汇总数据进行返回。有关MMP数据库可以自行查阅资料。

数据库和 Tomcat 都能够水平扩展，这意味着可支撑的并发大幅提高，但随着用户数的增长，最终单机的 Nginx 会成为性能瓶颈 ---> 第7次演进

3.8 使用LVS或F5来使多个Nginx负载均衡

读到这里，相信各位对网站的性能优化会有一个宏观的认知了，接下来的内容就等博主待办了...

avatar
文章
阅读
粉丝