问题

在展开分布式架构之前，先用几个核心问题作为线索，串联起全文：

  1. 何为分布式，何为微服务？——明确概念边界，区分"多机协作"与"服务拆分"两个维度。
  2. 为什么需要分布式？——从单机瓶颈出发，理解扩展性、高可用、容错的工程动机。
  3. 分布式核心理论基础是什么？——节点、网络、时间、顺序、一致性是构建一切分布式系统的物理与逻辑前提。
  4. 分布式系统有哪些设计模式？——从可用性、数据管理、弹性、安全等维度归纳可复用的解决方案。
  5. 分布式有哪些类型？——按存储、计算、消息、监控等场景分类，建立技术选型的全景图。
  6. 如何实现分布式？——从资源调度、流量调度、服务调度、数据调度到运维监控，落地为工程实践。

关键词

节点，时间，一致性，CAP，ACID，BASE，P2P，机器伸缩，网络变更，负载均衡，限流，鉴权，服务发现，服务编排，降级，熔断，幂等，分库分表，分片分区，自动运维，容错处理，全栈监控，故障恢复，性能调优

全文概要

随着移动互联网的发展和智能终端的普及，计算机系统从单机独立工作过渡到多机器协作工作。计算机以集群的方式存在，按照分布式理论的指导构建出庞大复杂的应用服务。本文从分布式基础理论、架构设计模式、工程应用、部署运维、业界方案这几大方面，介绍基于 MSA（微服务架构）的分布式知识体系大纲，从而对 SOA 到 MSA 的进化有立体的认识，从概念和工具应用上更进一步了解微服务分布式的本质。

基础理论

SOA 到 MSA 的进化

SOA 面向服务架构

当业务发展到一定程度，单一巨石系统会变得难以维护、难以扩展，于是需要按业务逻辑将其拆分为多个子系统，再通过服务接口通信，这就是 SOA（Service-Oriented Architecture）的核心思想。

SOA 的典型特征是依赖 ESB（企业服务总线） 进行服务集成：协议转换、路由、编排都集中在总线上完成，子系统之间不直接通信。这种模式带来三个突出问题：

  • 总线成为单点：所有流量经过 ESB，总线故障会波及全局。
  • 数据库常被共享：子系统逻辑隔离但物理共享数据库，表结构耦合，单点故障可能拖垮整个数据库。
  • 协议笨重：常基于 SOAP/XML，序列化与传输开销大，迭代效率低。

SOA 解决了"拆分"问题，但没有解决"独立"问题，因此需要更彻底的方案。

MSA 微服务架构

微服务架构（Microservice Architecture）在 SOA 的基础上进一步强调真正的独立：每个服务从入口、业务逻辑到数据持久层都逻辑隔离，拥有独立的数据库、独立的部署生命周期、独立的技术栈选择，服务间通过轻量级协议（REST、gRPC）通信，无需服务总线介入。

graph TB
  subgraph SOA
    A1[子系统A] --- ESB[ESB 服务总线]
    A2[子系统B] --- ESB
    A3[子系统C] --- ESB
    ESB --- DB[(共享数据库)]
  end
  subgraph MSA
    M1[微服务A] --> DB1[(DB-A)]
    M2[微服务B] --> DB2[(DB-B)]
    M3[微服务C] --> DB3[(DB-C)]
    M1 -.REST/gRPC.-> M2
    M2 -.REST/gRPC.-> M3
  end

微服务带来的收益与代价是并存的：

  • 收益：独立部署与伸缩、技术异构、故障隔离、团队自治、迭代敏捷。
  • 代价：分布式系统固有的复杂性——网络不可靠、数据一致性难、调用链路长、运维与监控成本陡增。

正因如此，微服务的兴起需要一整套技术栈（服务注册发现、配置中心、链路追踪、容器编排等）无缝接入，以支撑服务治理理念。

节点与网络

节点

节点是分布式系统中提供单位服务的逻辑计算资源集合。它的形态随技术演进不断变化：

  • 物理机阶段：节点即一台单体服务器，服务和数据库共置，资源利用率低、伸缩粒度粗。
  • 虚拟机阶段：通过虚拟化将物理机切分为多个 VM，节点演变为 VM 上的服务，隔离性增强但启动慢、开销大。
  • 容器阶段：容器技术（Docker）将应用与依赖打包，节点成为轻量级容器服务，秒级启动、密度高、易于编排。

