架构学习笔记2

公号：码农充电站pro

主页：https://codeshellme.github.io

这 2 篇文章是我在学习架构的过程中，总结的笔记：

• 第一篇 架构学习笔记1
  • 0，什么是架构师
  • 1，软件架构出现的历史背景
  • 2，架构设计的目的
  • 3，架构设计三原则
  • 4，架构复杂度的六个来源
  • 5，架构设计流程
  • 6，常用的高性能架构模式
• 第二篇 架构学习笔记2
  • 7，常用的高可用架构模式
  • 8，常用的可扩展架构模式
  • 9，架构师如何判断技术演进的方向
  • 10，互联网架构模板

7，常用的高可用架构模式

1，CAP 定理

CAP 定理是埃里克·布鲁尔在 2000 年的 ACM PODC 上提出的一个猜想。2002 年，赛斯·吉尔伯特和南希·林奇发表了布鲁尔猜想的证明，使之成为分布式计算领域公认的一个定理。

布鲁尔在提出 CAP 猜想的时候，并没有详细定义 Consistency、Availability、Partition Tolerance 三个单词的明确定义。

这里参考 Robert Greiner 的文章，其有两篇文章，第二篇比第一篇更精准：

• 第一篇：https://robertgreiner.com/2014/06/cap-theorem-explained/
• 第二篇：https://robertgreiner.com/2014/08/cap-theorem-revisited/

下面都是采用第二篇文章的解析

CAP 定理：在一个分布式系统（指互相连接并共享数据的节点的集合）中，当涉及读写操作时，只能保证一致性（Consistence）、可用性（Availability）、分区容错性（Partition Tolerance）三者中的两个，另外一个必须被牺牲。

其中的关键点有：

• 强调了互相连接并共享数据的分布式系统（分布式系统并不一定会互联和共享数据）
  • 例如 Memcache 的集群，相互之间就没有连接和共享数据，因此 Memcache 集群这类分布式系统就不符合 CAP 理论探讨的对象；
  • 而 MySQL 集群就是互联和进行数据复制的，因此是 CAP 理论探讨的对象。
• 强调了读写操作，CAP 关注的是对数据的读写操作，而不是分布式系统的所有功能。
  • 例如，ZooKeeper 的选举机制就不是 CAP 探讨的对象。

CAP 的含义：

• 一致性（Consistence）：对某个指定的客户端来说，读操作保证能够返回最新的写操作结果
• 可用性（Availability）：非故障的节点在合理的时间内返回合理的响应
• 分区容错性（Partition Tolerance）：当出现网络分区后（集群中的节点之间不能互相通信），系统能够继续提供服务

在分布式网络中，网络本身无法做到完全可靠，所以分区是一个必然的现象，也就是 P 必然存在，因此，有两种选择：

• CP 架构：当发生网络分区时，保证一致性，可用性无法保证。

  • 
  • 注意：完美的 CP 场景是不存在的，因为数据同步毕竟需要时间，
  • 即使是几毫秒的数据复制延迟，那么在这几毫秒时间内，系统是不符合 CP 要求的，
  • 因此 CAP 中的 CP 方案，实际上也是实现了最终一致性。

• AP 架构：当发生网络分区时，保证可用性，一致性则无法保证。

  • 
  • 系统分区期间牺牲一致性，但分区故障恢复后，系统应该达到最终一致性。

2，FMEA 排除高可用架构隐患

FMEA，中文翻译为“故障模式与影响分析”，是一种广泛应用的可用性分析方法，通过对系统范围内潜在的故障模式加以分析，并按照严重程度进行分类，以确定失效对于系统的最终影响。

在架构设计领域，FMEA 的具体分析方法是：

• 给出初始的架构设计图。
• 假设架构中某个部件发生故障。
• 分析此故障对系统功能造成的影响。
• 根据分析结果，判断架构是否需要进行优化。

FMEA 分析就是一个 FMEA 分析表，常见的 FMEA 分析表包含下面部分（11项）：

