架构师训练营第四周课程笔记及心得

学习笔记

互联网系统架构面临的挑战和需要解决的问题:

面临的挑战：

1. 高并发和大流量访问

2. 高可用，7x24小时不间断服务

3. 存储管理海量数据和服务器

4. 用户分布广泛，地域跨度大，需要多数据中心支持

5. 安全环境恶劣

6. 发布频率高，需求变更快速

7. 渐进式发展

高并发的实际问题是什么：

1. 大量用户的同时访问，服务器需要同时处理这些请求

2. 如何处理这些请求

3. 需要多少资源

4. 如何部署这些资源

解决方法：

1. 垂直伸缩：当并发量增加，增强单一服务起的功能，提高单一服务器的处理能力，来解决并发量高的问题

2. 缺点：

3. 垂直伸缩一开始的时候计算能力的需求和资源的增加是线性关系的，但是增加的幅度是有一个物理极限的，当超过这个极限，后期还需要进行垂直伸缩时，就需要投入大量的成本来升级单个服务器的处理能力，成本的付出相比性能的扩展就已经不是线性的增长关系了。

4. 垂直伸缩有自己的物理极限，即使是超级计算机，也不能达到服务全球所有用户的能力，目前互联网应用的上限，一定会超过服务器的上限。操作系统的设计本身存在缺陷，随着操作系统管理的服务器的资源越来越庞大，操作系统设计的复杂性也会越来越大，这导致了在该系统上运行的应用的复杂性也会越来越大，当复杂性到达上限时，也是无法承载更高的无限的应用需求的。

5. 垂直伸缩只在特定的条件下使用，一般不使用水平伸缩的方式来满足高并发的需求

6. 水平伸缩：通过增加服务器数量，来提升计算资源；使用服务器集群，来共同提供对外服务，水平伸缩是目前互联网应用常用的伸缩手段，这种方式正好应对了互联网渐进式发的趋势和路径

分布式架构的演化

1. 架构演化第零阶段：最简单的互联网应用架构，单一服务器应用

2. 架构演化第一阶段：应用数据分离，例：只拆分数据库服务和文件服务

3. 架构演化第二阶段：使用缓存改善系统的性能，将频繁访问的数据，从慢速的数据存储设备，迁移到高速的数据存储设备；缓存也分为两种，本地缓存和远程缓存

4. 架构演化第三阶段：使用应用服务器集群改善系统的并发处理能力

5. 架构演化第四阶段：数据库读写分离；数据库单台的情况下，会导致读写计中，虽然读取可以通过缓存减少部分压力，但是缓存中不存在时，还是会访问数据库，数据库的阻塞会导致整个系统的瓶颈，数据库的读取和写入分离可以有效的提高数据库的处理能力

6. 架构演化第五阶段：使用反向代理和CDN加速网站响应，CDN（内容分发网络）是部署在网络运营商机房里的一个缓存服务器，通过运营商提供的缓存服务，可以让访问者不需要到网站机房获取数据，直接从就近的运营商机房服务器中获取数据，从而加快访问速度；反向代理服务器，是用户请求到达数据中心时第一个访问的服务器，将用户请求分流，并且有一定的缓存作用，可以减少后端服务器的请求压力。

7. 架构演化第六阶段：使用分布式文件系统和分布式数据库，在前面第四阶段，已经将数据库的读写进行了分离，但是这种方式提升数据库的能力有限，数据库的存储能力并没有提升，当单一的数据库服务器无法满足数据存储需求时，就需要使用分布式的数据库，将数据进行分片，存储到分布式的数据库服务器上；同理文件存储服务也可以用相同的方法，使用分布式存储，将文件存储到多台服务器上，使存储能力得到提升（容量和访问速度）

8. 架构演化第七阶段：使用NoSQL和搜索引擎，通过分布式数据库，解决了存储容量和并发的问题，但是随之而来的，数据库和文件系统分布式之后，会导致数据库查找和文件查找的缓慢，至少目前为止多数据库节点查询和多文件系统查询上，查询效率并不是很高，这时，就需要用到NoSQL和搜索引擎服务来提高数据查找效率，进而提高整个系统的并发处理能力