理解节点时有一个关键假设：每个节点都是独立故障的。节点可能宕机、重启、时钟漂移、网络分区，分布式算法的设计必须以此为前提，而不是假设节点永远可靠。

网络

网络是分布式架构的根基。按消息延迟的可预测性，网络模型分为三类：

  • 同步网络：节点同步执行，消息延迟有已知上限，可以高效地使用全局锁与超时。真实互联网几乎不存在纯粹的同步网络。
  • 半同步网络：延迟大部分时间有界，但极端情况下无界。这是工程中最贴近现实的模型，许多一致性算法（Paxos、Raft）都建立在部分同步假设上。
  • 异步网络：节点独立执行，消息延迟无上限，无全局锁，部分需要超时与上界的算法不可行。互联网本质上是"尽力而为"的异步网络。

网络本身是不可靠的，常见的故障模式包括：丢包、延迟、乱序、重复、分区（partition）。分布式系统的所有难题几乎都源于"网络可能任意延迟或中断"这一事实。

常用网络传输层协议各有取舍：

  • TCP 协议：面向连接，通过序号与确认机制解决重复和乱序问题，保证可靠传输，但握手与确认带来额外延迟，速度较慢。
  • UDP 协议：无连接，发送即忘，适合常量数据流（如音视频、心跳、日志上报），丢包不致命，效率高但需应用层自行处理可靠性。

时间与顺序

时间

在单机系统中，进程内事件的先后由本地时钟决定。但在分布式系统中，不同节点的物理时钟各自独立，协调事件先后关系变得困难。

NTP（网络时间协议） 试图通过分层时间服务器把节点时钟同步到统一基准，但存在先天不足：

  • 节点间存在时钟偏移（skew），同步后仍有毫秒级误差。
  • 硬件时钟会漂移（drift），频率不一，同步后很快又偏离。
  • 网络延迟不确定，同步精度受网络抖动影响。

因此，分布式系统通常不依赖物理时钟来判定事件先后，而是引入逻辑时钟：

  • 逻辑时钟（Lamport Clock）：为每个事件分配一个单调递增的标量，定义" happens-before "关系。收到消息时，t' = max(t, t_msg + 1)。它能给出偏序，但无法区分并发事件。
  • 向量时钟（Vector Clock）：每个节点维护一个向量，记录所有节点的事件计数。更新规则 t_i' = max(t_i, t_msg_i)。向量时钟能精确判定两个事件是因果先后还是并发，是检测写冲突的基础。
  • 原子钟：利用铯原子跃迁提供极高精度的时间基准，配合 GPS 可实现全球同步。Google Spanner 的 TrueTime 即用原子钟 + GPS 提供"有界误差"的时间 API，使外部一致性成为可能。

顺序

顺序是一致性理论的基本概念。分布式系统中的顺序可分为：

  • 全序（total order）：任意两个事件都有确定的先后，强一致系统需要全序。
  • 偏序（partial order）：存在并发事件，无法比较先后，逻辑时钟给出的是偏序。
  • 因果序（causal order）：保留 happens-before 关系，是弱一致性系统协调的基础。

时间工具（逻辑时钟、向量时钟、原子钟）的引入，使得在不可靠网络上协商节点一致性成为可能。本质上，“一致性"就是"让多个节点对事件顺序达成一致”。

一致性理论

一致性是分布式系统的核心命题。根据对一致性强弱的要求，发展出三套理论体系。

强一致性 ACID

单机环境下，传统关系型数据库事务遵循 ACID 原则，是强一致性的代表：

  • Atomicity（原子性）：事务中的操作要么全部完成，要么全部不完成，由 undo/redo 日志保证。
  • Consistency（一致性）：事务执行前后，数据库的完整性约束不被破坏，是从原子性、隔离性推导出的结果。
  • Isolation（隔离性）：允许多个并发事务同时读写，通过锁与 MVCC 防止交叉执行导致不一致。隔离性分级为读未提交、读已提交、可重复读、串行化，强度递增、性能递减。
  • Durability（持久性）：事务一旦提交，数据修改永久保存，即使宕机也不丢失，由 WAL 与刷盘保证。

ACID 在单机内自然成立，但一旦数据分布到多机，保证原子性需要跨节点事务（两阶段提交 2PC），性能开销巨大。

