1、技术发展与复杂度
技术发展带来了性能上的提升，不一定带来复杂度的提升.
有些新技术淘汰旧技术，这种情况下我们直接用新技术即可，不用担心系统复杂度会随之提升。
只有那些并不是用来取代旧技术，而是开辟了一个全新领域的技术，才会给软件系统带来复杂度，因为软件系统在设计的时候就需要在这些技术之间进行选择或组合。
软件系统中高性能带来的复杂度主要体现在两方面
- 单台计算机内部为了高性能带来的复杂度；
- 多台计算机集群为了高性能带来的复杂度。
2、单机复杂度
操作系统是软件系统的运行环境，操作系统的复杂度直接决定了软件系统的复杂度。 操作系统和性能最相关的就是进程和线程。
操作系统发展到现在，要完成一个高性能的软件系统，需要考虑如多进程、多线程、进程间通信、多线程并发等技术点，而且这些技术并不是最新的就是最好的，也不是非此即彼的选择。在做架构设计的时候，需要花费很大的精力来结合业务进行分析、判断、选择、组合。
例如 Redis 采用的是单进程，Memcache 采用的是多线程，它们都实现了高性能，但内部实现差异却很大。
3、集群复杂度
进入互联网时代后，业务的发展速度远远超过了硬件的发展速度。支持支付宝、微信的支付和红包这种复杂的业务，单机的性能无论如何是无法支撑的，后台机器的数量是万台级别的。
让多台机器配合起来达到高性能的目的，是一个复杂的任务。
3.1、任务分配
任务分配的意思是指每台机器都可以处理完整的业务任务，多个任务按策略分配到不同的机器上。
- 增加任务分配器：硬件网络设备（例如，F5、交换机等），软件网络设备（例如，LVS），负载均衡软件（例如，Nginx、HAProxy），或者是自己开发的系统。选择合适的任务分配器也是一件复杂的事情，需要综合考虑性能、成本、可维护性、可用性等各方面的因素。
多台任务分配器带来的复杂度就是需要将不同的用户分配到不同的任务分配器上，常见的方法包括 DNS 轮询、智能 DNS、CDN（Content Delivery Network，内容分发网络）、GSLB 设备（Global Server Load Balance，全局负载均衡）等。 - 任务分配器和真正的业务服务器之间有连接和交互，需要选择合适的连接方式，并且对连接进行管理。例如，连接建立、连接检测、连接中断后如何处理等。
机器数量增多时，多台任务分配器连接多台业务服务器，状态管理、故障处理复杂度也大大增加。 - 选择合适的分配算法，轮询、随机、哈希、加权、最小连接等。如果按照服务器的负载进行分配，则业务服务器还要能够上报自己的状态给任务分配器。
“存储”“运算”“缓存”等都可以作为一项任务，因此存储系统、运算系统、缓存系统也都可以按照任务分配的方式来搭建架构。
此外，“任务分配器”也并不一定只能是物理上存在的机器或者一个独立运行的程序，也可以是嵌入在其他程序中的算法，例如 Memcache 的集群架构(一致性哈希算法)。
3.2、任务分解
通过任务分解，把原来大一统但复杂的业务系统，拆分成小而简单但需要多个系统配合的业务系统。
- 简单的系统更加容易做到高性能
系统功能越简单，影响性能的点就越少。复杂的系统首先难以找到关键性能点，其次修改一性能点可能无意间影响到另一性能点。 - 可以针对单个任务进行扩展
当各个逻辑任务分解到独立的子系统后，整个系统的性能瓶颈更加容易发现，而且发现后只需要针对有瓶颈的子系统进行性能优化或者提升，不需要改动整个系统，风险会小很多。
另外系统也不是拆分的越细越好，如果系统拆分得太细，为了完成某个业务，系统间的调用次数会呈指数级别上升，而系统间的调用通道目前都是通过网络传输的方式，性能远比系统内的函数调用要低得多。
最终决定业务处理性能的还是业务逻辑本身，业务逻辑本身没有发生大的变化下，理论上的性能是有一个上限的，系统拆分能够让性能逼近这个极限，但无法突破这个极限。
因此，任务分解带来的性能收益是有一个度的，并不是任务分解越细越好，而对于架构设计来说，如何把握这个粒度就非常关键了。