InfoQ 编辑部出品——2021年度技术盘点与展望 了解详情
写点什么

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

  • 2019 年 9 月 11 日
  • 本文字数:3482 字

    阅读完需:约 11 分钟

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

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



一、什么是技术架构

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


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

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

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


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



二、高并发技术架构

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


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


相关文章:


《系统架构系列(一):如何用公式定义该概念?》


《系统架构系列 (二):应对这一概念的方法》


《系统架构系列 (三):业务架构实战上篇》


《系统架构系列(四):业务架构实战下篇》


《系统架构系列(五):技术架构之高可扩展系统设计与实现》


2019 年 9 月 11 日 09:247297

评论 2 条评论

发布
用户头像
这取决于是否善于总结和思考,凡事是否会多想一点,机械性的完成一个一个任务的话,三年出十句并不容易
2019 年 09 月 16 日 09:33
回复
用户头像
工作三年左右,要能提出 10 句
工作五年左右,要能提出 3 句
工作八年左右,要能提出 1 句
2019 年 09 月 11 日 12:58
回复
没有更多了
发现更多内容

架构师训练营第二期 Week 2 总结

bigxiang

第六周作业 (作业一)

Geek_83908e

极客大学架构师训练营

架构师训练营第六周总结

月殇

极客大学架构师训练营

架构师训练营 week2 学习总结

花果山

极客大学架构师训练营

架构师训练营—第六周作业

Geek_shu1988

WK1作业

Gavin_From_Mars

第二周作业

阿呆

doris临时故障恢复图

happy

week06学习总结

追风

架构师一期

技术选型(1) 课后作业

ABS

第 2 周 框架设计总结

心在那片海

架构师训练营 Week6 - 技术选型 - 分布式数据库,NoSQL,Zookeeper,搜索引擎

极客大学架构师训练营

架构师训练营第六周作业

郎哲158

极客大学架构师训练营

架构师训练营—第五周学习总结

Geek_shu1988

架构师训练营—第六周学习总结

Geek_shu1988

第二周课后练习

jizhi7

极客大学架构师训练营

第六周作业

TheSRE

极客大学架构师训练营

架构师训练营—第五周作业

Geek_shu1988

第六周作业

Geek_ac4080

分布式CAP原理

Jacky.Chen

架构师训练营 第六周学习总结

郎哲158

极客大学架构师训练营

架构师训练营第 2 期 第二周作业 1

月下独酌

架构一期第六周作业

Airs

第六周-CAP原则理解

袭望

架构师训练营第二周作业

张小胖

极客大学架构师训练营

第 2 周 框架设计作业

心在那片海

架构师训练营第六周课程笔记及心得

Airs

架构师训练营第 1 期 -Week6 - 技术选型二学习总结

鲁小鲁

极客大学架构师训练营

架构师训练营 - 第 6周课后作业-CAP原理

树森

第六周总结

Geek_ac4080

架构师训练营第 1 期 -Week6 - 课后练习

鲁小鲁

极客大学架构师训练营

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