分布式一致性 CAP

分布式环境下，网络分区不可避免，因此无法同时保证一致性、可用性和分区容忍性：

  • CAP：在一个存在网络分区的分布式系统中，一致性（C，所有节点读到相同数据）、可用性（A，每个请求都能收到响应）、分区容忍性（P，网络分区时系统仍能运转）三者不可兼得。由于真实网络一定会分区，工程上实际是在 CP（牺牲可用性，保证强一致，如 ZooKeeper、etcd）与 AP（牺牲强一致，保证可用，如 Cassandra、Eureka）之间做选择。
  • FLP 不可能性：在完全异步的网络环境中，只要存在一个恶意（或失效）节点，就不存在一个确定性的共识算法能在有限时间内达成一致。这从理论上界定了异步共识的上限，也解释了为何实际算法（Paxos/Raft）都依赖"最终超时"来打破僵局。
  • DLS 模型：给出了容错能力的边界——部分同步网络可容忍不超过 1/3 的错误节点（拜占庭错误）；纯异步模型无容错能力；同步模型理论上可达 100% 容错。

弱一致性 BASE

为了在分布式环境下兼顾性能与可用性，发展出最终一致性理论 BASE：

  • Basically Available（基本可用）：在故障期间允许部分可用性损失（如响应变慢、降级返回），但保证核心功能可用。
  • Soft State（软状态）：允许系统存在中间状态（数据副本不一致的过渡态），且该状态不影响整体可用性。
  • Eventual Consistency（最终一致性）：在没有新的更新操作后，经过足够时间，所有数据副本最终会达到一致状态。

BASE 是 CAP 中选择 AP 后的工程落地，是互联网高并发系统的主流选择。它与 ACID 并非对立，而是按业务场景取舍：账务核心用强一致，社交、库存、缓存等用最终一致。

一致性算法

一致性算法是让多个节点对某个值（领导选举、日志复制、配置变更）达成共识的机制，常用算法包括：

  • Paxos：由 Lamport 提出的优雅共识算法，通过 Proposer/Acceptor/Learner 三种角色与 Prepare/Accept 两阶段达成多数派共识。正确性严格但难以理解、工程实现复杂。
  • Raft：为"可理解性"设计的共识算法，通过 Leader 选举 + 日志复制 + 安全性约束实现与 Paxos 等价的能力。它把共识分解为三个相对独立的子问题（选主、日志复制、安全性），是目前工业界最流行的强一致共识算法（etcd、Consul、TiKV 均采用）。
  • Gossip：基于流行病传播的最终一致性算法，每个节点周期性地把自身状态随机同步给少量邻居，经多轮传播后全集群收敛。协议简单、容错好，适合对一致性要求不高的成员管理与数据同步（Cassandra、Redis Cluster）。

在算法理论层面，还有两个重要概念：

  • CALM 原则：如果一个逻辑是单调的（只增不减、只合不分），那么它无需中心节点调度就能保证最终一致性。这为无协调的分布式计算提供了理论依据。
  • CRDT 数据结构：Conflict-free Replicated Data Type，无需协调即可合并的数据结构，天然契合最终一致性：
    • 基于状态：节点间直接交换并合并 CRDT 状态，合并满足交换律、结合律、幂等律，顺序不影响结果（如 G-Set、G-Counter）。
    • 基于操作：节点把操作通知其他节点，操作本身可交换，任意顺序执行都能到达同一状态（如 PN-Counter、OR-Set）。典型应用有 Riak、Automerge、协同编辑（Yjs）。

场景分类

分布式技术按解决的问题域可分为若干类。理解分类有助于在选型时快速定位。

graph LR
  DS[分布式系统] --> FS[文件系统]
  DS --> DB[数据库]
  DS --> CC[计算]
  DS --> CA[缓存]
  DS --> MQ[消息]
  DS --> MN[监控]
  DS --> AP[应用]
  DS --> LG[日志]
  DS --> LD[账本]
  DB --> RDB[关系型<br/>Spanner]
  DB --> NOSQL[NoSQL]
  NOSQL --> COL[列式<br/>HBase]
  NOSQL --> DOC[文档<br/>ES/MongoDB]
  NOSQL --> KV[KV<br/>Redis]

文件系统

