RPC函数的原子化处理

一个函数应该只做一件事。这个原则在本地代码里容易遵守，在 RPC 调用里却经常被打破。

原因很简单：每次 RPC 调用都有成本。网络延迟、序列化开销、连接建立，这些都让开发者倾向于把多个操作塞进一个远程函数里。调用一次总比调用三次快。

但这种优化带来了新的问题。

当失败发生时

假设这个函数在第三步失败了。邮件服务挂了，或者超时了，或者只是网络抖动。函数会返回什么？

如果返回错误，客户端会以为整个操作失败了。但实际上前两步已经成功了：用户信息已经更新，数据库已经改变。客户端可能会重试，导致重复更新。或者放弃，但用户会看到不一致的状态。

如果返回成功，客户端会以为一切都好。但实际上邮件没发出去，用户没收到通知。后续可能有依赖这个通知的逻辑，现在都会出问题。

这就是非原子化的代价：失败变得模糊不清。你不知道哪些步骤成功了，哪些失败了，应该重试什么，应该补偿什么。

原子性的真正含义

原子性不是说操作不可分割。它是说操作的结果只有两种：要么全部成功，要么全部失败。不存在中间状态。

对于本地事务，数据库帮你保证原子性。如果事务中任何一步失败，整个事务回滚，就像什么都没发生过。

但 RPC 调用没有这种保证。一个远程函数可能执行了一半就失败了。它可能修改了数据库，但没能发送消息。它可能扣了钱，但没能发货。

你需要自己保证原子性。

拆分的策略

把一个复杂的远程函数拆成多个简单的，听起来容易，做起来需要权衡。

按业务边界拆分：更新用户信息是一件事，发送通知是另一件事。它们不应该在同一个函数里。前者是核心操作，必须成功。后者是附加功能，可以异步处理，可以失败重试。

按失败域拆分：修改数据库和调用外部服务是不同的失败域。数据库操作通常快速可靠，外部服务可能慢、可能不稳定。把它们混在一起，失败会传染。一个不稳定的服务会拖慢整个函数。

按幂等性拆分：有些操作天然幂等，比如设置用户状态。有些操作不幂等，比如增加计数器。把幂等和非幂等操作混在一起，重试会变得危险。拆开它们，你可以安全地重试幂等部分。

拆分的代价是更多的网络调用。但这个代价值得，因为你得到了清晰的语义。每个函数的职责单一，失败的边界明确，重试的策略清楚。

编排在客户端

当你把一个复杂操作拆成多个简单函数，就需要有地方来编排它们。这个地方通常是客户端。

客户端调用 updateProfile(userId, newProfile)，成功后调用 sendNotification(userId, event)，最后调用 logAudit(userId, action)。每一步都是原子的，失败了可以单独处理。

但这意味着客户端需要处理更多逻辑：它需要知道调用的顺序，需要处理每一步的失败，需要决定哪些步骤可以重试，哪些需要人工介入。

这是对的。客户端最了解业务流程，最清楚哪些操作是必须的，哪些是可选的。把编排逻辑放在客户端，让每个服务专注于自己的职责。

批量操作的困境

原子化会遇到一个实际问题：批量操作。

如果你需要更新一千个用户，调用一千次 updateProfile 显然不现实。你需要一个批量接口 batchUpdateProfiles(updates)。

但批量操作天然不是原子的。一千个更新中，有些可能成功，有些可能失败。返回值会变成一个列表，标记每个操作的状态。

这没有违反原子性原则。相反，它让原子性的边界更清楚：每个单独的更新是原子的，整个批次不是。客户端知道哪些成功了，可以重试失败的那些。

关键是不要在批量操作里混入其他逻辑。batchUpdateProfiles 应该只更新用户信息，不应该发邮件、不应该记日志、不应该调用其他服务。保持单一职责，即使在批量场景下。

代价与收益

原子化让系统更容易理解。每个函数做一件事，失败的语义清晰，重试的策略简单。

代价是更多的网络调用。更多的延迟，更多的序列化，更多的连接开销。在性能敏感的场景下，这可能无法接受。

但性能问题通常有其他解决方案：缓存、批量、异步、队列。而复杂度问题很难解决。当一个函数做太多事情，它就变成了黑盒。你不知道它的状态，不知道失败意味着什么，不知道如何修复。

在大多数情况下，清晰比快速更重要。因为清晰的系统可以优化，混乱的系统只能重写。

最后

原子化不是教条。有时候你需要在一个函数里做多件事，有时候性能确实比简单重要。

但默认应该是原子化。让每个远程函数有清晰的职责、明确的边界、可预测的行为。当你需要做多件事情，在客户端编排，或者清楚地标记哪些是核心逻辑，哪些是附加功能。

分布式系统已经够复杂了。不要让函数的职责也变得模糊。