软件系统中高性能带来的复杂度主要体现在两方面:
- 一方面是单台计算机内部为了高性能带来的复杂度
- 另一方面是多台计算机集群为了高性能带来的复杂度
单机复杂度
- 计算机内部复杂度最关键的地方就是操作系统,计算机性能的发展本质上是由硬件发展驱动的,尤其是 CPU 的性能发展
- “摩尔定律”表明了 CPU 的处理能力每隔 18 个月就翻一番
- 将硬件性能充分发挥出来的关键就是操作系统,所以操作系统本身其实也是跟随硬件的发展而发展的
- 操作系统是软件系统的运行环境,操作系统的复杂度直接决定了软件系统的复杂度
- 操作系统和性能最相关的就是进程和线程
- 最早的计算机其实是没有操作系统的,只有输入、计算和输出功能,用户输入一个指令,计算机完成操作
- 大部分时候计算机都在等待用户输入指令,这样的处理性能很低效
- 为了解决手工操作带来的低效,批处理操作系统应运而生
- 先把要执行的指令预先写下来(写到纸带、磁带、磁盘等),形成一个指令清单(任务)
- 将任务交给计算机去执行,批处理操作系统负责读取“任务”中的指令清单并进行处理,计算机执行的过程中无须等待人工手工操作,这样性能就有了很大的提升
- 批处理程序有一个很明显的缺点:计算机一次只能执行一个任务
- 如果某个任务需要从 I/O 设备(例如磁带)读取大量的数据,在 I/O 操作的过程中,CPU 其实是空闲的,而这个空闲时间本来是可以进行其他计算的
- 为了进一步提升性能,人们发明了“进程”
- 用进程来对应一个任务,每个任务都有自己独立的内存空间,进程间互不相关,由操作系统来进行调度
- 为了达到多进程并行运行的目的,采取了分时的方式,即把 CPU 的时间分成很多片段,每个片段只能执行某个进程中的指令
- 多进程虽然要求每个任务都有独立的内存空间,进程间互不相关,但从用户的角度来看,两个任务之间能够在运行过程中就进行通信,会让任务设计变得更加灵活高效
- 为此,进程间通信的各种方式被设计出来了,包括管道、消息队列、信号量、共享存储等
- 多进程让多任务能够并行处理任务,但还有缺点,单个进程内部只能串行处理,而实际上很多进程内部的子任务,也需要并行处理
- 为了解决这个问题,人们又发明了线程
- 线程是进程内部的子任务,但这些子任务都共享同一份进程数据
- 为了保证数据的正确性,又发明了互斥锁机制
- 操作系统调度的最小单位就变成了线程
- 进程变成了操作系统分配资源的最小单位
- 操作系统发展到现在,如果我们要完成一个高性能的软件系统,需要考虑如多进程、多线程、进程间通信、多线程并发等技术点
- 这些技术并不是最新的就是最好的,也不是非此即彼的选择
- 在做架构设计的时候,需要花费很大的精力来结合业务进行分析、判断、选择、组合,这个过程同样很复杂
集群的复杂度
- 计算机硬件的性能快速发展,但业务的发展速度更快
- 2016 年“双 11”支付宝每秒峰值达 12 万笔支付
- 2017 年春节微信红包收发红包每秒达到 76 万个
- 要支持支付和红包这种复杂的业务,单机的性能是无法支撑的,必须采用机器集群的方式来达到高性能
- 通过大量机器来提升性能,并不仅仅是增加机器这么简单,让多台机器配合起来达到高性能的目的,是一个复杂的任务
- 任务分配
-
任务分配的意思是指每台机器都可以处理完整的业务任务,不同的任务分配到不同的机器上执行
- 从图中可以看到,1 台服务器演变为 2 台服务器后,架构上明显要复杂多了
- 需要增加一个任务分配器,选择合适的任务分配器也是一件复杂的事情,需要综合考虑性能、成本、可维护性、可用性等各方面的因素
- 任务分配器和真正的业务服务器之间有连接和交互,需要选择合适的连接方式,并且对连接进行管理
- 任务分配器需要增加分配算法
-
随着性能的增加,任务分配器本身又会成为性能瓶颈,也需要扩展为多台机器
- 任务分配器从 1 台变成了多台,需要将不同的用户分配到不同的任务分配器上( DNS 轮询、智能 DNS、CDN等)
- 任务分配器和业务服务器的连接从简单的“1 对多”(1 台任务分配器连接多台业务服务器)变成了“多对多”(多台任务分配器连接多台业务服务器)的网状结构
- 机器数量从少数台扩展到更多台,状态管理、故障处理复杂度也大大增加
- 任务分解
- 如果业务本身也越来越复杂,单纯只通过任务分配的方式来扩展性能,收益会越来越低
- 为了能够继续提升性能,我们需要采取第二种方式:任务分解
-
“业务服务器”如果越来越复杂,我们可以将其拆分为更多的组成部分,我以微信的后台架构为例
- 通过这种任务分解的方式,能够把原来大一统但复杂的业务系统,拆分成小而简单但需要多个系统配合的业务系统
- 简单的系统更加容易做到高性能
- 可以针对单个任务进行扩展
- 虽然系统拆分可能在某种程度上能提升业务处理性能,但提升性能也是有限的
- 最终决定业务处理性能的还是业务逻辑本身,业务逻辑本身没有发生大的变化下,理论上的性能是有一个上限的,系统拆分能够让性能逼近这个极限,但无法突破这个极限
- 因此,任务分解带来的性能收益是有一个度的,并不是任务分解越细越好,而对于架构设计来说,如何把握这个粒度就非常关键了
小结
软件系统中高性能带来的复杂度主要体现的两方面,一是单台计算机内部为了高性能带来的复杂度;二是多台计算机集群为了高性能带来的复杂度,本篇文章希望对大家有所帮助