版权声明：本文为博主原创文章，未经博主允许不得转载。 https://blog.csdn.net/lwl2014100338/article/details/84451517
高性能带来的复杂度
（1）单机计算机内部为了高性能带来的复杂度
（2）多台计算机集群为了高性能带来的复杂度
单机复杂度
（1）每个进程都有自己独立的内存空间，进程间互不相关，由操作系统调用
（2）进程间通信的方式包括管道、消息队列、信号量、共享存储等
（3）线程是操作系统调度是最小单位，进程是操作系统分配资源的最小单位
集群的复杂度
任务分配：每台机器都可以处理完整的业务任务，不同的任务分配到不同的机器上执行。
一台服务器变两台服务器架构示意图如下
架构复杂度体现
- 需要增加一个任务分配器，这个分配器可能是硬件网络设备（例如F5），可能是软件网络设备（例如LVS），也可能是负载均衡软件（例如Nginx）还可能是自己开发的系统，选择合适的任务分配器是一件复杂的事情，需要考虑性能、成本、可维护性、可用性等各方面因素
- 任务分配器和真正的业务服务器之间有连接和交互，需要选择合适的连接方式，并且对连接进行管理。例如连接建立、连接检测、连接中断后如何处理等
- 任务分配器需要增加分配算法。例如，是采用轮询算法，还是按权重分配，或者按照负载进行分配。如果按照服务器的负载进行分配，则业务服务器还要能上报自己的状态给任务分配器
单台任务分配器不够，扩展为多台任务分配器，架构示意图如下
架构复杂度体现
- 这个变化带来的复杂度需要将不同的用户分配到不同的任务分配器上（图中虚线“用户分配”部分），常用的方法包括DNS轮询、智能DNS、CDN（内容分发网络）、GSLB设备（全局负载均衡）等
- 任务分配器和业务服务器的连接从简单的“1 对多”（1 台任务分配器连接多台业务服务器）变成了“多对多”（多台任务分配器连接多台业务服务器）的网状结构。
- 机器数量从 3 台扩展到 30 台（一般任务分配器数量比业务服务器要少，这里我们假设业务服务器为 25 台，任务分配器为 5 台），状态管理、故障处理复杂度也大大增加。
任务分解：通过任务分配的方式，我们能够突破单台机器处理性能的瓶颈，通过增加更多的机器来满足业务的性能需求，但如果业务本身也越来越复杂，单纯只通过任务分配的方式来扩展性能，收益会越来越低，为了能够继续提升性能，我们需要采取第二种方式：任务分解。
微信后台架构为例
微信后台架构从逻辑上将各个子业务进行了拆分，包括：接入、注册登录、消息、LBS、摇一摇、漂流瓶、其他业务（聊天、视频、朋友圈等）。
通过这种任务分解的方式，能够把原来大一统但复杂的业务系统，拆分成小而简单但需要多个系统配合的业务系统。
为何通过任务分解就可以提升性能
- 简单的系统更容易做到高性能
- 可以针对单个任务进行扩展