从单体到微服务：Service、Instance 与服务拆分到底是什么关系？

提到微服务，很多人首先想到的是 Spring Cloud、Dubbo、Nacos、Gateway、Kubernetes 等技术组件。

但如果一开始就从这些框架入手，很容易产生一种误解：似乎使用了 Spring Cloud 才算微服务，或者把一个项目拆成多个服务，就算完成了微服务架构改造。

实际上，微服务首先是一种系统组织方式，框架只是实现这种架构的工具。

要真正理解微服务，需要先弄清几个问题：单体应用到底有什么局限？Service 和 Instance 是什么关系？为什么要拆分服务？以及什么情况下根本不需要微服务？

一、单体架构真的不好吗？

假设我们需要开发一个简单的电商系统，包括用户管理、商品管理、订单管理和库存管理。

最初的实现可能是这样的：

             Client
                |
                v
        E-commerce Application
                |
       +--------+--------+
       |        |        |
     User    Order    Product
     Module  Module   Module
       |        |        |
       +--------+--------+
                |
              MySQL

用户、订单、商品等业务模块都运行在同一个应用中，共同完成业务逻辑。

这种架构通常称为 Monolithic Architecture（单体架构）。

它的一个典型特点是：多个业务模块作为一个整体构建和部署。

例如，一个使用 Spring Boot 开发的应用，包含以下模块：

ecommerce/
├── user/
├── order/
├── product/
├── inventory/
└── payment/

虽然代码已经按照业务模块组织，但最终仍然可以打包成一个应用统一部署。

单体架构并不意味着代码一定混乱，也不意味着所有代码都必须写在一起。一个设计良好的单体应用，同样可以有清晰的模块边界。

实际上，在项目初期，单体架构通常有明显优势。

一方面，部署简单。一个应用、一个数据库，就可以运行核心业务。另一方面，各模块之间可以直接进行进程内方法调用，不需要为每次业务交互引入网络通信。

例如创建订单时：

orderService.createOrder(request);
inventoryService.reserveStock(request);

如果两个模块处于同一个应用和事务边界中，很多业务操作可以直接依靠本地数据库事务来保证一致性。

而且，单体应用同样可以进行多实例部署和横向扩容，并不是只能运行在一台服务器上。

所以，单体不是一种落后的架构，而是具有不同复杂度和成本特征的架构选择。

单体真正的问题出在哪里？

随着业务增长，问题可能逐渐出现。

例如，商品查询流量增长很快，但订单服务的压力并不大。

由于商品模块和订单模块被打包在同一个应用中，如果想通过增加应用实例来扩展商品查询能力，通常需要把订单等其他模块一起部署。

再比如，支付模块修改了部分业务逻辑。即使用户管理和商品管理没有任何变化，也可能需要重新构建、测试和部署整个应用。

随着代码规模和团队人数增加，不同模块之间的依赖也容易变得复杂：

• 修改一个模块，可能影响其他模块。
• 不同团队需要协调同一个应用的发布时间。
• 某个模块产生严重故障，可能影响整个应用进程。
• 各业务模块无法按照各自的资源特点独立扩展。

需要注意，这些问题并不是每个单体应用都会遇到，也不是遇到了就必须立即改造为微服务。

但当应用规模、团队协作和部署节奏逐渐成为主要瓶颈时，独立部署不同业务能力就开始具有价值。

二、微服务到底改变了什么？

仍然以上面的电商系统为例。

如果将各业务模块拆分为独立运行和部署的服务，架构就可能变成：

                  Client
                     |
                     v
                 Gateway
                     |
          +----------+----------+
          |          |          |
          v          v          v
     User Service Order Service Product Service
          |          |          |
          v          v          v
       User DB    Order DB    Product DB

与单体架构相比，最大的变化不只是多了几个应用。

而是：

原来位于同一个部署单元中的业务能力，现在可以拥有独立的运行、部署和演进生命周期。

例如：

• Product Service 可以独立升级，不必重新部署 Order Service。
• Order Service 可以根据业务负载独立扩容。
• User Service 可以使用适合自身业务的数据模型。
• 不同服务可以采用不同的编程语言和技术框架。

不过，这种独立性并不是免费的。

原来两个模块之间的一次方法调用，现在可能变成：

Order Service
      |
      | HTTP / RPC
      v
Inventory Service

这意味着系统开始面对网络超时、服务发现、调用失败、接口兼容和数据一致性等问题。

