系统架构

在互联网出现之后，传统软件架构已经完全不能满足快速多变的环境了，传统软件中如银行系统，业务量是可控的，因为所有业务都是在柜台处理，需求不会经常变动，而且还有停机时间，所以不会存在很大的问题。当互联网出现之后，互联网软件就会面临以下的问题：

1. 高并发，大流量

2. 高可用

3. 海量数据

4. 网络不稳定

5. 安全环境恶劣

6. 需求变化快

那我们如何来解决这些问题呢，有两种思路，一种方案是垂直伸缩：通过升级硬件和网络吞吐能力；另一种方案是水平伸缩：通过增加服务器提升服务能力。互联网软件一般会选择第二种方案，一方面是因为资金有限，另一方面是垂直伸缩会有物理极限。当应对高并发挑战时，互联网软件的水平伸缩我们怎么来做呢，一般会遵循下面的演化路径：

1. 单体应用架构，也即所有代码都在一个系统中，也部署在一台服务器上

2. 应用数据分离，将应用、数据库、文件服务分开部署

3. 使用缓存改善系统性能

4. 使用应用服务器集群改善系统的并发处理能力

5. 数据库读写分离，分担数据库主库的读压力

6. 使用反向代理和CDN加速网站响应

7. 使用分布式文件系统和分布式数据库系统

8. 使用NoSQL和搜索引擎

9. 业务拆分

10. 微服务及中台化

11. 大数据与智能化

在架构演化的过程当中，我们会碰到很多问题，而这些问题已经是周围重复发生的，所以互联网人总结了一套架构模式来解决这些重复的问题，如：

1. 分层：将系统在横向维度上切分成几个部分，每个部分单一职责，上层依赖下层

2. 分割：将系统在纵向上切分，也就是把系统按业务进行拆分

3. 分布式：切分后可以独立部署，所有的模块能够协同工作

4. 集群：每一个切分的模块可以部署多台服务器提升服务能力

5. 缓存：提升性能

6. 异步：降低耦合性，异步处理

7. 冗余：备份，保证不出现单点，和集群的目的也比较类似

8. 自动化：在无人值守的情况下网站可以正常运行

9. 安全：防攻击、数据脱敏等等

这些架构模式也就是为了帮助我们去架构一个高性能、高可用、可伸缩、可扩展、安全的系统。

以上说了这么多，目的都是为了解决业务问题，这也是本次课带给我最大的感受。老师有几句话，这里也分享出来：

1. 架构乱，说明业务没有拆分好，首先要做的就是去分析业务

2. 复杂的业务都是没有想清楚，想清楚的业务都很简单

老师分享的维基百科的架构，其实也很简单，本质也是因为业务简单；包括老师分享的宅米的架构演进，也让我明白很多架构其实也不是高大上，也是根据当前的业务来进行演进。所以不要一开始就陷入了要做一个最好架构的泥潭。