分布式系统的准确定义是什么？常见相关技术概念辨析

行业内讨论分布式系统时默认存在两套并行的定义标准，不存在绝对的谁对谁错，只是讨论场景不同时大家默认的指代范围有区别，这也是概念边界看起来模糊的核心原因。

首先先明确两套定义的核心边界：

• 广义分布式系统：只要满足「跨独立计算节点（物理机、容器、独立进程均可）、通过网络传递消息协同工作、对上层/用户呈现为统一的逻辑服务整体」三个条件，就属于分布式系统范畴。这个定义边界非常宽，大家日常提到的微服务拆分、水平扩容、数据分片、甚至客户端调用云端接口的架构，都符合广义标准，这也是大家聊的时候指代范围杂的核心原因——多数人讨论时不会特意说明自己用的是广义定义。
• 狭义分布式系统：也就是大家聊分布式技术难点、方案选型时默认指代的范畴，特指系统本身需要直面分布式环境固有异常，并且要在异常场景下保证服务正确性、可用性的架构设计。这类系统需要解决的是网络分区、节点故障、消息丢失/乱序、节点时钟不一致等经典分布式问题，会涉及共识算法、多副本复制、一致性权衡、分布式事务等大家常听到的核心技术点。

针对行业内常见的三个认知分歧，可以直接对应两套定义拆解：

• 关于微服务的归属：按广义定义，把订单、支付等能力拆分到独立服务部署、靠RPC协同完成业务流程，当然属于分布式系统。但如果微服务集群全是无状态节点，所有共享状态（比如库存、订单数据）都存在单节点数据库上，本质是把分布式场景下的状态一致性、容错问题全甩给了那个单节点组件，业务层本身不需要处理分布式核心难题，这就是为什么有观点认为“多实例通过共识维护共享状态才算分布式系统”——这类观点讨论的是狭义场景，也就是系统自身要解决分布式核心问题的情况，并非否定微服务的分布式部署属性。
• 关于分布式数据库的定义：按广义定义，只要数据分散存储在多个节点、由协调节点做请求路由，对外呈现统一的数据库访问视图，就算分布式数据库，分片（sharding）本身就是分布式数据库最基础的能力之一。但工程语境下讨论分布式数据库的实现深度时，只有静态分片的架构是不被认可为完整分布式数据库的：如果单分片没有多副本容灾、分片故障直接丢数据/不可用、跨分片操作没有事务保证，本质只是“分片版的单机数据库”；真正符合狭义标准的分布式数据库，必须在分片之外解决多副本一致性、故障自动切换、分布式事务、跨分片查询优化等问题，具备对分布式固有异常的容错能力。
• 关于分布式限流的判定：按广义定义，只要限流逻辑和业务应用节点不在同一进程内，靠网络通信做限流判定，就算分布式限流——多应用节点调用单节点限流器的架构，完全符合这个标准，毕竟业务节点是分布式部署的，限流逻辑不放在本地。但在方案选型的讨论语境下，单节点限流器存在性能瓶颈、单点故障问题，本质是把分布式场景下的限流压力全集中在一个节点上，不算真正解决了分布式场景的限流问题；行业内普遍认可的多限流器节点搭配共享存储、限流器节点间同步阈值的无单点架构，才是狭义上的分布式限流实现。

不用纠结某类架构“到底算不算”分布式系统，技术讨论里只要提前对齐语境就不会有偏差：聊部署形态时用广义定义即可，聊系统设计难点、技术方案权衡时，默认指代需要处理分布式固有故障、做CAP权衡的狭义场景即可。

内容的提问来源于stack exchange，提问作者Kumar