分布式 on Tofuwine's Blog

主流分布式技术集合导览

Fri, 14 Aug 2026 00:00:00 +0000

微服务开发框架

项目	简介	相关链接
Spring Cloud		官方网站
Spring Cloud Alibaba	Spring Cloud Alibaba 致力于提供微服务开发的一站式解决方案。	官方网站 Spring Cloud Alibaba

注册 & 配置中心 (Discovery & Config)

项目	简介	相关链接
Nacos	一个易于构建 AI Agent 应用的动态服务发现、配置管理和 AI 智能体管理平台。	官方网站
Spring Cloud Config	Spring 官方配置中心	官方网站
Consul	HashiCorp，注册发现 + KV 配置	官方网站 Spring Cloud Consul
Apollo (阿波罗)	分布式配置管理（携程开源）	官方网站
Apache Zookeeper	Apache 开源的分布式协调服务，基于 ZAB（ZooKeeper Atomic Broadcast，原子广播）一致性协议，用来解决分布式系统里的协调问题	官方网站
Eureka	注册中心	Github

服务间调用

项目	简介	相关链接
Apache Dubbo	Apache Dubbo 是一款 RPC 服务开发框架，用于解决微服务架构下的服务治理与通信问题。	官方网站
gRPC	gRPC 是一个现代开源的高性能 RPC 框架	官方网站
Spring Cloud OpenFeign	Spring Cloud 提供的声明式 HTTP 客户端，用来做微服务之间的服务调用。（前身是 Netflix Feign）	官方网站

分布式消息 (Messaging)

项目	简介	相关链接
Apache Kafka	分布式流消息平台,高吞吐日志 / 数据流，大数据场景	官方网站
Apache RocketMQ	阿里开源，高可靠业务消息，支持事务消息	官方网站
RabbitMQ	AMQP 协议，可靠性强，业务队列	官方网站
Apache Pulsar	云原生分布式消息流平台	官方网站

路由 (Routing)

项目	简介	相关链接
Spring Cloud Gateway	SpringCloud 官方响应式网关	官方网站
Apache APISIX	云原生高性能网关，Nginx+Lua，多语言	官方网站
Apache ShenYu	Java 原生 API 网关，用于服务代理、协议转换和 API 治理	官方网站
Higress	云原生 API 网关	官方网站
Traefik	云原生 Ingress 网关	官方网站
Kong	Nginx 内核，企业级 API 网关	官方网站
Zuul	路由网关	Github

断路器 (Circuit Breaker)

项目	简介	相关链接
Sentinel	面向分布式、多语言异构化服务架构的流量治理组件	官方网站
Resilience4j	轻量级容错库，转为函数式编程设计	官方网站

分布式事务

项目	简介	相关链接
Seata	微服务分布式事务	官方网站

分布式数据库中间件 & 分库分表

项目	简介	相关链接
Apache ShardingSphere	用于数据分片、扩展、加密等的分布式 SQL 事务与查询引擎——适用于任何数据库。	官方网站
MyCat2	开源分布式数据库中间件	官方网站

链路追踪 (Tracing)

项目	简介	相关链接
SkyWalking	分布式追踪、指标、日志、性能分析和告警	官方网站
Zipkin	分布式追踪系统，用于收集服务架构中延迟问题排查所需的时序数据。	官方网站
Jaeger	开源分布式追踪平台。	官方网站
Prometheus	为系统和服务提供开源的度量与监控	官方网站
Grafana	开源数据可视化工具	官方网站

服务网络 Service Mesh

项目	简介	相关链接
Istio	云原生服务网格，流量治理、安全、可观测，无侵入	官方网站
Envoy	高性能代理，Istio/Higress 数据面底层组件	官方网站

分布式任务调度

项目	简介	相关链接
PowerJob	全新一代分布式任务调度与计算框架。	官方网站
Elastic-Job	一个分布式调度解决方案，包括 ElasticJob-Lite 和 ElasticJob-Cloud	官方网站
xxl-job	分布式任务调度平台	官方网站
QuartZ	功能丰富的开源作业调度库	官方网站
SchedulerX 2.0	阿里中间件自研的基于 akka 架构的新一代分布式任务调度平台

分布式存储

项目	简介	相关链接
MinIO	对象存储，兼容 S3 协议	官方网站
Apache HDFS	Hadoop 分布式文件系统	官方网站
Redis Cluster	分布式缓存，集群模式	官方网站

其他中间件

项目	简介	相关链接
Logstash	Logstash 是一个开源的服务器端数据处理管道，能够从多种来源采集数据、对其进行转换，然后将其发送到您指定的目标存储中。	官方网站
Elasticsearch	Elasticsearch 是一个分布式、RESTful 风格的搜索和分析引擎，基于 Lucene 构建。	官方网站

技术组合推荐

传统 VM Spring Cloud Alibaba

虚拟机部署，Java 微服务

注册 & 配置中心：Nacos
RPC：Dubbo
网关：Spring Cloud Gateway
限流、熔断：Sentinel
MQ：RocketMQ / Kafka
分布式事务：Seata
任务调度：PowerJob
链路追踪：SkyWalking + Prometheus + Grafana
分库分表：ShardingSphere-JDBC

K8s 云原生方案

注册 & 配置中心：Nacos / K8s 原生 ConfigMap
RPC: gRPC
网关：APISIX / Higress
MQ: RocketMQ / Kafka
流量治理：Istio (ServiceMesh)
链路追踪：OpenTelemetry + SkyWalking + Prometheus + Grafana
分库分表：ShardingSphere-Proxy