分布式文件系统解决单机存储容量与吞吐不足的问题，把大文件切分为块分散存储在多机，并通过副本保证可靠。常见系统各有侧重：

  • HDFS：Hadoop 生态基石，大文件、一次写入多次读取，适合离线批处理，延迟较高。
  • FastDFS：轻量级，适合中小文件的存储与同步，常用于图片、附件场景。
  • Ceph：统一存储（块、对象、文件），无中心架构，扩展性强，是云原生存储的主流。
  • MooseFS：容错性好，支持快照，适合通用文件共享。

数据库

分布式数据库分为关系型与 NoSQL，按数据模型进一步细分：

  • 列式存储（HBase）：面向列族，适合稀疏数据与高吞吐写入，按 rowkey 范围分片。
  • 文档存储（Elasticsearch、MongoDB）：Schema 灵活，ES 同时提供全文检索与倒排索引，MongoDB 适合半结构化业务数据。
  • KV 类型（Redis）：内存数据库，单线程模型保证原子性，性能极高，常作缓存与会话存储。
  • 关系型（Spanner）：Google 的全球分布式关系库，借助 TrueTime 实现外部一致性，是强一致分布式数据库的标杆。

计算

分布式计算按对延迟的容忍度分为三类：

  • 离线计算（Hadoop）：基于 MapReduce，处理历史批量数据，吞吐优先、延迟高。
  • 实时计算（Spark）：基于内存的 DAG 计算，比 MapReduce 快一个数量级，适合迭代与交互式查询。
  • 流式计算（Storm、Flink/Blink）：逐条处理无界数据流，毫秒级延迟。Flink 在Exactly-Once 语义与状态管理上更完善，逐渐成为流计算首选。

缓存

分布式缓存通过把热点数据放入内存，降低数据库压力、提升响应速度，核心难题是缓存与数据库的一致性：

  • 持久化（Redis）：支持 RDB/AOF 持久化，重启不丢数据，功能丰富。
  • 非持久化（Memcache）：纯内存、简单高效，适合单纯加速读取的场景。

一致性策略包括 Cache Aside（旁路缓存）、Read/Write Through、Write Behind，需在一致性与性能间权衡。

消息

消息队列通过异步解耦生产者与消费者，削峰填谷、消除异步复杂性：

  • Kafka：高吞吐、基于日志追加，适合流式数据与日志管道，顺序消息保证。
  • RabbitMQ：丰富路由模型，AMQP 协议，适合复杂业务路由。
  • RocketMQ：阿里开源，支持事务消息、定时消息，金融场景常用。
  • ActiveMQ：JMS 规范实现，功能全面但性能一般，多用于传统企业集成。

监控

分布式系统节点众多、调用链长，需要专门的协调与监控组件：

  • Zookeeper：提供配置维护、命名服务、分布式锁与领导选举，是早期 Hadoop/HBase/Kafka 的协调基石（基于 ZAB 协议，CP 系统）。

应用

应用间通信是微服务的血液，基于 RPC 或 HTTP 协议：

  • HSF：阿里内部高性能 RPC 框架，支持服务治理与高并发。
  • Dubbo：开源 RPC 框架，提供注册中心、负载均衡、集群容错能力，是国内主流选择。

日志

分布式日志系统用于故障定位与行为分析，通常分为采集、存储、定位三层：

  • 日志采集（Flume）：agent 模式，从各节点汇聚日志到中心。
  • 日志存储（Elasticsearch、Solr、SLS）：建立倒排索引，支持全文检索；SLS 是阿里云日志服务。
  • 日志定位（Zipkin）：分布式链路追踪，通过 traceId 串联跨服务调用，定位性能瓶颈与故障点。

账本

区块链是去中心化的分布式账本系统，通过密码学与共识机制实现无需信任的多方协作：

  • 比特币：首个去中心化加密货币，PoW 共识，UTXO 模型。
  • 以太坊：支持智能合约的可编程区块链，账户模型，推动 DeFi 与 DApp 生态。

设计模式

分布式系统的设计模式是解决反复出现问题的可复用方案，按关注点分为几组。

可用性

可用性模式的目标是让系统在部分故障时仍能对外提供服务：

  • 健康检查：定期探活（HTTP 心跳、TCP 探测），及时发现故障节点并将其从流量中摘除。
  • 负载均衡：把请求分发到多个实例，平滑重负载，避免单点过载。算法包括轮询、加权、最少连接、一致性哈希。
  • 节流（限流）：限制单位时间的请求量，保护后端资源不被打满，是熔断的上游防线。

