技术架构之高并发系统设计方法论

最新推荐文章于 2024-09-13 20:23:01 发布

zhifeng687

最新推荐文章于 2024-09-13 20:23:01 发布

阅读量4.7k

点赞数

分类专栏：系统设计

原文链接：https://www.infoq.cn/article/iNbgrQm2liV1EdZeIFyD?utm_source=related_read_bottom&utm_medium=article

版权

系统设计专栏收录该内容

33 篇文章 13 订阅

订阅专栏

技术架构在业内并没有形成约定的统一认识，不同人的理解也不一样，有的人认为引入了中间件就是技术架构。笔者并不这么认为，如果是这样的话，只是将中间件堆在一起就是技术架构，那技术架构就是千篇一律了。在相似的业务场景下，技术架构相似是可能的，但绝对不是一种技术架构能包含所有的架构。这篇文章主要是探讨什么是技术架构、技术架构要解决什么问题、最后以高并发场景为例画出技术架构图。

一、什么是技术架构

技术架构是系统架构设计的一种，换言之，它是系统架构的一个实例，那它应该是具备系统架构的普遍特征，在第一篇文章中已经提到，系统架构 = 解决特定问题 + 要素 + 连接，结合这个公式，给技术架构下一个定义：技术架构 = 解决业务上的技术问题 + 技术方案 + 技术组件 ，下面再细化一下：

解决业务上的技术问题: 业务除了基本的功能之外，在运行环境中，它也是一种系统，系统还有一种重要的特征就是涌现，什么意思呢？本来平时不是问题的问题现在变成问题了，举一个简单的例子，简单的登录功能，根据用户名和密码在后台进行验证，验证成功就跳转到首页，失败跳到错误页。这个功能太简单不过了，放在普通的业务场景下，这样肯定没有问题，但用在淘宝登录上，你看看，还是之前的操作吗？到这里大家可能就明白了，技术架构一定是解决目前业务上的技术问题，一般而言，技术架构要解决的问题有：高并发、高可用、高性能、高扩展…。
技术方案：针对上面的技术问题，再设计技术方案，这里的方案应该是系统性的方案，绝对不是用一个或者几个中间件就能解决的问题。所以在设计方案时，要找到问题的本质，拿高并发来讲，笔者认为它是有限的资源应对大量的请求，矛盾很明显了，就是有限的资源和大量的请求，如果去解决这个问题呢？从矛盾出发，分别在资源和请求处理上做文章，这样从前端、网络、后端可以设计出一套系统化的方案出来。
技术组件：技术方案中会涉及到使用哪些技术组件，如分布式缓存、消息队列、分布式定时任务、网络通信等，这些都是一个个技术组件，技术方案会根据需要选择一个或多个技术组件来完成目标。单纯的技术组件本身是没有技术价值的，它应该是放在相应的业务场景下才会体现出价值来的。

用下面一张图来概括它们三者之间的关系，可以看出技术方案才是灵魂作用，技术组件是基础能力，中间件是基础能力，但它并不是技术架构的全部，技术架构的灵魂是技术方案。

二、高并发技术架构

高并发对于大家来讲并不陌生，甚至在校大学生也能讲出一些高并发，缓存、消息队列…这些被提到，并不是谁对谁错，像缓存、消息队列这些是具体的解决高并发的手段之一，在本篇文章之中，希望通过技术架构的思维来解决实际场景问题。

2.1 高并发的本质问题

笔者一直强调问题的本质，因为这样才能真正认识问题，从而解决问题，如果连问题都抓不住，又怎么能解决问题呢。高并发的本质问题笔者认为是有限的资源应对大量的请求(笔者在带新人时会提到一个观点，工作三年左右，要能提出 10 句最能代表自己技术水平的话，非常精炼的揭示技术问题本质)。所以它的以矛盾就很明显了：如何用有限的资源去应对大量的请求，解决的方法也就是解决这个矛盾。

2.2 系统性思考解决矛盾

根据我们的思维，我们可以大致从以下几个角度来思考：

资源能力强弱：之前资源处理能力弱，能不能变强呢？
资源少的问题：能不能增加资源呢？
请求多的问题：能不能减少请求呢？
处理速度：如果能处理得更快，处理的请求就会更多。

注意上面有一个词资源，这里的资源包含两个方面的含义：一是表示硬件资源，如机器节点数、内存大小等；二是业务资源，如秒杀场景下的商品数量。所以资源少的问题并不能简单地增加资源就能解决，秒杀就是那么少的商品数量。

2.3 高并发的应对方法

假设我们的场景就是大用户量访问 (不是秒杀场景，秒杀场景有它的处理方法)，应对的方法还是从上面接着往下分析。

2.3.1 资源能力强弱

