Musashi vs Kojiro：软件架构可以从基础中学到什么

Source: Dev.to

在日本历史上，有一场决斗被人记住的不是它的壮观——而是它的克制。

佐佐木 小次郎身着荣誉的装束：长刀、完美的姿势、仪式、声望、形态。
宫本 武藏迟到而来，没有盔甲，也没有花哨的动作，手持一把用桨雕刻的木剑。

决斗很快结束——并不是因为小次郎软弱，而是因为武藏领悟了更深的道理：在不确定的条件下，基础胜过华丽。

现代软件架构每天都在上演这场决斗。

现代小次郎：“我们需要微服务来扩展”

每个创业公司最终都会听到这句话：

“我们需要微服务来扩展。”

有时这句话是对的，但大多数情况下它说得太早——在需要扩展之前，在找到产品‑市场匹配之前，甚至在团队还不知道要扩展什么之前。

典型的早期创业公司画像

• 1–3 名工程师
• 需求不稳定
• 没有真正的流量压力
• 预算有限
• 快速迭代周期

然而他们却去使用：

• Kubernetes
• 服务网格
• 分布式部署
• 多数据库策略
• 叠加在抽象之上的云抽象

这就像小次郎披着仪式盔甲去参加根本不需要它的战斗。微服务解决的是组织层面的规模问题，而不是早期的混乱。

在这个阶段，你用 一个硬问题（代码结构）换来了 五个更难的问题：

• 网络边界
• 部署复杂性
• 可观测性开销
• 安全面
• 分布式故障模式

刀剑虽好，但战场不对。

Musashi的选择：模块化单体

Musashi并没有拒绝刀剑；他拒绝的是不必要的仪式。其在架构上的等价物是 模块化单体。

模块化单体的特征是：

• 一个可部署的应用
• 具有严格的内部边界和纪律

关键属性

• 单一代码库
• 单次部署
• 明确的模块所有权
• 没有跨模块泄漏
• 域之间的显式契约

示例结构

/users
  /domain
  /service
  /controller

/billing
  /domain
  /service
  /controller

/analytics
  /domain
  /service
  /controller

每个模块：

• 拥有自己的数据
• 暴露接口
• 隐藏实现细节

这并不是“仅仅是文件夹”；而是有意的分离——Musashi的木刀：简洁、专注、致命。

为什么它在早期对决中获胜

运行成本低

• 部署一次，监控一次，调试一次。
• 基础设施费用保持单调——这本身就是一个特性。
• 没有需要照看的集群，也不必在交付前理解服务网格。

适应速度快

• 早期需求每天都在变化。
• 模块化单体让你可以自信地重构，内部变动不会产生连锁影响，快速前进而无后顾之忧。

安全更容易

• 单一应用意味着暴露面更少，认证流程更简洁，数据边界更清晰。
• 分布式安全更为困难。

团队清晰

• 即使只有两名开发者：一人负责认证，一人负责分析。
• 责任明确，所有权可见；不存在“谁把生产环境弄坏了？”的谜团。

使之成败的纪律

Musashi 仍在不懈训练。没有纪律，模块化单体系统会失败。

重要规则

• 模块之间禁止直接访问数据库（DB）。
• 禁止从其他模块导入内部服务。
• 只能通过已定义的接口进行通信。
• 共享代码必须放在显式的共享层中。

违反这些规则会导致纠结的单体系统，而不是模块化的——那是 cosplay，而不是 Musashi。

扩容时刻（小次郎失利之处）

When scale actually arrives:

• Traffic increases.
• Specific domains get hot.
• Team size grows.

At that point:

• Each module already behaves like a service.
• Boundaries are already enforced.
• Extraction becomes mechanical, not emotional.

You can:

• Containerize a single module.
• Deploy it independently.
• Move it to Cloud Run, ECS, Railway, etc., while leaving the rest untouched.

No rewrite, no panic, no “three months to re‑architect.” The system evolves; it doesn’t reset. This is Musashi adapting mid‑fight—not Kojiro trapped by form.

为什么我向早期创始人推荐它

它优化了以下方面：

• 学习
• 成本
• 速度
• 清晰度
• 未来的选择性

你并不是在拒绝微服务，而是在“赚取”它们。微服务是一种工具——就像小次郎的剑——而不是严肃性的徽章。

最昂贵的架构是你在理解问题之前就构建的那个。