9. 架构演化第八阶段：业务拆分，一个系统刚开始可能功能比较单一，代码比较简单，但是随着系统需求的增加，代码不断迭代，代码量会不断增加，功能会越来越多，这时后这个系统会变得非常庞大，且不说系统需求已经不是和刚开始的时候一样简单，系统中代码之间的依赖，功能之间的依赖也已经变得非常庞大和复杂，在同一个应用系统中需要处理的流程变长，处理的逻辑变复杂会导致系统的处理能力下降，系统的并发性能降低，这时就需要对这个系统的业务功能，业务逻辑等进行拆分。可以拆分成不同的系统，使用的不同的应用模块更高效的处理业务流程中不同阶段的业务逻辑。拆分之后的业务之间，可以通过http请求，异步消息请求，进行交互，系统的耦合度下降的同时，请求的处理效率可以得到有效的提高。

10. 架构演化第九阶段：微服务及中台化，当业务进行拆分之后，各个系统中会出现一些相同的模块，比如登录，用户管理，等模块这些模块在各个系统中进行单独开发的话从开发成本，部署成本，维护成本上都是相当大的，并且重复开发会是的各个系统之前在交互时产生一些认识偏差，又增加的沟通成本，所以，将各个系统之间的一些通用模块拆分出来，单独变成一种微服务，由单独的集群提供服务，这些服务一起对外提供通用服务就构成了中台，各个业务系统进行开发时只需依赖中台提供的服务，按照中台提供的规范开发就可以了。

11. 架构演化的十阶段：大数据与智能化，系统演化至今，用户访问系统看到的内容都是不同的，所谓的个性化推荐，智能推荐等，使得用户看到的内容更加的符合用户的使用习惯，符合用户感兴趣的口味，这些个性化推荐和智能推荐，基础就是大数据，然后使用智能分析大数据，让每个用户看到的东西都是他们想看到的，典型的有今日头条，各个电商平台的产品推荐功能等。

架构模式与要素

架构模式的定义：

为解决系统高性能、高可用、易扩展、可伸缩、安全等目标，被很多互联网应用重复使用的一些解决方案，这些方案就称作模式，模式是一种解决方案。

架构模式的特点：

模式的关键在于可重复性，对于相同的问题与场景，可重复的使用一个解决方案（模式）。

架构模式：

1. 分层架构模式：架构在横向的维度上切分成几个部分，每个部分职责单一，通过上下层之间的依赖和调用组成一个完成的系统。视图层，应用层，服务层，基础设施层，存储层，不同的层次部署在不同的服务器上，实现分布式分层架构·

2. 分割架构模式：架构在纵向的维度上进行切分，也是对于软件的一种切分。系统越大，功能越复杂，服务和数据的种类也越多，从纵向上，根据软件的功能，服务进行分割，可以让把软件分割成更加高内聚，低耦合的模块单元，一方面有助于软件的开发和维护，另一方便于不同的模块分布式部署，以提高网站的并发处理能力，单个服务器的性能，以及架构的可扩展性

3. 分布式架构模式：即分层和分割后，将一个大型的集中的系统，通过分层和分割，变成个多模块协作，多服务器集群部署的形式。

4. 分布式的意义：解决同样的问题可以使用更多的计算机，计算机越多，cpu，内存存储资源也就越多，能狗处理的并发访问和数据量就越大

5. 例：分布式应用和服务，分布式静态资源，分布式数据和存储，分布式计算等

6. 集群架构模式：将相同功能的多台服务器构成一个集群，对外提供相同的服务，区别于分布式，分布式是分割功能，分层资源。集群模式也是分布式的一种。

7. 缓存架构模式：缓存就是将数据放在距离计算单元最近的位置，以加快调用处理速度，缓存是改善软件性能的第一手段，现代cpu越来越快的一个重要因素，就是使用了更多的缓存，在一个复杂的软件设计中缓存随处可见，大型网站架构中也在很多地方使用到了缓存，以提高系统的处理性能

8. 例：CDN，反向代理，本地缓存，远程缓存

9. 异步架构模式：降低软件耦合性，通过异步调用的方式，来降低软件系统间的耦合性，系统解耦的方法除了分层，分割，分布，还有就是异步。异步就是将一个业务操作分成多个阶段，每个阶段通过共享数据，而不是直接调用的方法进行协作。优点：提高可用性，加快网站相应速度，消除并发高峰（削峰填谷）