以前本地函数调用成功或抛出异常，调用方通常能够比较直接地判断结果。

现在远程调用发生超时，调用方却不一定知道下游是否已经完成操作。

例如，Order Service 请求 Inventory Service 预留库存：

Order Service              Inventory Service
      |                           |
      |---- Reserve Stock ------->|
      |                           |
      |                      预留成功
      |                           |
      |<---- Response Lost -------X
      |
   Timeout

Order Service 看到了超时，但库存可能已经预留成功。

如果它不加判断地重新调用，就可能造成重复预留。

这说明微服务架构不是简单的代码拆分，而是把原来应用内部的问题，转化成了分布式系统需要处理的问题。

单体架构的主要挑战往往来自应用内部复杂度，而微服务在降低部分内部耦合的同时，也引入了跨服务通信与协调的复杂度。

这也是为什么微服务不一定比单体更简单。

三、Service 和 Instance 到底有什么区别？

这是理解微服务时特别容易混淆的两个概念。

先看一个场景。

我们开发了一个 Order Service，负责处理订单创建、查询和取消。

如果把它部署到一台服务器上，启动一个应用进程，那么系统中就有一个运行中的 Order Service 实例。

但如果订单流量不断增加，一个进程处理不过来，我们可以在多台机器上启动相同的服务程序：

                 Order Service
                       |
                Load Balancer
                       |
          +------------+------------+
          |            |            |
          v            v            v
      Instance 1   Instance 2   Instance 3
          |            |            |
          +------------+------------+
                       |
                    Order DB

这里有两个不同层次。

1. Service 是逻辑上的业务服务

Service 描述的是一组业务职责和对外提供的能力。

例如：

Order Service

对外提供：

POST /orders
GET /orders/{id}
POST /orders/{id}/cancel

无论它部署多少个实例，逻辑上仍然是同一个 Order Service。

因此可以理解为：

Service 回答的是"这是什么业务能力"。

2. Instance 是实际运行中的服务副本

Instance 则是服务代码的一次实际运行。

例如：

Order Service
    |
    +-- Instance A
    +-- Instance B
    +-- Instance C

三个实例运行相同的服务程序，都能够处理订单请求。

因此：

Instance 回答的是"这个业务服务现在由哪些运行实体提供"。

在 Kubernetes 环境下，我们经常通过多个 Pod 运行同一个服务的副本。对于常见的单应用容器 Pod，可以近似把一个 Pod 看成一个运行实例，但 Pod 与 Instance 并不是严格等价的概念。

还需要注意：Kubernetes 中也存在一个名为 Service 的资源，用来提供稳定的访问入口和网络转发能力。

它与我们讨论的业务 Service 不是同一个层次。

例如：

业务服务：Order Service
           |
K8s Service：order-service
           |
     +-----+-----+
     |     |     |
    Pod1  Pod2  Pod3

前者是业务架构概念，后者是 Kubernetes 的网络抽象。

3. 增加 Instance，不等于拆分 Service

假设 Order Service 只有一个实例：

Order Service
      |
  Instance 1

随着业务量增加，我们扩容到三个实例：

Order Service
      |
  +---+---+
  |   |   |
  I1  I2  I3

这叫水平扩容（Horizontal Scaling）。

我们并没有增加新的业务能力，只是通过更多运行实例提升现有服务的处理能力和可用性。

反过来，如果把 Order Service 中的库存管理逻辑拆出来，形成 Inventory Service：

Order Service
      |
      | RPC
      v
Inventory Service

这才涉及业务服务边界的调整。

因此，需要区分两个问题：

• 扩容解决的是一个服务需要多少运行资源。
• 服务拆分解决的是哪些业务职责应该由独立服务承担。

而且，增加服务实例也不一定能线性提高吞吐量。

假设三个 Order Service 实例都需要访问同一台 MySQL，真正的瓶颈如果已经出现在数据库，那么扩容到十个实例可能也无法明显提高整体 QPS。

四、微服务一定要使用 Spring Cloud 吗？

不需要。

这是理解微服务之后，自然可以得出的结论。

微服务定义的是服务如何组织、部署和协作，并没有规定必须使用哪一种编程语言。

例如，同一个系统完全可以采用：

User Service       Java / Spring Boot

Order Service      Go

Product Service    Python / FastAPI

Payment Service    C# / ASP.NET Core

这些服务都可以通过 HTTP、gRPC 或消息系统完成通信。

