Apache、Nginx：
常见的服务架构
Apache是一个比较流行的Web服务器，它有着很多有点：稳定、开源、跨平台等等。但是由于它出现的时间太长了。它兴起的年代，互联网产业远比不上现在。所以它被设计为一个重量级的。不支持高并发的服务器。在Apache上运行数以万计的并发访问，会导致服务器消耗大量内存。操作系统对其进行进程或线程间的切换也消耗了大量的CPU资源，导致HTTP请求的平均响应速度降低。
于是，轻量级的nginx应运而生。nginx的反向代理可以实现负载均衡。
Nginx是一款自由的、开源的、高性能的HTTP服务器和反向代理服务器；同时也是一个IMAP、POP3、SMTP代理服务器；Nginx可以作为一个HTTP服务器进行网站的发布处理，另外nginx可以作为反向代理进行负载均衡的实现。
其实在上图中，nginx服务器更应该说是一种任务分配服务器，任务分配服务器可以是硬件的（交换机等），也可以是网络设备，也有可能是网络均衡的设备。一般来说，负载均衡的方法不外乎三种，一种是轮询，一种是按权重分配，一种是按照负载进行分配。
正向代理与反向代理：
正向代理就是说很多客户端通过代理访问服务器，服务器只知道该请求来自哪一台代理服务器，而并不知道来自于哪一个客户端，这很大程度上隐匿了客户端的真实信息。
而反向代理，比如说淘宝，每天的访问量很大，这时如果只用一台服务器，肯定会压力很大，于是采用了分布式系统，采用很多台服务器处理请求。这时，代理服务器接到请求的时候，会根据一定的策略把请求转移到应用服务器中（例如天朝某宝的Tengine，就是封装了很多的nginx组件）。这时，请求的来源来自哪一台客户端是明确的，但是由哪台服务器处理的却不是很明确。反向代理，主要用于服务器集群分布式部署的情况下，反向代理隐藏了服务器的信息！
模块与组件：
模块和组件都是系统的组成部分，只是从不同的角度拆分而已，模块是从逻辑角度拆分，而组件是从物理角度拆分。比如拿学生成绩管理系统举例，包括登录模块，学生信息管理模块，成绩模块等，但是从组件上来说，这个系统包括nginx服务器，web服务器，数据库服务器等等。
框架与架构：
单纯从定义的角度来看，框架和架构的区别还是比较明显的，框架关注的是“规范”，架构关注的是“结构”。框架的英文是 Framework，架构的英文是 Architecture。Spring MVC 的英文文档标题就是“Web MVC framework”。
但是，现在很多的说法是混用的，我们可以把所有的概念都说成是架构，只是从不同的角度上分析的架构罢了。
请求处理方式的发展-批处理、多进程、多线程:
最早的时候是没有操作系统的概念的，请求处理是“一对一”的，就是用户发送一个请求，计算机接收一个请求，这个时候会发现，用户发送请求的速度远远小于计算机处理请求的速度，因此造成了时间的浪费。后来逐渐出现了批处理的操作系统，就是用户把自己的请求一次性都写下来，计算机接到请求队列之后逐一进行处理。这种批处理的方式较之前有很大的优势，系统的性能提升很多，但是对于批处理系统有存在很大的缺点，就是I/O的瓶颈。如果其中的某一个指令进行IO操作时耗费了很长时间，那么其它的指令都要进行等待。
后来人们提出了进程的概念，就是把每一个任务变成一个进程，这个进程拥有自己的内存空间，由CPU进行调度。CPU采用分时处理的方式，在每一个时间段，只处理一个进程。对于CPU来说，其实还是串行处理，但是由于CPU的处理时间很快，用户会感觉好像是多进程并行处理。多个进程之间互不相关，独自干着自己的事情。但是，如果进程之间可以互相通信，则可以很大程度上优化任务的设计。进程通信，如果采取一个进程得到的信息先写入到存储里，另一个进程从存储里面读的话，效率会很低。因此人们构造了很多的进程通信方式，信号量、消息队列、管道、共享存储等等。
多进程让任务可以“并行”处理。但是每个进程中的子任务却仍然是顺序执行的。因此就把子进程单独分离出来，产生一个新的概念-线程。一个线程里面的各个进程共享同一个进程空间。操作系统调度的基本单位就变成了线程，而进程只是系统进行资源分配的基本单位。多进程处理就变成了多线程处理。
一个高性能的软件系统，需要考虑如多进程、多线程、进程间通信、多线程并发等特点。线程之间的并发其实本质上还是分时串行处理。实现真正的并发，可以依赖多核CPU。
系统的复杂度与性能？
对于春节期间的发红包以及双十一的购物的系统架构来说，动辄就是每秒上百万的请求次数，单台服务器肯定是不能满足需求的。这些服务的背后，肯定存在一个服务器的集群。在实现的过程中，肯定存在着大量的服务分配以及服务的分解。
然而，提高系统的复杂度真的能够提高系统的性能吗？很显然并不是这样，采用复杂的系统，虽然可以提高系统的并发度，但是对于维护起来也更为复杂，系统处理每一个请求的延时（lantency）也会更高。
在任务逻辑不变的情况下，系统的性能是存在一个极限的，采用任务分配和任务分解的方式可以使得系统逼近这个极限性能。但是，其收益也是有一个限度的。因此在进行任务分解的时候，一定要把握好这个粒度。
QPS、TPS、吞吐量
QPS: 每秒钟处理完请求的次数；注意这里是处理完。具体是指发出请求到服务器处理完成功返回结果。可以理解在server中有个counter，每处理一个请求加1，1秒后counter=QPS。
TPS：每秒钟处理完的事务次数，一般TPS是对整个系统来讲的。一个应用系统1s能完成多少事务处理，一个事务在分布式处理中，可能会对应多个请求，对于衡量单个接口服务的处理能力，用QPS比较多。
并发量：系统能同时处理的请求数
RT：响应时间，处理一次请求所需要的平均处理时间
计算关系：
QPS = 并发量 / 平均响应时间
并发量 = QPS * 平均响应时间
这里的响应时间可以理解为延时。