【分布式技术】分布式理论基础

概述

系统伸缩常见解决方案大致分 2 类：

1. 垂直伸缩方案（传统大型软件系统的技术方案）：受限于单台服务器的处理能力（CPU、内存、网卡、磁盘）；普通服务器、小型机、中型机、大型机（价格越贵、技术越复杂、运维越困难）

2. 水平伸缩方案：使用更多服务器，构成分布式集群。通过各种分布式技术，使这些服务器有效组织起来，对外统一提供服务。

• 优势：分布式系统可以解决集中式不便扩展的弊端，可利用微服务技术、容器技术等，提供了便捷的扩展性、独立的服务治理，提高安全可靠性。（理论上可以实现无限伸缩）

• 不足：增大了系统复杂性，需要考虑分布式事务、分布式锁、分布式 session、数据一致性等带来的问题。

如何实现分布式系统的核心设计目标：高可靠、高可用、可扩展性、可管理...

希望通过整理本系列文章，对这些问题有自己的理解和认识。

架构演进

通常我们认为架构发展历史经历了这样一个过程：单体架构、垂直分层架构、SOA 架构、微服务架构。

单体架构：所有的功能部署在同一个进程中。MVC 架构也属于一种单体架构。一般通过前置负载均衡实现负载分流。

• 优点：架构简单，前期开发成本低，开发周期短，运维比较简单；适合小型项目（物理服务器的资源利用效率足以支撑业务的部署）。

• 问题：随着业务复杂度飙升，功能模块复杂庞大，不易扩展和维护，单体架构严重阻塞了开发部署效率。

垂直分层架构：按业务垂直拆分成若干个单体系统；每个垂直单元包含用户界面、业务逻辑、数据存储等完整的功能。

• 优点：子系统功能简单，开发周期短，可按需伸缩；能应对大型项目。

• 问题：子系统之间耦合性高，功能冗余。

RPC 架构：通过远程调用技术实现不同服务之间的通信。将核心和公共业务抽取出来，作为独立的服务，实现前后台逻辑分离。

• 优点：服务间调用简单方便，提高业务复用和拆分。

• 问题：服务治理能力不健全（服务依赖关系，服务容量配置，服务生命周期管理流程，安全权限，服务访问安全策略）。服务数量变多时，服务生命周期管控和运行态的治理成为瓶颈。

SOA 架构：通过 ESB 方式实现已有的不同系统之间的服务通信。目标是重用 IT 系统已有资产、实现异构系统之间的灵活互通。也是一种 RPC 架构。

• 优点：解决应用服务化问题，提升服务质量的 SOA 服务治理

• 问题：系统与服务的界限模糊，耦合性高；中心化

微服务架构：随着敏捷开发、持续交付、DevOps 理论的发展和实践，以及基于 Docker 等轻量级容器(LXC)部署应用和服务的成熟，微服务架构开始流行。基于 SOA 思想，对服务层进行细粒度的拆分，各微服务职责单一。也是一种 RPC 架构。

• 优点：通过服务的原子化拆分，以及微服务的独立打包、部署和升级，小团队敏捷交付，应用的交付周期缩短，运维成本也大幅度下降。有效缓解 SOA 服务治理面临的挑战。

• 问题：开发复杂性增加，服务治理成本高

有人认为微服务是 SOA 架构的一种变体，是 SOA 的子集；微服务是 SOA 的实现方式；微服务是去掉 ESB 后的 SOA。

微服务是基于 SOA 思想，对服务层进行细粒度的拆分，各微服务职责单一。

微服务是一种和 SOA 相似但本质上不同的架构理念。

• SOA 面向企业内，系统集成，核心解决复用问题。

• 微服务面向最终产品，核心解决扩展问题，实现真正的 DevOps。

ACID 理论

ACID 理论是传统数据库常用的设计理念，追求强一致性模型（事务一致性）；是对事务特性的抽象和总结。

• A-原子性，由事务机制来保证。

• C-一致性，由约束条件和规则来保证，确保数据的完整性和正确性。

• I-隔离性，防止事务同时对同一数据进行修改而产生冲突。

• D-持久性，由数据的存储方式和备份机制、日志技术来保证。

CAP 理论

在一个分布式系统中，CAP 理论能帮助我们分析问题，做出总结归纳，指导我们做设计如何权衡折中。

1. C 一致性（强调数据正确）：客户端每次读操作，不管访问哪个节点，要么读到同一份最新写入的数据，要么读取失败。

2. A 可用性（强调服务可用）：客户端的任何请求，都能得到响应数据，但不保证是最新数据。

3. P 分区容错性（强调集群对分区故障的容错能力）：因为网络等原因，当节点间出现消息丢失或高延迟时，系统仍然继续工作。

一个分布式系统，一致性、可用性、分区容错性，三者不可兼得。网络问题不可避免，P 是必须保证的，C 和 A 只能二选一。

CP 模型：比如 Zookeeper。

AP 模型：比如 Eureka，Nacos（也可以配置支持 CP）。

常见实践：AP 模型 + 最终一致性。

BASE 理论

BASE 理论包括 BA（基本可用）、S（柔性状态，数据副本存在短暂的不一致）、E（最终一致性），强调可用性，是对互联网大规模分布式系统的实践总结。可以看作对 CAP 中一致性和可用性权衡的结果；也是对 CAP 理论中 AP 的延伸。

1. 如何实现基本可用：限流、熔断降级、过载保护、异步处理；通过牺牲部分功能的可用，实现整体的基本可用。

2. 如何实现最终一致性：优先保证可用性和性能优先；读时修复，写时修复，异步修复（常用的方式，通过定时对账检测和修复数据）。

BASE 理论在互联网分布式系统和 NoSQL 中应用广泛。

全局时钟

分布式系统常遇见的异常（NPC）：

• Network Delay（网络延迟）

• Process Pause（进程暂停）

• Clock Drift（时钟漂移）

在分布式系统中，这些问题都涉及全局时钟的概念。

全局时钟的实现方式，包括物理时钟和逻辑时钟（会引入物理时钟作为参考，也叫混合逻辑时钟）两种方式。主要要素：

• 时间源：一个或多个；多时间源，指多个独立提供时间的实例。

• 时钟类型：物理时钟、混合逻辑时钟；任何物理时钟都存在时钟偏移甚至回拨。

• 授时点：一个或多个；多个授时点指集群内有多个时间服务器提供授时服务。

常见应用一般采用逻辑时钟，根据时间源个数，授时点个数，设计不同的授时方案。

物理时钟实现复杂，很难做到足够高的精度和处理时钟误差；逻辑时钟主要通过逻辑控制来保证时钟的单调递增。

下期预告：【分布式技术】分布式协议与算法