当然，实际项目中未必应该刻意使用多种语言。统一技术栈通常能降低维护成本。

Spring Cloud 提供的是一组微服务开发相关的基础设施与集成能力，例如配置管理、服务调用、服务发现和网关等。

同样的需求，也可以由其他方案实现。

例如：

需要解决的问题	可选实现
服务通信	HTTP、gRPC
服务发现	Nacos、Consul、Kubernetes DNS
入口路由	Spring Cloud Gateway、Envoy
异步通信	Kafka、RabbitMQ
服务部署	Docker、Kubernetes
配置管理	Spring Cloud Config、Nacos、ConfigMap

这些只是不同的技术选项，并不是每个微服务系统都需要同时引入。

例如，在 Kubernetes 中，Service 和 DNS 已经能够提供基础的服务寻址能力，是否还需要引入 Nacos，取决于具体架构和其他治理需求。

所以判断一个系统是不是微服务，关键不在于它使用了哪些框架，而在于是否形成了合理的业务边界、独立部署能力和服务间协作方式。

五、服务应该怎么拆？为什么不能按照数据库表拆？

理解 Service 与 Instance 之后，接下来就是微服务设计中更难的问题：

究竟哪些业务应该成为独立服务？

很多人在第一次设计微服务时，容易按照数据库表拆分。

例如一个订单系统有：

orders
order_items
order_status

于是拆成：

Order Service

OrderItem Service

OrderStatus Service

乍一看每个服务职责都非常单一。

但问题是，创建一个订单本来是一个完整的业务操作：

创建订单主记录
    |
创建订单明细
    |
设置订单状态

如果三个步骤分布在三个独立服务中，那么一次简单的下单操作就需要多次 RPC。

以前依靠一个 MySQL 本地事务就能完成的事情，现在还可能需要跨服务事务或补偿。

结果是服务数量变多了，系统却没有获得相应的业务价值。

这就是按照数据库表进行过度拆分容易出现的问题。

更合理的拆分思路：按照业务能力划分边界

仍然以电商系统为例。

我们可以先识别几类不同的业务能力：

Order Service

负责订单创建、订单明细、订单状态、取消订单等业务。

Inventory Service

负责库存查询、预留、确认和释放。

Payment Service

负责支付请求、支付状态、支付回调以及退款。

这些服务之所以值得独立，并不是因为它们分别对应了几张数据库表，而是因为它们具有相对独立的业务规则和数据生命周期。

例如库存预留与订单状态虽然有关联，但库存同时也可能服务于其他销售渠道。

支付服务则需要独立管理外部支付接口、支付幂等和退款等业务规则。

将这些职责划分清楚，才能在系统扩展时减少不必要的耦合。

不过，业务边界并不是唯一的判断标准，还需要考虑事务边界。

服务拆得太细，会增加分布式事务成本

假设 Order Service 需要执行：

创建订单
    |
预留库存
    |
等待支付

在单体应用中，部分数据库操作可能放进同一个事务。

但拆成不同服务后：

Order Service
    |
    | RPC
    v
Inventory Service

两个服务如果拥有独立的数据存储边界，那么各自的本地事务无法自动组成一个跨库原子事务。

这时就需要考虑 Saga、补偿、业务状态机等机制。

这些技术能够解决问题，但也增加了开发和运行复杂度。

因此，一个实用的原则是：

频繁一起修改、需要强事务约束、业务生命周期高度一致的数据，不应该仅仅因为它们属于不同的表就被拆进不同服务。

服务拆分需要同时考虑业务职责、数据所有权和事务边界。

六、独立服务是不是必须拥有独立数据库？

这里有一个很容易被误解的概念：

微服务强调数据所有权，并不意味着每个 Service 必须占用一台独立的数据库服务器。

例如：

Order Service
     |
  Order DB

Payment Service
     |
 Payment DB

这里的两个数据库，可以位于不同的数据库实例上，也可以在满足隔离要求的情况下，部署于同一台 MySQL 服务器的不同数据库或 Schema 中。

关键在于：

Order Service 应该负责维护自己的订单数据，Payment Service 不应该直接绕过 Order Service，随意修改订单表。

假设 Payment Service 支付成功，需要更新订单状态。

如果它直接操作 Order Service 的数据库：

Payment Service
       |
       v
   Order DB

看起来少了一次 RPC，但也意味着 Payment Service 开始依赖订单表的内部结构。

