从零开始学架构——复杂度来源

复杂度来源——高性能

对性能孜孜不倦的追求是整个人类技术不断发展的根本驱动力。例如计算机,从电子管计算机到晶体管计算机再到集成电路计算机,运算性能从每秒几次提升到每秒几亿次。但伴随性能越来越高，相应的方法和系统复杂度也是越来越高。现代的计算机CPU集成了几亿颗晶体管，逻辑复杂度和制造复杂度相比最初的晶体管计算机，根本不可同日而语。
软件系统也存在同样的现象。最近几十年软件系统性能飞速发展，从最初的计算机只能进行简单的科学计算，到现在Google能够支撑每秒几万次的搜索。与此同时，软件系统规模也从单台计算机扩展到上万台计算机；从最初的单用户单工的字符界面Dos操作系统，到现在的多用户多工的Windows 10图形操作系统。
当然，技术发展带来了性能上的提升，不一定带来复杂度的提升。例如，硬件存储从纸带—>磁带—>磁盘—>SSD，并没有显著带来系统复杂度的增加。因为新技术会逐步淘汰旧技术，这种情况下我们直接用新技术即可，不用担心系统复杂度会随之提升。只有哪些并不是用来取代旧技术，而且开辟了一个全新领域的技术，才会给软件系统带来复杂度，因为软件系统在设计的时候就需要在这些技术之间进行判断选择或者组合。就像汽车的发明无法取代火车，飞机的出现也并不能完全取代火车，所以我们在出行的时候，需要考虑选择汽车、火车还是飞机，这个选择的过程就比较复杂了，要考虑价格、时间、速度、舒适度等各种因素。
软件系统中高性能带来的复杂度主要体现在两方面，一方面是单台计算机内部为了高性能带来的复杂度；另一方面是多台计算机集群为了高性能带来的复杂度。

单机复杂度

计算机内部复杂度最关键的地方就是操作系统。计算机性能的发展本质上是悠硬件发展驱动的，尤其是CPU的性能发展。著名的“摩尔定律”表明了CPU的处理能力每隔18个月就能翻一倍；而将硬件性能充分发挥出来的关键就是操作系统，所以操作系统本身其实也是跟随硬件的发展而发展的，操作系统是软件系统的运行环境，操作系统的复杂度直接决定了软件系统的复杂度。
操作系统和性能相关的就是进程和线程。最早的计算机没有操作系统，只有输入、计算和输出功能。这样的处理性能效率很低。
为解决手工操作带来的低效，批处理应运而生，批处理简单来说就是先把要执行的指令预先写下来，形成一个指令清单，然后交给计算机执行，执行过程中无须等待人工手工操作，这样性能就有了很大的提升。
虽然批处理能大大提升处理性能，但有一个很明显的缺点：计算机一次只能执行一个任务，如果某个任务需要从I/O设备（例如磁带）读取大量的数据，在I/O操作的过程中，CPU其实是空闲的，浪费了部分资源。
为进一步提升性能，人们发明了“进程”，用进程来对应一个任务，每个任务都有自己的独立内存空间，进程间互不相关，由操作系统来进行调度。此时的CPU还没有多核和多线程的概念，为了达到多进程并行的目的，采取了分时的方式。同时，进程间通信的各种方式被设计出来，包括管道、消息队列、信号量、共享存储等。多进程让多任务能够并行处理，但本身缺点：单个进程内部只能串行处理，而实际上很多进程内部的子任务并不要求是严格按照时间顺序来执行的，也需要并行处理。
为解决进程的缺点，人们发明了线程，线程是进程内部的子任务，但这些子任务都共享同一份进程数据。为保证数据的正确性，又发明了互斥锁机制。有了多线程后，操作系统调度的最小单位就变成了线程，而进程变成了操作系统分配资源的最小单位。多进程多线程虽让多任务并行处理的性能大大提升，但本质还是分时系统，并不能做到真正意义上的多任务并行。实现真正意义上的多任务并行：目前这样的解决方案有 3 种：SMP（Symmetric Multi-Processor，对称多处理器结构）、NUMA（Non-Uniform Memory Access，非一致存储访问结构）、MPP（Massive Parallel Processing，海量并行处理结构）。目前主流方案是SMP方案。
操作系统发展到现在，如果我们要完成一个高性能的软件系统，需要考虑如多进程、多线程、进程间通信、多线程并发等技术点，而且这些技术并不是最新的就是最好的，也不是非此即彼的选择。在做架构设计的时候，需要花费很大的精力来结合业务进行分析、判断、选择、组合，这个过程同样很复杂。

