后端反思：我们需要多少层微服务？小心过度设计陷阱！

在近年来的后端圈子里，"微服务"、"Serverless" 以及各种 "K8s 容器编排" 等高大上的词汇几乎成了每一个服务端技术分享的绝对标配。似乎如果你不用一套庞杂的、网状互联的分布式基础架构，你都会不好意思向别人说自己在开发后端平台。

但经过了几个周期的业务迭代、并主导参与了几场微服务架构重构后，我越发警惕一个现象：过度设计与盲目拆分是扼杀开发和调试效率的元凶。

对于绝大多数早中期的项目、乃至于大部分的中型甚至个别大型团队，一个结构逻辑清晰、代码规整的模块化单体架构 (Modular Monolith) 所带来的开发舒适度、测试独立性和维护性，其实往往远高于被强行拆解成数十个相互通过 RPC 或 HTTP 网络调用的微服务集簇。

我们在线上排查环境时，经常低估了跨越服务通信所带来的复杂物理边界问题： 比如高并发场景下带来的雪崩效应、捉摸不定的分布式事务回滚难题、长调用链路里的丢包定位，甚至是极其恶心的级联超时排雷等... 这些隐形的团队沟通排错成本一旦爆发，通常会瞬间吃掉当初为了采用微服务而吹捧的那点“不同语言模块可自由扩展开发”的光环红利。

在技术栈选型时，我个人觉得只有当代码层级或者业务边界已经明确到了某种不可调和的业务隔绝，亦或是当前核心链路流量大到了单机甚至常规读写分离集群实在无法横向延展的时候，再去逐步探索拆分微服务化才是真正符合工程学定律的。

不要为了炫技而强行引入 Kubernetes 等系统去玩花式 DevOps。保持纯粹，信奉 Unix 的老哲学 KISS法则 (Keep It Simple, Stupid)，才是后端这门手艺最核心且优雅的艺术。