架构师训练营第 4 周——学习总结

之前一直都是将总结或多或少地放进作业中，然而随着知识内容的越来越多，觉得还是很有必要将课程总结单独成文，对以后的学习会更加的方便一些。

本周的学习总结会按照老师的思路，通过自己手敲文字，脑子同步回顾内容的方式进行，主要会涉及到以下几个方面：

1. 互联网系统面临的挑战

2. 高并发挑战下的技术方案

3. 互联网架构的演进

4. 互联网架构模式

5. 衡量一个互联网系统架构的核心要素

6. 互联网技术架构一览

1 互联网系统面临的挑战

• 高并发、大流量

• 高可用互联网系统应能够提供7×24小时连续稳定的服务

• 海量数据的存储与管理

• 用户分布广泛，网络环境复杂

• 互联网安全由于互联网的开放性，使得互联网应用更容易被攻击

• 快速的需求变更，频繁的线上发布与传统软件不同，互联网应用为快速地适应市场环境，满足客户需求，拓展业务市场，就要求互联网应用能够快速地适应业务变化，及时地响应市场方向

• 渐进式的发展不同于传统软件产品或者企业级应用系统，需要在开始时就规划好业务功能与非功能需求，几乎所有的大型互联网应用都是从小功能逐渐发展起来的。好的互联网产品需要逐步慢慢地运营，业务需求也是在逐步的发展中适应市场的需要的。

2 高并发挑战下的技术方案

2.1 垂直伸缩

通过升级硬件和网络吞吐能力，不改变应用及其架构，从而提升应用服务能力。由于不需要改变应用架构，所以通常被认为使一种最简单的短期伸缩性方案。

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

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

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

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

· 更新服务器使用更多的处理器或者更多超线程。

垂直伸缩最大的特点就是简单、快速、短期有效，随着业务的增长，成本的投入与达到的效果呈现指数级增长，更大的问题是垂直伸缩会有天花板，以下是垂直伸缩的缺点：

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

• 垂直伸缩有物理极限；

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

2.2 水平伸缩

水平伸缩是指通过增加服务器提升计算能力的一类架构方法；

水平伸缩可以克服垂直伸缩带来的单位计算成本随计算能力增加而迅速飙升的问题；

水平伸缩总是可以增加更多的服务器，这样就不会受到单台服务器的极限限制；

水平伸缩被认为是伸缩性的圣杯，理论上可以无限地伸缩。

水平伸缩不像垂直伸缩那样会遇到瓶颈上限，但也并不是说水平伸缩就一定比垂直伸缩的方案好，这要依据实际的业务场景决定：

• 在业务拓展的初期，可以快速地构建系统占领市场；

• 在业务快速发展阶段，可以通过垂直伸缩巩固已占领的市场份额；

• 当垂直伸缩遇到瓶颈或者花费的代价过高时，就需要提前考虑水平扩展的方案。



3 互联网架构的演进

3.0 最简单的互联网应用架构

应用程序，文件存储与数据库部署在同一台应用服务器上，这样做的好处是开发简单、部署快、架构简单，但是不好的方面也很明显，服务器宕机会导致所有应用均无法提供服务，启动一次耗费时间长，需要考虑应用的启动顺序等。

其实这个阶段可以称为没有架构阶段，目的也很明确，简单、粗暴。

3.1 应用数据分离

架构演进第一阶段：

不同功能的应用分离，部署在不同的服务器上。

这样做的好处使得服务器功能更加明确，不同应用之间可以做到独立维护。

3.2 使用缓存改善系统性能

架构演进第二阶段：

为了改善系统访问性能，引进了缓存技术，针对热点数据进行缓存，减少与数据库直接操作，从而提升系统服务性能。

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

架构演进第三阶段：

单台应用服务能力毕竟是有上限的，为了能够支撑更多的业务请求，改善系统的并发处理能力，引入了负载均衡调度服务，应用服务集群化部署；

进入到这个阶段后，服务的稳定性有了明显的提升，应用服务可以做到7×24小时的不间断服务，同时引入了新的问题（缓存一致性），针对这种问题也有多种解决方案：

1. 内存复制，例如：weblogic就可以通过配置，使各应用之间缓存通过复制的方式保证其一致性，不过这样做应用服务集群是有上限的问题的，应用多了以后，内存复制带来的消耗也会放大；

2. 负载均衡调度服务保证请求分配始终落在一台应用服务上，这种做法会有缓存失效的问题，如果一台应用服务停止后，落在这台应用上的请求就会失效；

3.4 数据库读写分离

架构演进第四阶段：

互联网大部分应用服务是读多写少的情况，该阶段引入了数据访问模块，将数据库的读写操作映射到不同的数据库服务之上，而数据库通过主从复制保证数据的一致性。

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

架构演进第五阶段：

在前面几个阶段，引入了集群、缓存、读写分离等技术可以极大地提高系统的服务响应能力，而针对静态资源文件的访问（例如：html,css,js,图片等）会占用大量的服务器I/O吞吐，所以在此引入了针对静态资源的访问处理（这里相当于静态资源缓存）：

1. 使用反向代理，将静态资源服务通过反向代理直接返回，在这里还可以开启压缩功能，降低文件传输大小，降低网络消耗；动态业务请求反向代理到应用服务集群的负载均衡上，这样就可以减少应用服务器的I/O吞吐，从而可以提升网站的响应速度；

2. 使用CDN加速，静态资源文件不再请求到应用服务上，而是直接通过CDN服务返回，并且CDN可以开启DNS地理位置定位功能，根据不同的网络访问，将请求分发到最近的网络服务之上，降低网络间的跳转次数，从而也可以提高静态资源的访问效率；

