架构师训练营 Week 04 总结

系统架构

前几周讲的是软件架构，而系统架构更多的是指互联网系统的架构。

1 互联网系统面临的挑战

1.1 高并发，大流量

即是需要面对高并发用户，大流量访问。如：

• Google日均PV数35亿，日均IP访问数3亿

• 微信在线用户数10亿

• 天猫双十一活动一天交易额3000亿

1.2 高可用

系统7*24小时不间断服务。大型互联网站的宕机事件通常会成为新闻焦点

1.3 海量数据

需要存储、管理海量数据。如：

• Facebook每周上传的照片数目接近10亿

• 百度收录的网页数目数百亿

• Google有近百万台服务器为全球用户提供服务

1.4 用户分布广泛，网络情况复杂

许多大型互联网都是为全球用户提供服务的，用户分布范围广，各地网络情况千差万别。在国内，有各个运营商网络互通难的问题。而中美光缆的数次故障，也让一些对国外用户依赖较大的网站不得不考虑在海外建立数据中心。

1.5 安全环境恶劣

由于互联网的开放性，使得互联网网站更容易受到攻击，大型网站几乎每天都会遇到黑客攻击的情况。2011年国内多个重要网站泄露用户密码，让普通用户也直面一次互联网安全问题。

1.6 需求快速变更，发布频繁

和传统软件的版本发布频率不同，互联网产品为快速适应市场，满足用户需求，其产品发布频率也是极高的。Office的产品版本以年为单位发布，而一般大型网站的产品每周都有新版本发布上线，至于中小型网站的发布就更频繁了，有时候一天会发布十几次。

1.7渐进式发展

不同于传统软件产品或者企业应用系统，一开始就规划好全部的功能和非功能需求，几乎所有的大型互联网站都是从一个小网站开始，渐进地发展起来的。

• Facebook是伯克扎格与同学在哈佛大学的宿舍里开发的

• Google的第一台服务器部署在斯坦福大学的实验室里

• 阿里巴巴则是马云家的客厅里诞生的

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

2.1 垂直伸缩

通过升级硬件和网络吞吐能力可以实现垂直伸缩。由于不需要改变应用架构，所以通常被认为是最简单的短期伸缩性方案。

• 通过使用RAID（独立冗余磁盘阵列）增加I/O吞吐能力

• 通过切换到SSD（固态硬盘）改善I/O访问速度

• 通过增加内存减少I/O操作

• 通过升级网络接口或者增加网络接口提高网络吞吐能力

• 更新服务器使用更多处理器或者更多超线程

2.1.1 垂直伸缩的缺点

• 达到某个程度后，增加计算能力需要更多的花费

• 垂直伸缩有物理极限

• 操作系统的设计或者应用程序自身制约着垂直伸缩最多只能达到某个点

2.2 水平伸缩

是指通过增加服务器来提升计算能力的一类架构方法

2.2.1 水平伸缩与垂直伸缩的比较

在规模不大时，使用垂直伸缩更为适合。因为维护成本和开发成本更低。

3 互联网架构的演化

3.1 简单互联网应用架构

应用程序+数据库部署在一台服务器中

3.2 应用数据分离

将应用程序、文件系统、数据库分别部署在各自的服务器中

3.3 使用缓存改善系统性能

使用缓存来降低对数据库的访问频率

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

部署多个应用服务器，来应对并发的用户请求

3.5 数据库读写分离

数据库使用主/从复制的部署方式，一台主数据库服务器承担写操作，多台从服务器承担读操作

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

反向代理部署在网站的中心机房，当用户请求到达中心机房后，首先访问的服务器反向代理服务器，如果反向代理服务器中缓存着用户请求的资源，就将其直接返回给用户。

CDN部署在网络提供商的机房，使用户在请求网站服务时，可以从距离自己最近的网络提供商机房获取数据。

需要使用这些功能时，只需要向网络服务商购买即可。

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

把数据库的数据表进行切片处理，分别存储在不同的数据库服务器中。例如，微信的用户表有10亿条数据，我们可以将其进行切片，部署在100台服务器上，这样每台服务器只需处理1千万条数据。

3.8 使用NoSQL和搜索引擎

3.9 业务拆分

例如，淘宝可拆成买家、卖家、首页、购物车、搜索等业务，也就是分别封装成各个子系统。但对用户来说就是同一个系统。

3.10 微服务及中台化

例如系统中的用户功能，把其从代码的模块依赖转化成微服务，从本地调用变成远程调用。

3.10 大数据与智能化

4 互联网架构模式

抽取重复发生问题的解决方案

4.1 分层

把上下层

4.2 分割

把平层进行切分，如，淘宝把不同的页面分割开不同的业务，让不同的团队去开发维护

4.3 分布式

通过分层、分割后，如4层，7个业务，28个模块。这样就可以部署在28个服务器，同层次的服务可以使用RPC、http、消息队列等方式调用，而上下层的服务可用通过微服务的调用、数据库调用、缓存器接口调用

4.4 集群

分布式部署各个独立模块后，在用户访问集中的模块，如网页的首页，还需要将独立部署的服务器集群化，即多台服务器相同应用构成一个集群，通过负载均衡设备共同对外提供服务。

4.5 缓存

• CDN

• 反向代理

• 本地缓存

• 远程缓存

4.6 异步

http是同步的，这样会阻塞，也会影响调用者，降低了其处理能力。

改用异步，那么就减少了彼此影响，同时降低耦合性：

• 提高系统可用性

• 加快网络响应速度

• 消除并发访问高峰

4.7 冗余

保证互联网应用7*24小时连续运行

4.8 自动化

实现无人值守的情况下网站可以正常运行，一切都可以自动化是网站的理想状态。目前互联网的自动化架构设计主要在运维方面。

4.9 安全

5 互联网系统架构核心要素

如何衡量一个系统的架构设计

5.1 高性能

5.2 高可用

系统高可用架构设计的前提是必要会出现服务器宕机，当服务器宕机的时候，服务后者应用依然可用

5.3 可伸缩

大型互联网应用通过集群的方式将多台服务器组成一个整体共同提供服务。是否容易向集群中添加新的服务器，是衡量架构伸缩性的主要标准。

5.4 可扩展

添加新业务时，是否可以实现不需要人户改动或者很少改动既有业务功能。可扩展架构的主要手段是实践驱动架构和分布式服务。

5.5 安全

6 互联网架构技术

6.1 前端架构

• App及Web开发技术

• 浏览器及HTTP优化技术

• CDN（由网络供应商提供的，缓存服务，用于缓存图像等资源）

• 动静分离（是指数据库的动态数据、和静态数据，即是修改频率不同）

• 图片服务（存储图片的服务器）

• 反向代理（在应用服务器前假设的一类缓存服务器）

• DNS（访问就近数据中心）

6.2 网关及应用层架构

• 网关架构

• 负载均衡

• 动态页面静态化

• 业务拆分（如，购物商场按首页、买家、卖家分成不同的、平层的业务）

6.3 服务层架构

• 微服务框架

• 分布式消息队列

• 分布式缓存

• 分布式一致性（锁）服务

6.4 存储层架构

• 分布式文件

• 分布式关系数据库

• NoSQL数据库

6.5 后台架构

• 大数据平台

• 搜索引擎

• 推荐引擎

• 数据仓库

6.6 运维与安全

• 数据采集与展示

• 数据监控与报警

• 攻击与防护

• 数据加密与解密