1 分钟抗住 10 亿请求！某些 App 怎么做到的？

水深无声 2023-07-19 08:27 22阅读 0赞

# 某些App怎么扛住1分钟10亿请求？ #

**架构的演进路线**

百万级并发：1秒100万次请求。

千万级并发：一分钟6亿次请求，差不多就是需求的极限。

架构的设计和架构优化要符合需求本身，不能无限制优化。

**基本概念**

（1）分布式（系统中，多个模块在不同服务器上部署）

（2）集群（一个软件部署在多台服务器，并作为一个整体，提供一类服务）

（3）高可用（系统中部分节点失效，其他节点能够接替它继续工作或有相应的处理预案）

（4）负载均衡（把请求均匀的发到多个节点上）

**架构演进：**

![1 分钟抗住 10 亿请求！某些 App 怎么做到的？| 原力计划][1 _ 10 _ App _]

![1 分钟抗住 10 亿请求！某些 App 怎么做到的？| 原力计划][1 _ 10 _ App _ 1]

DNS服务器，做域名解析的服务器，作用是，经过DNS将www.taobao.com这类的域名转换为实际IP地址，浏览器转而访问这个IP对应的tomcat。

瓶颈：用户增长，tomcat和数据库之间竞争资源，单机性能不足以支撑业务。

![1 分钟抗住 10 亿请求！某些 App 怎么做到的？| 原力计划][1 _ 10 _ App _ 2]

**第一次：Tomcat和数据库分开部署（最常见架构）**

![1 分钟抗住 10 亿请求！某些 App 怎么做到的？| 原力计划][1 _ 10 _ App _ 3]

Tomcat和数据库分别独占服务器资源，显著提高两者各自性能（tomcat服务器找一个内存大的，DB服务器找一个硬盘大的，带宽更宽的）。

瓶颈：用户量增长，数据库并发读写，尤其是读，成为瓶颈。

注意，不会通过数据库集群解决。

![1 分钟抗住 10 亿请求！某些 App 怎么做到的？| 原力计划][1 _ 10 _ App _ 4]

**第二次演进：引入本地缓存甚至分布式缓存**

![1 分钟抗住 10 亿请求！某些 App 怎么做到的？| 原力计划][1 _ 10 _ App _ 5]

在Tomcat服务器上（Java程序所在的地方）加入缓存，可以把绝大多数请求（尤其是查询）在访问数据库前拦截掉。

![1 分钟抗住 10 亿请求！某些 App 怎么做到的？| 原力计划][1 _ 10 _ App _ 6]

Redis放在Tomcat服务器上，如果不够用。

那么Redis可以自己放在一个服务器，也可以多弄几台Redis服务器，配置成主从同步（提升可用性可以加上哨兵）。

瓶颈：用户数量增长，并发压力主要在单机的tomcat上，响应逐渐变慢。

![1 分钟抗住 10 亿请求！某些 App 怎么做到的？| 原力计划][1 _ 10 _ App _ 7]

**第三次演进：引入反向代理和负载均衡**

![1 分钟抗住 10 亿请求！某些 App 怎么做到的？| 原力计划][1 _ 10 _ App _ 8]

使用反向代理，将大量的用户请求，均匀分发到每个Tomcat中（一般来讲，Tomcat对应100个并发，nginx对应5万个并发，具体的要看服务器性能）。

瓶颈：应用服务器可支持的并发量大大增加，缓存能力也可以轻易扩展，并发量增长意味着更多请求穿透到数据库，单机的数据库最终成为瓶颈。

![1 分钟抗住 10 亿请求！某些 App 怎么做到的？| 原力计划][1 _ 10 _ App _ 9]

**第四次演进：数据库读写分离**

![1 分钟抗住 10 亿请求！某些 App 怎么做到的？| 原力计划][1 _ 10 _ App _ 10]

把数据库划分为读库和写库，读库可以有多个，通过同步机制把写库的数据同步到读库，使用数据库中间件（Mycat），通过它来组织数据库的分离读写。

瓶颈：业务逐渐变多，不同业务之间的访问量差距较大，不同业务直接竞争数据库，相互影响性能。