使用缓存，就会遇到缓存失效的问题，缓存在什么情况下失效，需要考虑好规则，否则更新的时候就会比较痛苦。

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

架构演进第六阶段：

随着业务的增长，业务文件的增多，业务数据的大量增长，业务数据单一存储就会遇到很大的性能瓶颈，这时候引入分布式文件系统和分布式数据库系统，通过统一数据访问模块统一操作，应用系统开发不会产生使用上的变化。

这里使用到的技术有：数据分片、分库分表等

3.7 使用NoSQL和搜索引擎

架构演进第七阶段：

随着用户量和业务量的提升，业务数据的大幅增长，同时也随着技术的进步，数据查找可以通过数据库去查找，由于数据库查询效率比较低，同时数据库的资源还是比较宝贵的，这时候就可以引入搜索引擎，通过搜索引擎快速查找；对于非事务性数据的大数据量信息的存储可以引进NoSQL数据库存储方案。

3.8 业务拆分

架构演进第八阶段：

业务早期所有业务都放在一起，随着业务的增加，系统就会变得非常庞大，系统协同开发与维护会变得非常的困难，这时候就需要根据业务进行拆分，子业务系统之间通过调用或消息通知协同工作。

3.9 微服务及中台化

架构演进第九阶段：

起初大家对于依赖的jar包根据各自实际的业务需要可能会修改jar包的内容，这样对于同名的jar可能提供的能力就不能满足所有的场景需要，版本也维护的比较混乱。这时候就可以将jar包依赖替换成微服务依赖，通过远程调用的方式来获取自己需要的能力，使用方不用关心微服务的实现。系统结构就会变得更加清晰，管理更加容易，业务也可以快速扩展（基础服务能力具备了）。



3.10 大数据与智能化

架构演进第十阶段：

围绕大数据与智能化构建系统，具体会在老师讲解大数据之后再来补充。

4 互联网架构模式

每一个模式描述了一个在我们周围不断重复发生的问题以及该问题的解决方案的核心。

模式的关键在于模式的可重复性，问题与场景的可重复性带来解决方案的可重复性。

互联网架构模式就是试图去描述那些为解决互联网系统高性能、高可用、易扩展、可伸缩、安全等目标，被很多互联网应用重复使用的一些解决方案，这些解决方案是互联网软件系统的重要组成部分。

4.1 分层

分层是企业应用系统中最常见的一种架构模式，将系统在横向维度上切分成几个部分，每个部分负责一部分相对比较单一的职责，然后通过上层对下层依赖和调用组成一个完整的系统。

4.2 分割

如果说分层是将软件在横向方面进行切分，那么分割就是在纵向方面对软件进行切分。

系统越大，功能越复杂，服务和数据处理的种类也越多，将这些不同的功能和服务分割开来，包装成高内聚低耦合的模块单元，一方面有助于软件的开发与维护；另一方面便于不同模块的分布式部署，提高软件的并发处理能力和功能扩展能力。

4.3 分布式

对于大型网站，分层与分割的一个主要目的是为了切分后的模块可以分布式部署，即将不同模块部署在不同的服务器上，通过远程调用协同工作。

分布式意味着解决同样的问题可以使用更多的计算机，计算机越多，CPU/内存/存储资源也就越多，能够处理的并发访问和数据量就越大。

• 分布式应用和分布式服务

• 分布式静态资源

• 分布式数据和存储

• 分布式计算

4.4 集群

使用分布式虽然已经将分层和分割后的模块独立部署，但是对于用户访问集中的模块，比如网站首页，还需要将独立部署的服务器集群化，即多台服务器部署相同应用构成一个集群，通过负载均衡设备对外提供服务。

4.5 缓存

缓存就是将数据存放在距离计算最近的位置以加快处理速度，缓存是改善软件性能的第一手段，现代CPU越来越快的一个重要因素就是使用了更多的缓存，在复杂的软件设计中，缓存几乎无处不在。大型网站架构设计在很多方面都使用了缓存设计。

• CDN

• 反向代理

• 本地缓存

• 远程缓存

4.6 异步

计算机软件发展的一个重要目标和驱动力是降低软件耦合性。

事物之间越少直接关系，那么就越少被彼此影响，越可以独立发展。

大型网站架构中，系统解耦合的手段除了前面提到的分层、分割、分布等手段，还有一个重要手段是异步，就是将一个业务操作分成多个阶段，每个阶段之间通过共享数据而不是直接调用的方法进行协作。

• 提高系统可用性

• 加快网站响应速度

• 消除并发访问高峰

4.7 冗余

互联网引用需要7×24小时连续运行，但是服务器总有可能会出现故障，特别是服务器规模比较大的时候，服务器宕机是必然事件。

要想保证在服务器宕机的情况下网站依然可以继续服务，数据不会丢失，就需要一定程度的服务器冗余运行，数据冗余备份。

4.8 自动化

在无人值守的情况下网站可以正常运行，一切都可以自动化是网站的理想状态。

目前互联网的自动化架构设计主要集中在运维方面。

4.9 安全

互联网的开放特性使得其从诞生起就面对巨大的安全挑战，网站在安全架构方面也积累了许多模式：

• 通过密码和手机校验码进行身份认证；

• 登录、交易等操作需要对网络通讯协议进行加密；

• 网站服务器上存储的敏感数据如用户信息等也进行加密处理；

• 为了防止机器人程序滥用网络资源供给网站，网站使用验证码进行识别；

• 对于常见的用于攻击网站的XSS攻击，SQL注入，进行编码转换等相应处理；

• 对于垃圾信息、敏感信息进行过滤；

• 对转账交易等重要操作根据交易模式和交易信息进行风险控制。

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 运维与安全

• 数据采集与展示

• 数据监控与报警

• 攻击与防护

• 数据加密与解密

7 维基百科技术架构图