免费下载!由 O’Reilly 出版的《NGINX 完全指南》中文版已正式上线 了解详情
写点什么

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

  • 2019-09-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-09-11 09:248514

评论 2 条评论

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

hdfs 的集群间拷贝、归档、回收站等功能剖析

大数据技术指南

hdfs 7月日更

搭建 JumpServer 堡垒机管理数万台游戏服务器

学神来啦

云计算 Linux linux运维 运维工程师 运维平台

在数字经济领域实现更充分更高质量就业的思考

CECBC

Flink Runtime架构

布兰特

flink

绍兴柯桥CAD制图培训到兴德教育

Geek_196d9f

云具匠心在宜宾 浪潮云亮相第二届中国国际智能终端产业发展大会

浪潮云

CodeDay 北京站报名倒计时

蚂蚁集团移动开发平台 mPaaS

移动开发

互帮侠系统软件开发公司

新思科技凭借Coverity Scan帮助NGINX确保代码质量和安全

InfoQ_434670063458

新思科技 软件安全 Coverity 静态代码分析

Hologres揭秘:高性能原生加速MaxCompute核心原理

阿里云大数据AI技术

欧洲杯上链,区块链语境下的数字化有什么不一样?

CECBC

TY短视频系统APP开发介绍

【kafka实战】分区重分配可能出现的问题和排查问题思路(生产环境实战,干货!!!非常干!!!建议收藏)

石臻臻的杂货铺

Kafk Kafka实战

5G+工业互联网 智造驱动新发展

唯一网络

智慧海洋三维可视化,科技运维助工业物联网一臂之力

一只数据鲸鱼

数据可视化 3D可视化 智慧工业 海上作业

绍兴服装设计培训到兴德教育!

Geek_196d9f

CryptoPlace挖矿APP系统开发简介

趣口袋拼团系统APP开发案例

网络攻防学习笔记 Day72

穿过生命散发芬芳

网络攻防 7月日更

柯桥淘宝拼多多电商培训到兴德教育!

Geek_196d9f

filecoin靠谱吗?filecoin合不合法?

Filecoin ipfs挖矿 fil挖矿

为什么要学习网络协议?

学无止境的阿奔

c++ Linux TCP/IP 网络通信协议 网络协议栈

区块链与AI、大数据等技术融合,将带来哪些产业变革?

CECBC

万字图文丨最全的Java继承解读

华为云开发者联盟

Java 开发 代码 继承

Redisson 分布式锁源码 09:RedLock 红锁的故事

程序员小航

Java 源码 分布式锁 redisson 红锁

云计算对比IDC的优势简单说明-行云管家

行云管家

云计算 服务器

面试官:你能讲讲栈和队列吗?我:你礼貌吗?

Ayue、

数据结构

柯桥PS培训到兴德教育!零基础开始辅导!

Geek_196d9f

TcaplusDB | 倏忽温风至,因循小暑来

TcaplusDB

nosql tencentdb TcaplusDB database

有人说SQL注入已经落后了,请问可以捶他吗???

网络安全学海

运维 网络安全 信息安全 渗透测试 SQL注入

什么是统一语言?

escray

学习 极客时间 6月日更 7月日更 如何落地业务建模

系统架构系列(六):技术架构要解决什么问题?_语言 & 开发_高福来_InfoQ精选文章