• 功能点：这里的“功能点”指的是从用户角度来看的，而不是从系统各个模块功能点划分来看的。
• 故障模式：指的是系统会出现什么样的故障，包括故障点和故障形式。
• 故障影响：当发生故障模式中描述的故障时，功能点具体会受到什么影响。
• 严重程度：严重程度指站在业务的角度故障的影响程度，一般分为“致命 / 高 / 中 / 低 / 无”五个档次。
• 故障原因
• 故障概率
• 风险程度：风险程度就是综合严重程度和故障概率来一起判断某个故障的最终等级，风险程度 = 严重程度 × 故障概率。
• 已有措施：针对具体的故障原因，系统现在是否提供了某些措施来应对，包括：检测告警、容错、自恢复等。
• 规避措施：规避措施指为了降低故障发生概率而做的一些事情，可以是技术手段，也可以是管理手段。
• 解决措施：指为了能够解决问题而做的一些事情，一般都是技术手段。
• 后续规划

例如，对如下架构进行架构分析：

下图是 FMEA 分析的结果：

改进后的架构图：

3，高可用存储架构：双机架构

存储高可用方案的本质都是通过将数据复制到多个存储设备，通过数据冗余的方式来实现高可用，其复杂性主要体现在如何应对复制延迟和中断导致的数据不一致问题。

因此，对任何一个高可用存储方案，我们需要思考以下问题：

• 数据如何复制？
• 各个节点的职责是什么？
• 如何应对复制延迟？
• 如何应对复制中断？

常见的高可用存储架构有：

• 主备（双机架构）
• 主从（双机架构）
• 主主（双机架构）
• 集群
• 分区

1，主备复制

主备复制是最常见也是最简单的一种存储高可用方案，几乎所有的存储系统都提供了主备复制的功能，例如 MySQL、Redis、MongoDB 等。

主备方案架构图：

主备架构中的“备机”主要还是起到一个备份作用，并不承担实际的业务读写操作，如果要把备机改为主机，需要人工操作。

主备架构的优缺点：

• 优点：简单
• 缺点：
  • 备机仅仅只为备份，并没有提供读写操作，硬件成本上有浪费。
  • 故障后需要人工干预，无法自动恢复。

内部的后台管理系统使用主备复制架构的情况会比较多，例如学生管理系统、员工管理系统、假期管理系统等

2，主从复制

主机负责读写操作，从机只负责读操作，不负责写操作。

主从方案架构图：

主从架构的优缺点：

• 优点：
  • 主机故障时，读操作相关的业务可以继续运行（写操作不可用）。
  • 从机提供读操作，发挥了硬件的性能。
• 缺点：
  • 客户端需要感知主从关系，并将不同的操作发给不同的机器进行处理，复杂度比主备复制要高。
  • 从机提供读业务，如果主从复制延迟比较大，业务会因为数据不一致出现问题。
  • 故障时需要人工干预。

一般情况下，写少读多的业务使用主从复制的存储架构比较多。例如，论坛、BBS、新闻网站这类业务。

3，双机切换

主备和主从方案存在两个共性的问题：

• 主机故障后，无法进行写操作。
• 如果主机无法恢复，需要人工指定新的主机角色。

双机切换就是为了解决这两个问题而产生的，包括主备切换和主从切换两种方案。这两个方案就是在原有方案的基础上增加“切换”功能，即系统自动决定主机角色，并完成角色切换。

要实现一个完善的切换方案，必须考虑这几个关键的设计点：

• 主备间状态判断，主要包括两方面：
  • 状态传递的渠道：是相互间互相连接，还是第三方仲裁？
  • 状态检测的内容：例如机器是否掉电、进程是否存在、响应是否缓慢等。
• 切换决策，主要包括：
  • 切换时机：什么情况下备机应该升级为主机？
    • 是机器掉电后备机才升级，
    • 还是主机上的进程不存在就升级，
    • 还是主机响应时间超过 2 秒就升级，
    • 还是 3 分钟内主机连续重启 3 次就升级等。
  • 切换策略：原来的主机故障恢复后，要再次切换，确保原来的主机继续做主机，还是原来的主机故障恢复后自动成为新的备机？
  • 自动程度：切换是完全自动的，还是半自动的？
• 数据冲突解决：当原有故障的主机恢复后，新旧主机之间可能存在数据冲突。