数据管理

数据管理模式解决分布式数据存储与查询的复杂度：

  • 缓存：把热点数据加载到缓存层，减少对持久存储的访问。
  • CQRS：命令查询职责分离，写模型与读模型独立设计，读侧可针对查询优化（如物化视图），提升查询性能。
  • 事件溯源：不存储最终状态，而是记录导致状态变化的事件序列，状态由重放事件得到，天然支持审计与回溯。
  • 索引表：为高频查询字段在 NoSQL 中显式创建索引表，弥补其查询能力不足。
  • 物化视图：预先计算并填充查询结果视图，用空间换查询时间。
  • 拆分：水平分区（按行）或分片（按键），突破单机容量与吞吐上限。

设计与实现

这类模式关注系统结构与实现方式：

  • 代理（反向代理）：在客户端与服务间转发请求，隐藏后端拓扑，统一鉴权与 SSL 卸载。
  • 适配器：在现代化系统与遗留系统间做协议/数据转换，实现渐进式迁移。
  • 前后端分离：后端只提供 API，前端独立部署，职责清晰。
  • 网关聚合/卸载/路由：聚合多个后端请求为一次响应、卸载横切关注点（鉴权、限流）、按规则路由流量。
  • 领导人选举：在多节点中选出一个主节点协调工作，是主从架构的基础（如 Raft、ZAB）。
  • 管道和过滤器：把复杂任务分解为串行/并行的处理阶段，每阶段专注单一职责。
  • 边车（Sidecar）：把监控、日志、网格治理能力部署为独立容器与主应用伴生，实现能力与业务解耦（Service Mesh 的核心思想）。
  • 静态内容托管：静态资源交由 CDN 边缘节点加速，减轻源站压力。

消息

消息模式优化异步处理效率：

  • 竞争消费者：多个消费者并发消费同一队列，提升吞吐，需注意消息顺序性。
  • 优先级队列：高优先级消息优先被消费，适合VIP任务与告警。

管理与监控

公开运行时信息（指标、日志、链路），支持动态配置与管理，是可观测性的基础。

性能与扩展

支持动态水平扩展以应对负载变化，核心是无状态化（状态外置到共享存储），使实例可随时增减。

弹性

弹性模式让系统在故障下优雅降级而非崩溃：

  • 隔离：把不同资源/租户隔开，防止故障扩散（舱壁模式 Bulkhead）。
  • 断路器（熔断）：当依赖服务连续失败时熔断，快速失败而非长时间等待，保护调用方与被调方。
  • 补偿交易：在最终一致性场景中，通过反向操作撤销已执行的步骤，实现跨服务事务的"回滚"。
  • 重试：对临时性故障自动重试，需配合退避策略（指数退避）与重试上限，避免雪崩。

安全

分布式安全模式关注身份与访问控制：

  • 联合身份：与外部身份提供商（OIDC、SAML）集成，实现单点登录。
  • 看门人：网关层代理验证所有请求，未授权请求不进入内网。
  • 代客钥匙：颁发受限的临时凭证（如 STS Token），限定可访问的资源与时效。

工程应用

理论落地为工程，需要一套完整的调度与治理体系。

资源调度

弹性伸缩

  • 应用扩容：根据负载指标（CPU、QPS）自动扩展或缩容实例，是云原生的核心能力。
  • 机器下线：在低峰期回收闲置资源，控制成本，需先摘流量再下线。
  • 机器置换：故障机器无缝切换，先摘流、拉起新实例、再销毁旧实例。

网络管理

  • 域名申请/变更：统一管理域名与解析，避免混乱。
  • 负载管理：设定访问策略、路由规则、灰度比例。
  • 安全外联：拦截非法出站请求，防止数据外泄与挖矿。
  • 统一接入：统一权限管理与登录态，一次认证全网通行。

故障快照

  • 现场保留：故障发生后第一时间保存现场（内存 dump、线程栈、日志），便于事后分析。
  • 调试接入：在线接入诊断工具查看日志与状态。

流量调度

负载均衡

多层负载均衡协同工作，从外到内：交换机 → F5（硬件） → LVS（四层） → Nginx（七层） → VIPServer（客户端负载）。