![1 分钟抗住 10 亿请求！某些 App 怎么做到的？| 原力计划][1 _ 10 _ App _ 11]

**第五次演进：数据库按业务分库**

![1 分钟抗住 10 亿请求！某些 App 怎么做到的？| 原力计划][1 _ 10 _ App _ 12]

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

瓶颈：用户数量增长，单机的写库会逐渐达到性能瓶颈。

![1 分钟抗住 10 亿请求！某些 App 怎么做到的？| 原力计划][1 _ 10 _ App _ 13]

**第六次演进：把数据库的大表拆成小表**

其他环节同上。

![1 分钟抗住 10 亿请求！某些 App 怎么做到的？| 原力计划][1 _ 10 _ App _ 14]

比如针对订单生成，可以按照月份，甚至小时创建表。

这种做法可以称作分布式数据库，但逻辑上仍然是一个完整的数据库整体，现在有一种架构叫MPP（大规模并行处理），针对于各种这类问题的使用场景。

瓶颈：数据库和tomcat都可以大规模水平扩展，最终单机的nginx会成为瓶颈。

![1 分钟抗住 10 亿请求！某些 App 怎么做到的？| 原力计划][1 _ 10 _ App _ 15]

**第七次演进：使用LVS让多个Nginx负载均衡**

LVS是软件，运行在操作系统内核态，可以对TCP请求或高层网络协议进行转发，分发的性能远高于Nginx，大概十几万。

F5是硬件，跟LVS做的事情类似，但性能更高，而且价格昂贵。

![1 分钟抗住 10 亿请求！某些 App 怎么做到的？| 原力计划][1 _ 10 _ App _ 16]

这种方式，用户可达千万或上亿级别。

瓶颈：LVS达到瓶颈，或用户分布在不同的地区，与服务器机房的距离不同，导致访问延迟的不同。

![1 分钟抗住 10 亿请求！某些 App 怎么做到的？| 原力计划][1 _ 10 _ App _ 17]

**第八次演进：DNS轮询实现机房间的负载均衡**

![1 分钟抗住 10 亿请求！某些 App 怎么做到的？| 原力计划][1 _ 10 _ App _ 18]

在DNS中配置一个域名对应多个IP。

每个IP地址对应到不同的机房里的虚拟IP。

做到机房级别的水平扩展，已经是从请求并发量来讲，过亿的处理方案，十几亿或几十亿的并发，暂时没人考虑。

瓶颈：检索，分析的需求越来越多，单靠数据库无法解决各种各样的需求。

![1 分钟抗住 10 亿请求！某些 App 怎么做到的？| 原力计划][1 _ 10 _ App _ 19]

**第九次演进：引入NoSQL数据库和搜索引擎**

![1 分钟抗住 10 亿请求！某些 App 怎么做到的？| 原力计划][1 _ 10 _ App _ 20]

数据量多到一定规模的时候，关系型数据库不再适用，而且数据量较大的查询，MySQL不一定能运行出结果，对于海量数据的处理，通过分布式文件系统HDFS来存储，对于key-value类型的数据，通过HBase、Redis等处理，对于抓取查询，可以通过ES等解决，对于多维分析，通过kylin、Druid等解决。

引入更多的组件同时必然极大的提高系统复杂度，不同的组件的数据还需要同步，需要考虑一致性问题。

![1 分钟抗住 10 亿请求！某些 App 怎么做到的？| 原力计划][1 _ 10 _ App _ 21]

**第十次演进：大应用拆为小应用**

结构图中上下不变：

![1 分钟抗住 10 亿请求！某些 App 怎么做到的？| 原力计划][1 _ 10 _ App _ 22]

按照业务板块来划分应用，使单个应用的职责更清晰，相互之间可以做到独立升级迭代，甚至可以做到部分功能关闭。

瓶颈：不同应用之间，存在公用的模块，导致包含公共功能的部分在升级时，全部相关代码都要跟着升级。

![1 分钟抗住 10 亿请求！某些 App 怎么做到的？| 原力计划][1 _ 10 _ App _ 23]

第十一次演进，抽离成微服务