切换方案比复制方案不只是多了一个切换功能那么简单，而是复杂度上升了一个量级。

常见的主备切换架构有三种形式：互连式、中介式和模拟式。

互连式

互连式就是指主备机直接建立状态传递的渠道，其架构图如下：

中介式

中介式指的是在主备两者之外引入第三方中介，主备机之间不直接连接，而都去连接中介，并且通过中介来传递状态信息，其架构图如下：

MongoDB 的 Replica Set 采取的就是这种方式，其基本架构如下：

中介式架构的关键在于如何实现中介本身的高可用，开源方案已经有比较成熟的中介式解决方案，例如 ZooKeeper 和 Keepalived。ZooKeeper 本身已经实现了高可用集群架构。

模拟式

4，主主复制

主主复制指的是两台机器都是主机，互相将数据复制给对方，客户端可以任意挑选其中一台机器进行读写操作。

主主复制架构具有如下特点：

• 两台都是主机，不存在切换的概念。
• 客户端无须区分不同角色的主机，随便将读写操作发送给哪台主机都可以。

主主复制架构对数据的设计有严格的要求，一般适合于那些临时性、可丢失、可覆盖的数据场景。例如，用户登录产生的 session 数据（可以重新登录生成）、用户行为的日志数据（可以丢失）、论坛的草稿数据（可以丢失）等。

4，高可用存储架构：集群和分区

1，数据集群

单台机器的存储和处理能力是有极限的，集群是多台机器组合在一起形成一个统一的系统，可存储更多的数据。

根据集群中机器承担的不同角色来划分，集群可以分为两类：

• 数据集中集群
• 数据分散集群

数据集中集群

数据集中集群为 1 主多备或者 1 主多从。数据都只能往主机中写，而读操作可以参考主备、主从架构进行灵活多变。

下图是读写全部到主机的一种架构：

由于集群里面的服务器数量更多，导致复杂度更高一些：

• 主机如何将数据复制给备机
  • 数据集中集群架构中，存在多条复制通道，多条复制通道会增大主机复制的压力，并且可能会导致多个备机之间数据不一致
• 备机如何检测主机状态
  • 在数据集中集群架构中，多台备机都需要对主机状态进行判断，而不同的备机判断的结果可能是不同的
  • 如何处理不同备机对主机状态的不同判断，是一个复杂的问题。
• 主机故障后，如何决定新的主机
  • 在数据集中集群架构中，有多台备机都可以升级为主机，但实际上只能允许一台备机升级为主机，那么究竟选择哪一台备机作为新的主机，备机之间如何协调，这也是一个复杂的问题。
  • 开源的数据集中集群以 ZooKeeper 为典型，ZooKeeper 通过 ZAB 算法来解决上述提到的几个问题，但 ZAB 算法的复杂度是很高的。

数据分散集群

数据分散集群指多个服务器组成一个集群，每台服务器都会负责存储一部分数据；同时，为了提升硬件利用率，每台服务器又会备份一部分数据。

数据分散集群的复杂点在于如何将数据分配到不同的服务器上，需要考虑这些设计点：

• 均衡性：服务器上的数据分区需是均衡的，不能存在某台服务器上的分区数量是另外一台服务器的几倍的情况。
• 容错性：当出现部分服务器故障时，算法需要将原来分配给故障服务器的数据分区分配给其他服务器。
• 可伸缩性：当集群容量不够，扩充新的服务器后，算法能够自动将部分数据分区迁移到新服务器，并保证扩容后所有服务器的均衡性。

数据分散集群中的每台服务器都可以处理读写请求，因此不存在数据集中集群中负责写的主机那样的角色。

但在数据分散集群中，必须有一个角色来负责执行数据分配算法，这个角色可以是独立的一台服务器，也可以是集群自己选举出的一台服务器。

Hadoop 的实现就是独立的服务器（NameNode）负责数据分区的分配。Hadoop 的数据分区管理架构如下：

与 Hadoop 不同的是，Elasticsearch 集群通过选举一台服务器来做数据分区的分配，叫作 master node，其数据分区管理架构是：

数据集中集群与数据分散集群的区别：