CAP 定理与 BASE 理论

Sun, 09 May 2021 00:00:00 +0000

前言

在后端开发、微服务架构、分布式存储的学习和实践中，CAP 定理和 BASE 理论是绕不开的核心底层理论。几乎所有分布式组件（数据库、缓存、注册中心、消息队列）的设计取舍、性能特性、使用场景，都能在这两套理论中找到答案。

为什么需要 CAP 与 BASE ?

单机系统的完美闭环

传统的单机架构中，所有数据、计算、存储都集中在一台服务器，依托数据库的 ACID 事务特性，可以轻松实现强一致性、高可用性、数据可靠性，无需复杂权衡，系统逻辑简单可控。

分布式系统的核心矛盾

随着互联网业务爆发，高并发、大数据量、高可用需求倒逼架构从单体走向分布式。多节点部署、跨机器通信、集群扩容成为常态，但也带来了本质问题：网络不可靠、节点可能宕机、数据同步存在延迟。

此时单机时代的绝对一致性设计完全失效，架构师必须在「数据一致」和「服务可用」之间做出取舍。正是为了解决分布式系统的设计权衡问题， CAP 定理与 BASE 理论应运而生，成为分布式架构的设计准则与约束边界。

CAP 定理: 分布式系统的不可能三角

理论起源

CAP 定理由加州大学伯克利分校 Eric Brewer 教授在 2000 年提出猜想，2002 年麻省理工学院科学家通过数学严谨证明，正式成为分布式领域的权威定理，定义了分布式系统的三大核心特性约束，又称布鲁尔定理。

三大核心特性

CAP 是三个核心特性的缩写，分别对应一致性、可用性、分区容错性，三者无法同时完全满足，最多兼得其二。

C - Consistency 一致性

指分布式集群中，所有节点在同一时刻的数据完全一致。任意客户端访问任意节点，读取到的都是最新写入的数据，不存在数据延迟、脏数据、旧数据问题，也就是常说的「强一致性」。

典型场景：银行转账、支付交易、订单金额核算，这类场景绝对不允许数据不一致。

A - Availability 可用性

指系统任何时刻都能正常响应客户端请求，不会出现宕机、阻塞、超时、拒绝访问等情况。无论是否有节点故障，所有合法请求都能在有限时间内得到正常返回结果，保证服务持续可用。

典型场景：电商首页展示、商品评论、点赞浏览、资讯推送，优先保证用户可访问，容忍短暂数据偏差。

P - Partition Tolerance 分区容错性

指当分布式集群出现网络分区故障（断网、丢包、节点间通信中断）时，系统依然可以正常运行，不会整体瘫痪。网络分区是分布式系统的固有问题，属于不可避免的客观故障。

CAP 核心取舍逻辑

很多新手误解：CAP 是三选二，三种组合随意选。但真实的工程结论是：分布式系统必须保证 P（分区容错性）。

因为只要是多节点分布式部署，网络故障就是必然事件，放弃 P 就意味着一旦网络波动，整个系统直接崩溃，这不符合分布式高可用的设计初衷。

因此分布式系统的真实取舍只有两种：

CP 架构（舍弃可用性，保证强一致）：网络分区发生时，为了避免数据不一致，系统主动阻塞请求、停止对外服务，优先保障数据绝对准确。

代表组件：Zookeeper、MySQL 强一致主从集群。
AP 架构（舍弃强一致性，保证高可用）：网络分区发生时，系统持续对外提供服务，允许节点数据短暂不一致，等待网络恢复后再同步数据。

代表组件：Nacos、Redis Cluster、Eureka

BASE 理论：CAP 取舍的工程落地方案

理论起源

BASE 理论由 eBay 架构师在 2008 年提出，是针对 AP 架构的工程实践指导思想。如果说 CAP 定理告诉我们「分布式系统不能什么都要」，那 BASE 理论就告诉我们「选择高可用后，系统该如何设计、如何容错、如何兜底」。

BASE 是对传统 ACID 强事务模型的弱化适配，完美适配互联网高并发、高可用的业务场景。

三大核心特性详解

B - Basically Available 基本可用

系统出现故障或网络分区时，不保证完全功能可用，但保证核心功能不瘫痪。允许适度降级、延迟变长、部分非核心功能不可用，以此换取整体服务不宕机。

实战案例：电商大促时，商品详情页正常展示、下单功能正常使用，但关闭热门商品的实时销量统计、用户评论加载等非核心功能。

S - Soft State 软状态

打破单机数据「硬一致性」，允许集群节点数据存在短暂中间状态、不一致状态，无需时刻保持数据同步。节点数据可以异步更新、延迟同步，不需要实时强一致性校验。

实战案例：多端登录的用户会话、朋友圈点赞数据、缓存与数据库的临时数据偏差。

E - Eventually Consistent 最终一致性

这是 BASE 理论的核心精髓。系统不追求实时强一致性，但保证在一段时间后，当网络恢复、同步完成、无新数据写入时，所有节点的数据会自动对齐，最终达成完全一致的状态。

互联网 90% 以上的业务场景，都适配最终一致性，无需强事务支撑。

总结

CAP 是理论约束，定义了分布式系统的取舍边界；BASE 是工程解决方案，是 CAP 定理中 AP 选型的落地实现。二者相辅相成，共同构成分布式架构的设计基石。