转载

系统架构系列 (六):技术架构要解决什么问题?

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

系统架构系列 (六):技术架构要解决什么问题?

一、什么是技术架构

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

  • 解决业务上的技术问题 : 业务除了基本的功能之外,在运行环境中,它也是一种系统,系统还有一种重要的特征就是 涌现 ,什么意思呢?本来平时不是问题的问题现在变成问题了,举一个简单的例子,简单的登录功能,根据用户名和密码在后台进行验证,验证成功就跳转到首页,失败跳到错误页。这个功能太简单不过了,放在普通的业务场景下,这样肯定没有问题,但用在淘宝登录上,你看看,还是之前的操作吗?到这里大家可能就明白了,技术架构一定是解决目前业务上的技术问题,一般而言,技术架构要解决的问题有: 高并发、高可用、高性能、高扩展…

  • 技术方案 :针对上面的技术问题,再设计技术方案,这里的方案应该是系统性的方案,绝对不是用一个或者几个中间件就能解决的问题。所以在设计方案时,要找到问题的本质,拿高并发来讲,笔者认为它是 有限的资源应对大量的请求 ,矛盾很明显了,就是有限的资源和大量的请求,如果去解决这个问题呢?从矛盾出发,分别在资源和请求处理上做文章,这样从前端、网络、后端可以设计出一套系统化的方案出来。

  • 技术组件 :技术方案中会涉及到使用哪些技术组件,如分布式缓存、消息队列、分布式定时任务、网络通信等,这些都是一个个技术组件,技术方案会根据需要选择一个或多个技术组件来完成目标。单纯的技术组件本身是没有技术价值的,它应该是放在相应的业务场景下才会体现出价值来的。

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

系统架构系列 (六):技术架构要解决什么问题?

二、高并发技术架构

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

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 高并发技术架构图

系统架构系列 (六):技术架构要解决什么问题?

三、总结

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

作者简介:

高福来,先后在 Oracle、阿里工作,目前在滴滴小桔车服加油团队负责营销基础 (优惠券、奖励金),在分布式中间件和系统架构方面积累了一定的经验,擅长用通俗易懂的语言描述复杂问题。

原文  https://www.infoq.cn/article/iNbgrQm2liV1EdZeIFyD
正文到此结束
Loading...