• 数据集中集群：
  • 客户端只能将数据写到主机；
  • 适合数据量不大，集群机器数量不多的场景。
  • 例如，ZooKeeper 集群，一般推荐 5 台机器左右，数据量是单台服务器就能够支撑
• 数据分散集群：
  • 客户端可以向任意服务器中读写数据。
  • 适合业务数据量巨大、集群机器数量庞大的业务场景。
  • 例如，Hadoop 集群、HBase 集群，大规模的集群可以达到上百台甚至上千台服务器。

2，数据分区

数据分区指将数据按照一定的规则进行分区，不同分区分布在不同的地理位置上，每个分区存储一部分数据，通过这种方式来规避地理级别的故障所造成的巨大影响。

设计一个良好的数据分区架构，需要考虑以下方面：

• 数据量：数据量的大小直接决定了分区的规则复杂度。
• 分区规则：地理位置有近有远，因此可以得到不同的分区规则，包括洲际分区、国家分区、城市分区。具体采取哪种或者哪几种规则，需要综合考虑业务范围、成本等因素。
• 复制规则

常见的分区复制规则有三种：

• 集中式：

  • 指存在一个总的备份中心，所有的分区都将数据备份到备份中心，其架构如下：
  • 

• 互备式：

  • 指每个分区备份另外一个分区的数据，其架构如下：
  • 

• 独立式：

  • 指每个分区自己有独立的备份中心，其架构如下：
  • 
  • 注意，各个分区的备份并不和原来的分区在一个地方。

5，高可用计算架构

计算高可用的主要设计目标是当出现部分硬件损坏时，计算任务能够继续正常运行，其本质是通过冗余来规避部分故障的风险。

计算高可用架构的设计复杂度主要体现在任务管理方面，即当任务在某台服务器上执行失败后，如何将任务重新分配到新的服务器进行执行。

计算高可用架构设计的关键点有下面两点：

• 哪些服务器可以执行任务
• 任务如何重新执行

常见的计算高可用架构：主备、主从和集群。

主备架构

详细设计：

• 主机执行所有计算任务。例如，读写数据、执行操作等。
• 当主机故障时，任务分配器不会自动将计算任务发送给备机，此时系统处于不可用状态。
• 如果主机能够恢复（人工或自动恢复），任务分配器继续将任务发送给主机。
• 如果主机不能够恢复，则需要人工操作，将备机升为主机，然后让任务分配器将任务发送给新的主机；
• 同时，为了继续保持主备架构，需要人工增加新的机器作为备机。

根据备机状态的不同，主备架构又可以细分为冷备架构和温备架构：

• 冷备架构：备机上的程序包和配置文件都准备好，但备机上的业务系统没有启动。
  • 主机故障后，需要人工手工将备机的业务系统启动，并将任务分配器的任务请求切换发送给备机。
• 温备架构：备机上的业务系统已经启动，只是不对外提供服务。
  • 主机故障后，人工只需要将任务分配器的任务请求切换发送到备机即可。
  • 冷备可以节省一定的能源，但温备能够大大减少手工操作时间，因此一般情况下推荐用温备的方式。

主从架构

从机也是要执行任务的。任务分配器需要将任务进行分类，确定哪些任务可以发送给主机执行，哪些任务可以发送给备机执行，其基本的架构示意图如下：

详细设计：

• 正常情况下，主机执行部分计算任务，备机执行部分计算任务。
• 当主机故障时，任务分配器不会自动将原本发送给主机的任务发送给从机，而是继续发送给主机，不管这些任务执行是否成功。
• 如果主机能够恢复（人工或自动恢复），任务分配器继续按照原有的设计策略分配任务。
• 如果主机不能够恢复，则需要人工操作，将原来的从机升级为主机。
• 增加新的机器作为从机，新的从机准备就绪后，任务分配器继续按照原有的设计策略分配任务。

集群架构

高可用集群方案能够自动完成切换操作，根据节点角色的不同，可以分为两类：

• 对称集群：集群中每个服务器的角色都是一样的，都可以执行所有任务，因此其又叫负载均衡集群。
• 非对称集群：集群中的服务器分为多个不同的角色，不同的角色执行不同的任务，例如最常见的 Master-Slave 角色。

