骏骏骏的博客

主题

骏骏骏2025-10-16
2028
7m
Get...

分布式学习 ​

基础概念 ​

分布式系统概述 ​

分布式系统是由多个通过网络相互连接的独立计算机或节点组成的系统。这些节点可以分布在不同的地理位置，并协同工作以完成共同的任务或提供特定的服务。从用户的角度来看，整个系统就像是一台计算机，尽管其资源（如处理能力、存储空间等）是分布于多台机器上的。

特点：

  1. 分布性： 系统由多个节点组成，这些节点可能位于不同的物理位置。
  2. 并发性： 多个节点可以并行地执行任务，从而提高系统的处理能力和性能。
  3. 缺乏全局时钟： 节点通常没有全局时钟，而是使用局部时钟进行时间同步或事件排序。
  4. 故障容忍性： 分布式系统能够应对节点故障和通信故障，继续提供服务或恢复正常运行。
  5. 可扩展性： 系统应能方便地添加或移除节点以适应不断增长的工作负载。
  6. 透明性： 对用户来说，系统内部的细节应该是透明的，用户无需了解数据是如何在不同节点之间传输和处理的。
  7. 异构性： 分布式系统中的节点可能运行不同的操作系统、硬件架构和编程语言。

微服务架构介绍 ​

微服务架构是一种设计风格，它将大型应用程序拆分成一组小型、独立的服务。每个服务专注于单一业务功能，并且能够独立部署、扩展和更新。

核心优势：

  • 模块化开发与部署： 每个服务可以独立开发、测试、部署和扩展，提高了敏捷性和生产力。
  • 技术栈多样性： 不同服务可以选择最适合当前需求的技术栈，而不用受限于整个应用的技术选择。
  • 伸缩性与弹性： 服务可以根据负载情况独立伸缩，提高了资源利用率和系统的可靠性。

挑战：

  • 服务间通信复杂性增加： 需要额外处理服务间的交互问题。
  • 运维难度增加： 需要成熟的运维体系来支持多服务的部署、监控和日志聚合。
  • 网络延迟： 服务调用依赖网络，可能会引入延迟和潜在故障。
  • 数据一致性： 跨服务的事务管理需要特殊的设计，比如最终一致性和事件溯源机制。

典型组件：

  • 服务注册与发现： 允许服务实例动态注册和发现其他服务的位置。
  • 服务间通信： 使用HTTP/REST、gRPC等协议进行同步通信，或者利用消息队列实现异步通信。
  • 配置管理： 集中管理服务配置，确保配置的一致性和灵活性。
  • 服务熔断与限流： 保护系统不受单个服务故障的影响，并防止过载。

RPC ​

HTTP/RESTful API ​

HTTP是一种应用层协议，通常用于Web应用程序之间的通信。RESTful API是基于HTTP的一种架构风格，它使用标准的HTTP方法（GET、POST等）来操作资源。虽然HTTP不是专门为RPC设计的，但它被广泛应用于构建分布式系统中的服务接口

  • 优点：
    • 简单易用，适合开发Web应用和移动应用。
    • 广泛支持，几乎所有现代编程语言都支持HTTP。
    • 具有良好的文档和社区支持。
  • 缺点：
    • 性能较低，因为HTTP消息通常是文本格式，体积较大。
    • 不支持双向流式通信，难以实现实时通信场景。

gRPC ​

gRPC是由Google开发的一个高性能、开源的通用RPC框架。它基于HTTP/2协议，使用Protocol Buffers作为接口定义语言(IDL)和消息交换格式，提供了高效的序列化机制

  • 优点：
    • 支持多种语言，具有跨语言能力。
    • 使用二进制格式进行序列化，效率高。
    • 支持双向流式通信，适用于实时通信场景。
    • 提供了负载均衡、服务注册与发现等功能。
  • 缺点：
    • 相对较新，学习曲线可能较高。
    • 需要额外的工具链来生成客户端和服务端代码。

XML-RPC 和 JSON-RPC ​

XML-RPC 和 JSON-RPC 是基于网络的轻量级RPC实现方式，它们分别使用XML和JSON格式来封装请求和响应，提供了一种跨语言的通信协议

  • XML-RPC:
    • 使用XML格式，支持复杂的数据结构。
    • 比JSON-RPC更早出现，有一定的历史积累。
  • JSON-RPC:
    • 使用更简洁的JSON格式，通常更快，适合大量数据交换。
    • 因为JSON的普及度高，所以更容易集成到现有的系统中。

每种RPC实现方式都有其适用的场景和优缺点，在选择时需要根据具体的应用需求来决定。例如，对于性能要求较高的内部服务间通信，gRPC可能是更好的选择；而对于公开API或者需要简单快速集成的情况，HTTP/RESTful API则更为合适。

RPC 调用分以下两种： ​

  1. 同步调用：客户方等待调用执行完成并返回结果。
  2. 异步调用：客户方调用后不用等待执行结果返回，但依然可以通过回调通知等方式获取返回结果。若客户方不关心调用返回结果，则变成单向异步调用，单向调用不用返回结果。

异步和同步的区分在于是否等待服务端执行完成并返回结果。

CAP理论 ​

CAP 是分布式系统中的一个重要理论，由计算机科学家 Eric Brewer 提出，被称为 CAP 定理（也称 CAP 理论）

什么是CAP？ ​

CAP是三个单词的缩写

缩写含义说明
CConsistency（一致性）所有节点在同一时间看到的数据是一致的。即：写操作完成后，后续所有读操作都能读到最新的值。
AAvailability（可用性）系统始终能够在合理时间内返回非错误的响应（不保证是最新的），即使部分节点故障。
PPartition Tolerance（分区容错性）系统在部分节点之间网络通信失败（即发生“网络分区”）时，仍能继续运行。

CAP 定理的核心观点 ​

一个分布式系统最多只能同时满足三项中的两项。

也就是说，在面对网络分区（P）时，你必须在一致性（C）和可用性（A）之间做出选择：

  • CA：放弃 P → 不是真正的分布式系统（假设网络永远可靠）
  • CP：放弃 A → 网络分区时拒绝请求，保证数据一致
  • AP：放弃 C → 网络分区时继续提供服务，但数据可能不一致

在分布式系统中，P（分区容错性）是必须的，因为网络不可靠。因此，实际选择往往是在 CP vs AP 之间。

例子 ​

假设有两个服务器（A 和 B），数据需要同步。突然 A 和 B 之间的网络断了（发生 网络分区）：

场景 1：选择 CP（一致性和分区容错性） ​

  • 客户端向 A 写入新数据。
  • 但由于 A 无法与 B 同步，为了保持一致性，A 拒绝写入。
  • ❌ 服务不可用（牺牲 A）
  • ✅ 保证数据一致（C）

场景 2：选择 AP（可用性和分区容错性） ​

  • 客户端向 A 写入新数据，A 接受写入并返回成功。
  • B 由于网络断开，数据未更新。
  • ✅ 服务可用（A）
  • ❌ 数据不一致（牺牲 C）

总结 ​

选择特点适用场景
CP保证一致，可能拒绝服务金融、账务、注册中心
AP保证可用，允许短暂不一致社交、评论、购物车

框架学习 ​

Dubbo

最近更新