以后 Order Service 修改表结构，Payment Service 就可能受到影响。

服务表面上拆开了，数据库层面却仍然紧密耦合。

更合理的方式通常是：

Payment Service
       |
       | PaymentSucceeded
       v
     Kafka
       |
       v
  Order Service
       |
       v
    Order DB

或者在适当场景下，由 Payment Service 调用 Order Service 提供的接口。

这样订单数据仍然由 Order Service 负责维护。

当然，系统需要处理消息重复、投递失败和状态一致性等问题。

服务拥有独立数据边界，换来的是自主维护能力，同时也意味着跨服务的数据交互必须经过明确的接口或事件。

七、什么时候不应该采用微服务？

讲到这里，我们可以反过来考虑一个问题。

如果微服务具有独立部署和独立扩容的优势，是不是所有系统都应该使用微服务？

答案是否定的。

假设现在只有一个五人开发团队，业务仍处于早期阶段。

系统包含用户、订单和商品等模块，每天请求量也不大。

如果此时直接拆成十几个独立服务，可能需要额外维护：

服务部署
服务发现
配置管理
接口版本
跨服务认证
日志与链路追踪
网络超时与重试
数据一致性

原本一个应用就能完成的需求，现在需要维护多个应用和一套分布式基础设施。

而且服务拆分不代表业务复杂度消失了，只是有一部分复杂度被转移到服务协作过程中。

模块化单体可能是更好的起点

如果暂时没有独立部署和独立扩容的强需求，可以先使用模块化单体（Modular Monolith）。

例如：

E-commerce Application
    |
    +-- User Module
    |
    +-- Order Module
    |
    +-- Inventory Module
    |
    +-- Payment Module

所有模块仍然作为一个应用部署，但在代码层面保持明确的依赖关系和职责边界。

例如：

• 订单模块不能随意修改支付模块的内部数据。
• 模块之间通过定义清晰的接口协作。
• 避免把所有业务逻辑混进一个公共 Service。
• 将模块内部实现与对外接口分离。

这样做的价值是，既保留了单体应用部署简单、本地调用方便的特点，又降低了后续拆分业务模块的难度。

当然，模块化单体并不保证未来一定能无成本迁移为微服务，但清晰的边界会让演进更加容易。

什么时候值得真正拆分？

通常可以观察几个信号。

第一，业务模块的部署节奏开始明显不同。

例如商品团队每天发布新功能，但订单团队需要更严格的发布流程。统一部署开始影响团队效率。

第二，不同模块的资源需求出现明显差异。

例如商品查询需要大量横向扩容，而订单处理量相对稳定。把它们绑定在一个部署单元中，会产生不必要的资源开销。

第三，业务边界和数据所有权已经比较清晰。

能够明确说出某个服务管理哪些业务状态、对外提供什么能力，以及发生失败时由谁负责恢复。

第四，团队已经具备相应的工程能力。

例如能够维护自动化部署、日志、监控、追踪、告警，以及跨服务接口和数据一致性机制。

如果这些条件还不成熟，过早拆分往往只会增加复杂度。

八、总结：微服务的重点不是"拆得多"，而是"边界清楚"

回顾这一篇，几个概念需要明确区分。

概念	核心含义
Monolith	多个业务模块作为一个整体构建和部署
Microservice	围绕业务能力组织、可独立运行和演进的服务
Service	一组明确的业务职责与对外能力
Instance	某个 Service 实际运行中的一个副本
Horizontal Scaling	为现有服务增加运行实例
Service Splitting	调整业务职责及数据所有权的边界
Modular Monolith	保持模块边界，但仍统一部署的架构

这几个概念中，我认为最容易弄混的是 Service 和 Instance。

例如一个订单系统只有一个 Order Service，但它可以运行十个实例。

十个实例不代表十个微服务，只有一个实例也不代表系统是单体。

同样，单体应用可以拥有清晰的业务模块；微服务如果拆分不合理，也可能产生严重的耦合。

所以理解微服务，不能只看系统中有多少个应用、部署了多少个 Pod，或者使用了多少中间件。

真正应该关注的是：

每个服务负责什么业务，维护什么数据，为什么需要独立部署，以及这种拆分带来的收益是否足以覆盖分布式系统的额外成本。

在这个基础上，再去理解 RPC、Gateway、服务发现、Redis、Kafka 和 Kubernetes，整个微服务技术体系就会清晰得多。