对称集群

详细设计：

• 任务分配器采取某种策略（随机、轮询等），将计算任务分配给集群中的不同服务器。
• 当集群中的某台服务器故障后，任务分配器不再将任务分配给它，而是将任务分配给其他服务器执行。
• 当故障的服务器恢复后，任务分配器重新将任务分配给它执行。

负载均衡集群的设计关键点在于两点：

• 任务分配器需要选取分配策略：轮询或随机。
• 任务分配器需要检测服务器状态：
  • 检测服务器的状态，例如服务器是否宕机、网络是否正常等；
  • 检测任务的执行状态，例如任务是否卡死、是否执行时间过长等。
  • 常用的做法是任务分配器和服务器之间通过心跳来传递信息（包括服务器信息和任务信息），然后根据实际情况来确定状态判断条件。

非对称集群

非对称集群中不同服务器的角色是不同的，承担不同的职责。

详细设计：

• 集群通过某种方式来区分不同服务器的角色
• 任务分配器将不同任务发送给不同服务器
• 当指定类型的服务器故障时，需要重新分配角色

非对称集群的复杂度主要体现在两个方面：

• 任务分配策略更加复杂：需要将任务划分为不同类型并分配给不同角色的集群节点。
• 角色分配策略实现比较复杂：例如，可能需要使用 ZAB、Raft 这类复杂的算法来实现 Leader 的选举。

6，异地多活架构

无论是高可用计算架构，还是高可用存储架构，其本质的设计目的都是为了解决部分服务器故障的场景下，如何保证系统能够继续提供服务。

异地多活的关键在于异地与多活：

• 异地：地理位置上不同的地方
• 多活：不同地理位置上的系统都能够提供业务服务

实现异地多活架构的代价很高，具体表现为：

• 系统复杂度会发生质的变化，需要设计复杂的异地多活方案。
• 成本会上升，毕竟要多在一个或者多个机房搭建独立的一套业务系统。

异地多活的方案：

• 同城异区：指的是将业务部署在同一个城市不同区的多个机房。
• 跨城异地：指的是业务部署在不同城市的多个机房。
• 跨国异地：指的是业务部署在不同国家的多个机房。

跨城异地多活架构设计的 4 大技巧：

• 保证核心业务的异地多活
• 保证核心数据最终一致性
• 采用多种手段同步数据
• 只保证绝大部分用户的异地多活

8，常用的可扩展架构模式

软件的可扩展性让我们可以通过修改和扩展，不断地让软件系统具备更多的功能和特性，满足新的需求或者顺应技术发展的趋势。

可扩展性架构设计的基本思想是，将原本大一统的系统拆分成多个规模小的部分，扩展时只修改其中一部分即可，无须整个系统到处都改，通过这种方式来减少改动范围，降低改动风险。

合理的拆分，能够强制保证即使程序员出错，出错的范围也不会太广，影响也不会太大。

不同的拆分方式，决定了系统的扩展方式。常见的拆分思路有如下三种：

• 面向流程拆分：将整个业务流程拆分为几个阶段，每个阶段作为一部分。
• 面向服务拆分：将系统提供的服务拆分，每个服务作为一部分。
• 面向功能拆分：将系统提供的功能拆分，每个功能作为一部分。

不同的拆分方式，将得到不同的系统架构，典型的可扩展系统架构有：

• 面向流程拆分：分层架构
• 面向服务拆分：SOA、微服务
• 面向功能拆分：微内核架构

当然，这几个系统架构并不是非此即彼的，而是可以在系统架构设计中进行组合使用的。

1，分层架构

分层架构也叫 N 层架构，N 至少是 2 层：

• 2 层架构：例如 C/S 架构、B/S 架构
• 3 层架构：例如 MVC、MVP 架构
• 等

分层架构设计最核心的一点是要保证各层之间的差异足够清晰，边界足够明显。如果两个层的差异不明显，很容易导致分层混乱。

分层架构使得每个层中的组件只会处理本层的逻辑，并且强制将分层依赖限定为两两依赖（不建议绕过分层，时间长了，容易混乱），降低了整体系统复杂度。

