互连网系统架构

挑战

- 高并发、大流量

- 7x24 高可用

- 海量数据

- 用户分布广泛、网路情况复杂

- 安全

- 需求快速变更、发布更频繁

- 需持时间渐进式发展

应对高并发的两个技术方向

- 垂直伸缩

最简单的伸缩方案。通过升级硬件和网络吞吐能力实现。但垂直伸缩到达某个点后，会需要更多花费。

- 水平伸缩

通过增加服务器数量来提升计算能力。垂直伸缩后期花费的飙升便需要水平伸缩来应对

高性能

单机

让多个 CPU 同时执行计算任务，从而实现真正意义上的多任务并行。

解决方案有 3 种：

- SMP（Symmetric Multi-Processor，对称多处理器结构）

- NUMA（Non-Uniform Memory Access，非一致存储访问结构）

- MPP（Massive Parallel Processing，海量并行处理结构）

其中 SMP 是我们最常见的，目前流行的多核处理器就是 SMP 方案。

Nginx 可以用多进程也可以用多线程，JBoss 采用的是多线程；Redis 采用的是单进程，Memcache 采用的是多线程，这些系统都实现了高性能，但内部实现差异却很大。

集群

通过任务分配、任务分解就能够提升性能

- 简单的系统更加容易做到高性能

- 可以针对单个任务进行扩展

高可用

高性能增加机器目的在于“扩展”处理性能；高可用增加机器目的在于“冗余”处理单元。

关键在于无中断，本质上都是通过冗余来实现高可用。

有计算高可用、存储高可用。基础都是状态决策，即能够判断当前的状态是正常还是异常。

- 独裁式 

- 协商式

- 民主式

• 计算高可用: 特点是无论在哪台机器上进行计算，同样的算法和输入数据，产出的结果都是一样的。需要增加一个任务分配器及分配算法。例如，常见的双机算法有主备、主主，主备方案又可以细分为冷备、温备、热备。

• 存储高可用: 将数据从一台机器搬到到另一台机器，需要经过线路进行传输。存储高可用的难点不在于如何备份数据，而在于如何减少或者规避数据不一致对业务造成的影响。

分布式领域里面有一个著名的 CAP 定理，从理论上论证了存储高可用的复杂度。也就是说，存储高可用不可能同时满足“一致性、可用性、分区容错性”，最多满足其中两个，这就要求我们在做架构设计时结合业务进行取舍。

可伸缩

可扩展

有两个基本条件：正确预测变化、完美封装变化。

预测变化

预测变化的复杂性在于：

- 不能每个设计点都考虑可扩展性。

- 不能完全不考虑可扩展性。

- 所有的预测都存在出错的可能性。

刻意练习于把握预测的程度和提升预测结果的准确性

应对变化

方法一: 将“变化”封装在一个“变化层”，将不变的部分封装在一个独立的“稳定层”。

将“变化”封装在一个“变化层”，将不变的部分封装在一个独立的“稳定层”。

- 系统需要拆分出变化层和稳定层

- 需要设计变化层和稳定层之间的接口

方法二: 提炼出一个“抽象层”和一个“实现层”

抽象层是稳定的，实现层可以根据具体业务需要定制开发，当加入新的功能时，只需要增加新的实现，无须修改抽象层。实现举例设计模式的“装饰者”模式

低成本、安全、规模

低成本正好与高性能和高可用相反，需要减少服务器的数量才能达成低成本的目标。我们首先设定一个成本目标，当我们根据高性能、高可用的要求设计出方案时，评估一下方案是否能满足成本目标，如果不行，就需要重新设计架构。往往只有“创新”才能达到低成本目标。

低成本

引入新技术的主要复杂度在于需要去熟悉新技术，并且将新技术与已有技术结合起来；创造新技术的主要复杂度在于需要自己去创造全新的理念和技术，并且新技术跟旧技术相比，需要有质的飞跃。大公司才有足够的资源、技术和时间去创造新技术。

安全

互联网系统的架构安全目前并没有太好的设计手段来实现，更多地是依靠运营商或者云服务商强大的带宽和流量清洗的能力

功能上的安全

常见的 XSS 攻击、CSRF 攻击、SQL 注入、Windows 漏洞、密码破解等，本质上是因为系统实现有漏洞，黑客有了可乘之机。

架构上的安全

传统的架构安全主要依靠防火墙，防火墙最基本的功能就是隔离网络，通过将网络划分成不同的区域，制定出不同区域之间的访问控制策略来控制不同信任程度区域间传送的数据流。

规模

规模带来复杂度的主要原因就是“量变引起质变”

- 功能越来越多，导致系统复杂度指数级上升

- 数据越来越多，系统复杂度发生质变