有一种最简单的方法就是提升资源能力，就是提升机器的性能，也就是提升硬件配置，这个是最简单的方法，但它有一定的成本的。比如笔者之前就经验过这样的场景，Mysql 数据存储在机械硬盘上和存储在固态硬盘上，它们的处理速度是有很大的区分的，在不优化任何代码的情况下，它的性能能提供一倍。当然这里必须指明的是业务上存在的大量的 IO 读写，所以换成固态硬盘能起到立竿见影的效果。

上面也说了，提升硬件是要花一定的成本的，所以作为管理者来讲，能不改配置的就不要改配置，但它的确会有明显的性能提升。

2.3.2 资源少的问题

上面开始就已经提到，这里的场景不是秒杀场景，所以我们可以通过增加机器节点来应对，假如有 1w 个请求，一台机器处理 100 个请求，100 台机器搞定，如果只有 10 台机器，那一台机器就要处理 1000 个请求，这种方法叫机器水平扩展。

当然要做到能够水平扩展，必须是无状态的。无状态简单理解就是请求之间没有记忆功能，但有时一个请求又涉及到多个涉及到多个操作，如下单、库存、支付等，用户信息肯定要携带，如何做到无状态呢？常见有几种做法：

stick 粘滞：对同一个用户请求转发到同一台机器上
集中式存储：如 session 共享就集中存储在一个集群上，每台机器去集群上 get 信息就行
token：相比集中式存储，token 就显得比较轻巧，它是不需要额外的存储，利用的是加密、解密的思想，在请求中就携带了相关信息，所以就不需要再去查了。

2.3.3 请求多的问题

既然请求过多，怎么做到请求少呢？注意并不是不让请求。一般有几个思路处理：一是错峰处理，避免集中请求，这里就可以分流，压力自然就减少了；二是排队，整体集群的能力是一定的，所有的请求先入队列，集群从队列中取请求就行；三是限流，这是稳定性常用的手段，具体在高可用中会讲解。

2.3.4 处理速度

“天下武功，唯快不破”，处理快很关键。所以现在我们在快上做文章。一般的请求轨迹：前端访问 -> 前置逻辑判断 -> 业务处理 -> 数据存储 -> 结果响应返回。

这里有几个点：网络开销、CPU 处理、IO，把这几个耗时关键点降下来，整体效果就比较明显。

网络开销：能不能没有网络开销呢？有的，完全可以静态化放在 CDN 上，双 11 晚会承接页就是放在 CDN 上，只有实际变化的数据才会请求后端，其它的数据都是静态化的，处理速度非常快，当时的 QPS 达到 10W。有的不能完全没有网络开销，可以合并请求减少请求访问，能一次访问获取到结果的，不要再发一次请求，可以不发请求的就一定不要发请求。虽然每次请求就 10 几 ms，在量大的情况下，这就是压死骆驼的一根稻草。
前置判断逻辑：这个过程一般是查询，每次查询不管是访问 db 或者是文件，都会有 IO 消耗，如何避免呢？存在缓存中可以提高访问速度，访问速度快慢顺序：本地内存 > 远程缓存 > db，但要注意一点，如果使用到了缓存，一定要考虑缓存数据的一致性，一致性问题包括多级缓存和缓存和数据库中的一致性。
CPU 处理：在业务处理过程中，包括了很多步骤，如果操作步骤没有依赖关系的，完全可以并行处理，最后通过 java 中的 Future 获取各个步骤的结果；还有一种是操作过程中并不是实时要处理的，如发通知等，完全可以异步执行，这样也能节省时间。
IO 处理：IO 速度相对内存而言是慢的，IO 有两种情况，一是读，另一种是写，如果是读，自然想到通过缓存来提速，也可以把请求打散到不同的机器，如 Mysql 的主从模式，可以从不同的从服务器上读数据；写数据的时候可以延迟写，在高并发的场景下，不要直接与 IO 打交道，可以放要处理的数据放在消息队列中再慢慢处理落地到数据库中。

通过上面的分析可以看出，我们在应对高并发是可以从多个不同的角度来考虑，只要思路打开了就会形成系统性的解决方案。

2.4 高并发的应对方法总结

下面通过思维脑图的方式整理归纳应对高并发的解决方法。

2.5 高并发技术架构图

三、总结

本篇文章主要探讨了什么是技术架构，给出技术架构的公式：技术架构 = 解决业务上的技术问题 + 技术方案 + 技术组件，以及这三者的关系。要以看出技术组件是基础，技术方案是灵魂，用不同的技术组件给合解决实现问题。相似的场景是有相似的技术架构，关键是技术架构要解决的问题是什么，抓住了问题的本质，再从矛盾出发，系统化的提出解决方案。