类似于我们现在写的SpringCloud的项目结构，尤其是当用户，支付等功能在多个应用中都存在，抽离出来效率更高

现在想实现这种效果，可以用现成的框架。

再往下演进，ESB服务总线做接口管理，容器化技术实现运行环境隔离，云平台承载大型系统

云平台中的几个概念：

IaaS：基础设施即服务，可申请硬件资源的层面。

PaaS：平台即服务，提供云平台常用的技术组件的开发和维护。

SaaS：软件即服务，开发好一个应用，部署之后，按照功能或要求付费。

![1 分钟抗住 10 亿请求！某些 App 怎么做到的？| 原力计划][1 _ 10 _ App _ 24]

**总结**

（1）架构调整是否必须按照上面的路线演变？

不一定！！！上面讲的是电商方向，已有的演化线路。

（2）对于即将实施的系统，架构要设计到什么程度？

够用就行，问清楚什么叫够用，设计要满足下一阶段用户量和性能指标的要求。

（3）微服务和大数据架构？

这俩架构，解决的是同一个系统中，不同环节的问题。

不用比好坏，也不用分开处理。

[1 _ 10 _ App _]: /images/20230528/de4b60cab81a41b0860bfe81913d9121.png
[1 _ 10 _ App _ 1]: /images/20230528/09eb594c770b4c4bbb6a2681897d8b01.png
[1 _ 10 _ App _ 2]: /images/20230528/72b8b7db121f48b9a12e96419e8804db.png
[1 _ 10 _ App _ 3]: /images/20230528/958732e8821c457882c4a27f78fe1b74.png
[1 _ 10 _ App _ 4]: /images/20230528/19e7f2326dd4483f86a150d5db2f2c58.png
[1 _ 10 _ App _ 5]: /images/20230528/b40e21f8969f43fdb5548801bb2ed24a.png
[1 _ 10 _ App _ 6]: /images/20230528/03d1fa624d984d45be5326532799c474.png
[1 _ 10 _ App _ 7]: /images/20230528/dd1ed06e1df54ba5ab52324a73fe1f35.png
[1 _ 10 _ App _ 8]: /images/20230528/8387d73fc6ba4ea081a48eae5bbd66d7.png
[1 _ 10 _ App _ 9]: /images/20230528/b1e8312ea49a4a738c5e53b3f0f0836f.png
[1 _ 10 _ App _ 10]: /images/20230528/15a039890f0b4d3899d080f1e2d0a9ab.png
[1 _ 10 _ App _ 11]: /images/20230528/5fac11b31ae2414ebbd2dacd0a80bc2e.png
[1 _ 10 _ App _ 12]: /images/20230528/4bb7ce977e0b40b98eb7ee602a944bbd.png
[1 _ 10 _ App _ 13]: /images/20230528/b927ceb139ca4825bfe5d4943aafab99.png
[1 _ 10 _ App _ 14]: /images/20230528/227224558fe345e1ab09f3c2a58dd224.png
[1 _ 10 _ App _ 15]: /images/20230528/4ca11559a2764917b2d7cd3af9249d00.png
[1 _ 10 _ App _ 16]: /images/20230528/b931523604a84ce59be9bccbdce6f6f2.png
[1 _ 10 _ App _ 17]: /images/20230528/10d24995e63149bb8ef0b8ee7190761e.png
[1 _ 10 _ App _ 18]: /images/20230528/4245f732c9534f93bfc50f7013942337.png
[1 _ 10 _ App _ 19]: /images/20230528/b33a48c0076b44fa9c82b6ccb82692d4.png
[1 _ 10 _ App _ 20]: /images/20230528/6422953629c6435785dad77650dcbe61.png
[1 _ 10 _ App _ 21]: /images/20230528/1338d0699b5c425eb051da5677eccaa2.png
[1 _ 10 _ App _ 22]: /images/20230528/80ad550c215642c28cd3fbdfbd181b80.png
[1 _ 10 _ App _ 23]: /images/20230528/1f5cfedf43174dea95c73de9014681d0.png
[1 _ 10 _ App _ 24]: /images/20230528/f9d5a05e93b744219baa2a8efd68fb33.png