集群复杂度

虽然，计算机操作系统和硬件的发展已经很快了，但是在进入互联网时代后，业务的发展速度远远更超前了。例如：

2016 年“双 11”支付宝每秒峰值达 12 万笔支付。
2017 年春节微信红包收发红包每秒达到 76 万个
单机的性能无法支撑业务需求的增长，必须采用机器集群的方式来达到高性能。但是，通过大量的机器来提升性能，并不仅仅是增加机器这么简单，下面是针对几种方式的加单分析：

1.任务分配：

任务分配的意思是指，每台机器都可以处理完整的业务任务，不同的任务分配到不同的机器上执行。

例如：从最简单的一台服务器变两台服务器：

此时架构上明显要复杂多了，主要体现在：

需要增加一个任务分配器，这个分配器可能是硬件网络设备（例如，F5、交换机等），可能是软件网络设备（例如，LVS），也可能是负载均衡软件（例如，Nginx、HAProxy），还可能是自己开发的系统。选择合适的任务分配器也是一件复杂的事情，需要综合考虑性能、成本、可维护性、可用性等各方面的因素。
任务分配器和真正的业务服务器之间有连接和交互（即图中任务分配器到业务服务器的连接线），需要选择合适的连接方式，并且对连接进行管理。例如，连接建立、连接检测、连接中断后如何处理等。
任务分配器需要增加分配算法。例如，是采用轮询算法，还是按权重分配，又或者按照负载进行分配。如果按照服务器的负载进行分配，则业务服务器还要能够上报自己的状态给任务分配器。
假设性能要求继续提高，要求每秒提升到10万次：

这个架构比 2 台业务服务器的架构要复杂，主要体现在：

任务分配器从 1 台变成了多台（对应图中的任务分配器 1 到任务分配器 M），这个变化带来的复杂度就是需要将不同的用户分配到不同的任务分配器上（即图中的虚线“用户分配”部分），常见的方法包括 DNS 轮询、智能 DNS、CDN（Content Delivery Network，内容分发网络）、GSLB 设备（Global Server Load Balance，全局负载均衡）等。
任务分配器和业务服务器的连接从简单的“1 对多”（1 台任务分配器连接多台业务服务器）变成了“多对多”（多台任务分配器连接多台业务服务器）的网状结构。
机器数量从 3 台扩展到 30 台（一般任务分配器数量比业务服务器要少，这里我们假设业务服务器为 25 台，任务分配器为 5 台），状态管理、故障处理复杂度也大大增加。
上面这两个例子都是以业务处理为例，实际上“任务”涵盖的范围很广，可以指完整的业务处理，也可以单指某个具体的任务。例如，“存储”“运算”“缓存”等都可以作为一项任务，因此存储系统、运算系统、缓存系统都可以按照任务分配的方式来搭建架构。此外，“任务分配器”也并不一定只能是物理上存在的机器或者者一个独立运行的程序，也可以是嵌入在其他程序中的算法，例如 Memcache 的集群架构。

2.任务分解

通过任务分配的方式，能够突破单台机器处理性能的瓶颈，通过增加更多的机器来满足业务的性能需求，但如果业务本身也越来越复杂，单纯只通过任务分配的方式来扩展性能，收益会越来越低。

为了能够继续提升性能，我们需要采取第二种方式：任务分解。

那为何通过任务分解就能够提升性能呢？
1）简单的系统更加容易做到高性能
系统的功能越简单，影响性能的点就越少，就更加容易进行有针对性的优化。而系统很复杂的情况下，首先是比较难以找到关键性能点，因为需要考虑和验证的点太多；其次是即使花费很大力气找到了，修改起来也不容易。
2）可以针对单个任务进行扩展
当各个逻辑任务分解到独立的子系统后，整个系统的性能瓶颈更加容易发现，而且发现后只需要针对有瓶颈的子系统进行性能优化或者提升，不需要改动整个系统，风险会小很多。

从图中可以看出，当系统拆分2个子系统的时候，用户访问需要1次系统间的请求和1次响应；当系统拆分为4个子系统的时候，系统间的请求次数从1次增长到3次；假如继续拆分下去为100个子系统，为了完成某次用户访问，系统间的请求次数变成了99次。
所以系统拆分可能在某种程度上提升业务处理性能，但提升有限，因为最终决定业务处理性能的还是业务逻辑本身。
因此，任务分解带来的性能收益有一个度，如何把握好这个度非常关键。