2，SOA

SOA 的全称是 Service Oriented Architecture，中文翻译为面向服务的架构。

SOA 更多是在传统企业（例如，制造业、金融业等）落地和推广，在互联网行业并没有大规模地实践和推广。SOA 出现的背景是企业内部的 IT 系统重复建设且效率低下。

典型的 SOA 架构如下：

3，微服务

2014 年，James Lewis 和 Martin Fowler 合写了关于微服务的一篇学术性的文章，详细阐述了微服务。

关于 SOA 和微服务的关系和区别，有下面几个典型的观点：

• 微服务是 SOA 的实现方式

  • 

• 微服务是去掉 ESB 后的 SOA

  • 

• 微服务是一种和 SOA 相似但本质上不同的架构理念（正确观点）

  • 

SOA 和微服务对比如下：

微服务有哪些坑：

• 服务划分过细，服务间关系复杂
• 服务数量太多，团队效率急剧下降
• 调用链太长，性能下降
• 调用链太长，问题定位困难

4，微内核

微内核架构，也被称为插件化架构，是一种面向功能进行拆分的可扩展性架构，通常用于实现基于产品的应用。

微内核的架构本质就是将变化部分封装在插件里面，从而达到快速灵活扩展的目的，而又不影响整体系统的稳定。

微内核架构包含两类组件：

• 核心系统：负责和具体业务功能无关的通用功能，例如模块加载、模块间通信等
• 插件模块：负责实现具体的业务逻辑

架构示意图：

核心系统 Core System 功能比较稳定，不会因为业务功能扩展而不断修改，插件模块可以根据业务功能的需要不断地扩展。

OSGi 架构

OSGi 是一个非盈利的国际组织，旨在建立一个开放的服务规范，为通过网络向设备提供服务建立开放的标准，这个标准就是 OSGi 规范。

OSGi 是一个插件化的标准，它的架构图如下：

说明：

• 模块层（Module 层）：实现插件管理功能，插件被称为 Bundle。
• 生命周期层（Lifecycle 层）：实现插件连接功能，提供了执行时模块管理、模块对底层 OSGi 框架的访问。
• 服务层（Service 层）：实现插件通信的功能。

规则引擎

规则引擎也属于微内核架构的一种具体实现，基本架构如下：

目前最常用的规则引擎是开源的 JBoss Drools，采用 Java 语言编写，基于 Rete 算法。

9，架构师如何判断技术演进的方向

几个典型的派别（都存在一定的问题）：

• 潮流派：对于新技术特别热衷，紧跟技术潮流，当有新的技术出现时，迫切想将新的技术应用到自己的产品中
• 保守派：对于新技术抱有很强的戒备心
• 跟风派：跟着竞争对手的步子走

互联网公司发展的不同阶段：

10，互联网架构模板

互联网的标准技术架构如下图所示：

1，存储层

有以下几种：

• SQL：即关系型数据库，比如 MySQL、PostgreSQL，Oracle。
  • 当业务发展到一定规模后，会将这部分功能独立成中间件（分库分表自动化），例如百度的 DBProxy、淘宝的 TDDL。
  • 中小公司建议使用开源方案，例如 MySQL 官方推荐的 MySQL Router、360 开源的数据库中间件 Atlas。
• NoSQL：非关系型数据库，比如 Redis，Memcache，MongoDB 等。
• 小文件存储：比如图片数据，特点是数据小，量大，访问量大。
  • HBase、Hadoop、Hypertable、FastDFS 等都可以作为小文件存储的底层平台，只需要将这些开源方案再包装一下基本上就可以用了。
  • 典型的小文件存储有：淘宝的 TFS、京东 JFS、Facebook 的 Haystack。
• 大文件存储：比如视频、日志文件等。
  • 流行的开源方案，例如，Hadoop、HBase、Storm、Hive 等。
  • Hadoop 生态圈：
  • 

2，开发层

主要有：

• 开发框架：提升团队的开发效率，例如：
  • Java 的 SSH、SpringMVC、Play
  • Ruby 的 Ruby on Rails
  • PHP 的 ThinkPHP
  • Python 的 Django
  • 等