网关设计

网关是流量入口，需具备高性能、分布式部署、业务筛选（鉴权、限流、路由、协议转换）能力。

流量管理

  • 请求校验：在入口拦截非法请求（参数、签名、权限）。
  • 数据缓存：使用 CDN 缓存静态与半静态内容，边缘加速。

流控控制

  • 流量分配：常用算法有计数器、队列、漏斗（匀速）、令牌桶（允许突发）。
  • 流量限制：基于 QPS、线程数、RT 阈值多维限流，工具如 Sentinel 提供流控、熔断、热点限流一体能力。

服务调度

注册中心

  • 状态类型：通过心跳检测服务可用性，维护实例健康状态。
  • 生命周期：管理服务注册、发现、下线的完整状态机。

版本管理

  • 集群版本：为集群定义统一版本号，便于灰度与回滚。
  • 版本回滚：异常时快速回退到稳定版本。

服务编排

容器编排与服务治理框架：K8S（容器编排事实标准）、Spring Cloud（JVM 微服务套件）、HSF、ZK+Dubbo。

服务控制

  • 发现：服务注册与健康检查，客户端从注册中心获取实例列表。
  • 降级：高峰期主动关闭非核心功能（如评论、推荐），保全核心链路。
  • 熔断：保护过载服务，工具如 Hystrix，依赖失败率/超时触发。
  • 幂等：通过全局一致性 ID（如 Snowflake 雪花算法）保证重复请求不产生副作用，是重试安全的前提。

数据调度

  • 状态转移：把状态从应用层转移到全局共享存储（Redis、DB），使应用无状态化、可水平扩展。
  • 分库分表：按业务维度纵向分库、按哈希/范围横向分表，突破单库瓶颈。
  • 分片分区：数据多副本冗余与分片分布，兼顾可用性与吞吐。

自动化运维

  • 配置中心：统一管理各环境配置，支持热更新与灰度发布（如 Apollo、Nacos）。
  • 部署策略：停机部署（简单但有损）、滚动部署（逐步替换）、蓝绿部署（两套环境切换）、灰度部署（按比例放量）、A/B 测试（按规则分流验证效果）。
  • 作业调度：分布式定时任务调度，如 SchedulerX、Spring 定时任务。
  • 应用管理：重启、上下线、日志清理等日常运维操作自动化。

容错处理

  • 重试设计：设置合理的重试次数与退避间隔，避免无效重试与雪崩。
  • 事务补偿：在 Saga 等最终一致性事务中，对失败步骤执行补偿操作恢复一致性。

全栈监控

监控需覆盖全栈，分层定位问题：

  • 基础层：监控 CPU、内存、磁盘、网络等硬件指标。
  • 中间件：监控数据库、缓存、消息队列的健康与性能。
  • 应用层：监控接口性能、错误率、业务指标。
  • 监控链路：端到端链路追踪，工具如 Zipkin、SLS、Goc、Alimonitor。

故障恢复

  • 应用回滚：保存故障现场后回滚到上一稳定版本。
  • 基线回退：代码版本回退，恢复到已知良好的基线。
  • 版本回滚：集群版本回滚，快速恢复整集群状态。

性能调优

  • 分布式锁：解决多实例并发读写缓存/共享资源的一致性（Redisson、Redlock）。
  • 高并发：多线程与异步提升吞吐量，注意锁竞争与上下文切换。
  • 异步：事件驱动提升响应效率，把耗时操作交给后台消化。

总结

分布式系统本质上是"用复杂度换取能力"：用网络把多机组织起来获得扩展性、高可用与容错，但也引入了网络不可靠、数据一致性、调用链复杂、运维困难等一系列难题。应对之道是备份与冗余——多副本保证可用，多实例分担负载，多机房容灾。

微服务背景下，Docker（容器化）、K8S（编排调度）和 Spring Cloud（服务治理）是构建分布式系统的核心技术栈，分别解决了"如何打包"“如何调度”"如何治理"三个问题。

最后需要强调一个工程原则：分布式的复杂度是真实且昂贵的。在性能需求不明确时，应优先考虑单节点或单体方案；只有当单机确实无法满足扩展性、可用性、容错要求时，才引入分布式架构。过早分布式化会带来远超收益的维护成本。