这几天下雨，小区的一排路灯坏了，意外引发了我和儿子的一段对话。这段看似平常的问答，却让我联想到技术架构中的一个经典命题——微服务的拆分边界。我觉得其中蕴含的道理值得分享。

一段关于路灯的追问

晚上散步，儿子指着黑着的一排路灯，一脸疑惑地问我：

儿子：爸爸，这排灯咋都不亮了？
我：可能坏了吧。
儿子：为啥坏了呀？
我：估计是下雨，线路短路了。
儿子：那旁边那些灯怎么好好的？
我：哦，它们可能不在同一条电路上。
儿子：为啥不都接在一块儿呢？
我：分开接好修啊！你看，就这一排不亮，说明问题就出在这儿；要是整个小区的灯全灭了，咱不得挨个查半天？
儿子：那干脆每个灯自己拉一根线呗？这样哪个坏了不一眼就看出来了？
我：哎呀，那样太麻烦啦！每个灯都单独布线，施工成本太高了。
儿子：那到底几个灯用一条线才合适啊？
我：……这个嘛，爸爸还真说不准。

儿子的问题层层递进，从现象追问到设计逻辑，最后抛出了一个连工程师都未必能轻易回答的难题。

从路灯到微服务：寻找平衡的艺术

儿子的问题让我联想到软件架构中的一个经典难题：大单体与微服务之间，该如何取舍？

微服务并非越小越好。拆分得过于细碎，虽然故障隔离性更强，却会显著增加开发复杂度、部署成本和运维负担。

但反过来，单体也不是越大越好。当系统臃肿不堪，任何微小改动都可能牵一发而动全身，维护成本高企，业务价值却难以释放。

关键在于找到那个“恰到好处”的平衡点——用合理的拆分粒度，在可控的成本下实现最大的业务敏捷性与系统稳定性。

现实中，我们常常渴望一个明确的答案：“该拆”或“不该拆”。但真实世界很少提供这样的确定性。与其等待完美的方案，不如在实践中不断试错、调整、优化。正如我在另一篇文章中所写：《用正确的方式做事情》比执着于“做正确的事”更重要——因为“正确”的边界，往往是在行动中逐渐清晰的。