• Web 服务器：选择一个服务器主要和开发语言相关，例如：
  • Java 的有 Tomcat、JBoss、Resin 等
  • PHP/Python 的用 Nginx
• 容器：以 Docker 为代表

3，服务层

服务层的主要目标是为了降低系统间相互关联的复杂度。

• 配置中心：集中管理各个系统的配置。

• 服务中心：是为了解决跨系统依赖的“配置”和“调度”问题，一般有两种实现方式：

  • 服务名字系统：将 Service 名称解析为“host + port + 接口名称”
  • 服务总线系统：由总线系统完成调用，服务请求方不需要直接和服务提供方交互

• 消息队列：是为了实现跨系统异步通知的中间件系统。

  • 有很多成熟的开源实现方案，例如，RocketMQ、Kafka、ActiveMQ 等。

4，网络层

网络层技术的关键架构设计点：

• 负载均衡：为了应对大容量的访问，将请求均衡地分配到多个系统上。

  • DNS 是最简单也是最常见的负载均衡方式，一般用来实现地理级别的均衡。解析域名的命令：dig baidu.com
  • DNS 负载均衡的优缺点：
    • 优点：通用（全球通用）、成本低（申请域名，注册 DNS 即可）
    • 缺点：DNS 缓存的时间比较长；DNS 不够灵活，不能感知后端服务器的状态
  • Nginx 、LVS 、F5，用于同一地点内机器级别的负载均衡。
  • 很多云服务商都提供了负载均衡的产品，例如阿里云的 SLB、UCloud 的 ULB 等。

• CDN：CDN 是为了解决用户网络访问时的“最后一公里”效应，本质上是一种“以空间换时间”的加速策略，即将内容缓存在离用户最近的地方，用户访问的是缓存的内容，而不是站点实时的内容。

  • CDN 流程图：
  • 
  • CDN 经过多年的发展，已经变成了一个很庞大的体系：分布式存储、全局负载均衡、网络重定向、流量控制等都属于 CDN 的范畴，尤其是在视频、直播等领域，如果没有 CDN，用户是不可能实现流畅观看内容的。
  • 目前有专门的 CDN 服务商，例如网宿和蓝汛；
  • 也有云计算厂家提供 CDN 服务，例如阿里云和腾讯云都提供 CDN 的服务。

• 多机房：多机房是为了解决单机房的单点问题。

• 多中心：多中心必须以多机房为前提，多中心相比多机房是本质上的飞越，难度也高出一个等级。

5，用户层

用户管理

用户管理的第一个目标：单点登录（SSO），又叫统一登录。单点登录的技术实现手段较多，例如 cookie、JSONP、token 等，目前最成熟的开源单点登录方案当属 CAS，其架构如下：

用户管理的第二个目标：授权登录（第三方应用接入）。现在最流行的授权登录就是 OAuth 2.0 协议，基本上已经成为了标准。

用户管理的基本架构如下：

消息推送

消息推送根据不同的途径，分为短信、邮件、站内信、App 推送。

App 目前主要分为 iOS 和 Android 推送，iOS 系统比较规范和封闭，基本上只能使用苹果的 APNS；但 Android 就不一样了，在国外，用 GCM 和 APNS 差别不大；但是在国内，情况就复杂多了：首先是 GCM 不能用；其次是各个手机厂商都有自己的定制的 Android，消息推送实现也不完全一样。

存储云、图片云

存储云和图片云通常的实现都是“CDN + 小文件存储”，现在有了“云”之后，除非 BAT 级别，一般不建议自己再重复造轮子了，直接买云服务可能是最快也是最经济的方式。

普通的文件基本上提供存储和访问就够了，而图片涉及的业务会更多，包括裁剪、压缩、美化、审核、水印等处理，因此通常情况下图片云会拆分为独立的系统对用户提供服务。

6，业务层

面对业务层的技术挑战，最有效的方法就是，化整为零、分而治之，将整体复杂性分散到多个子业务或者子系统里面去。具体的方式就是可扩展架构模式部分的分层架构、微服务、微内核等。

例如下面的系统拆分演变过程：