10. 冗余架构模式：现在的大型互联网应用，动辄几百上千台服务器，这么多服务器的情况下，出现服务器故障是肯定的，在这时，就要需要考虑服务器冗余运行，数据冗余备份，实现即使个别服务器宕机，但是服务不会中断的需求

11. 自动化架构模式：大型互联网应用成百上千的服务器如果单靠人力维护，那么人员成本将会很高，并且人力维护大量服务器必定会出现人为失误，并且对人的负荷也非常高，这时，需要将这些服务器进行统一的自动的管理，用更少的人力资源，管理更多的应用资源。

12. 安全架构模式：由于互联网的开放特性，使得互联网上的应用面对巨大的安全挑战，网站在安全架构方面也积累的很多模式例：手机校验码；网络通讯加密；用户信息加密；网站验证码；编码转换；信息过滤；交易风控等模式。

互联网系统架构核心要素

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

1. 高性能：性能是互联网应用的一个重要指标，除非用户没得选择，否则用户无法忍受一个响应缓慢的应用，任何一个架构设计方案都必须考虑可能会带来的性能问题；优化系统性能的手段也非常多，从用户端到数据库，从代码到机房部署，影响用户请求处理的所有环节都可以成为优化点，性能的衡量指标也有很多中，通过指标来反映系统的性能。

2. 高可用：保证系统的可用性，是一个架构是必须要会的，这是一个硬指标，由于服务器供应商提供的服务器，并不保证服务器本身的可用性，也就是说，服务器宕机是肯定存在的，但是对于一个系统，一个服务，一个软件来说，任何时候，都是需要可以使用的，这就要求了，在服务器本身宕机时，系统，服务，软件需要保持可用性，这时一般通过冗余来实现，通过冗余，来实现软件的备份，服务的备份，系统的备份，数据的备份，这样，除非该系统下所有服务器同时宕机，否则这个系统，服务，和软件在个别服务器宕机的情况下依然是可用的。这是一个硬性指标，所有的互联网应用必须都保证系统，服务，软件的可用性。

3. 可伸缩性：大型互联网应用在应对不断升高的并发量与请求数量的过程中，经常使用应用集群的方式，来解决容量问题，通过更加渐简便的添加或删除集群中应用节点的操作，使得集群可以应对突发的高并发，大数量的请求，并且在闲时，可以让集群减少节点数量，来控制成本。构成系统或者服务的服务器集群，应用集群，是否容易添加服务器，添加应用节点，是衡量伸缩性的一个标准，越是容易添加，缩减服务器，并且添加，缩减后，对外提供的服务，功能保持不变，对外来说变化不可见，可容纳的总服务器数量越高，则伸缩性越是好。例：NoSQL数据库，分布式关系型数据库，虽然支持伸缩，但是步骤操作非常的复杂，所以现在我们还需要探索开发NoSQL数据库

4. 可扩展性：与其他架构关注点，不同，可扩展性关注的是功能性需求，可扩展性关注的是在需求快速变更的情况下，使系统更易于开发，易于添加功能，满足业务的发展要求，并且在满足新需求，功能的同时，保证对现有系统没有影响，保证成本增加最少，保证产品之间没有耦合，通过事件驱动架构和为服务模式实现。

5. 安全性：互联网总是开放的，安全性的安全标准就是保证系统不管变更的同时，保证系统的安全性，数据安全，系统安全等互联网的一些技术方案：前端架构：app及web开发技术浏览器及http优化技术CDN动静分离图片服务反向代理DNS网关及应用层架构：网关架构负载均衡动态页面静态化业务拆分服务层架构：微服务框架分布式消息队列分布式缓存分布式一致性（锁）服务存储层架构：分布式文件系统分布式关系数据库NoSQL数据库后台架构：大数据平台搜索引擎推荐引擎数据仓库运维与安全：数据采集与展示数据监控与报警攻击与防护数据加密与解密

第四、五、六课：案例分析，见课件

CTO团队管理经验：

1. 构建团队自驱动闭环

2. 去完成目标而不是完成工作

3. 加班既不是目的也不是

4. 手段亡羊补牢，没事不要瞎折腾

5. 只有优秀的员工才能创建优秀的企业

6. 为员工共的成长买单先关注人，后关注事

7. 快乐工作