后端反思：好的架构不是拆得越细越高级
后端架构很容易让人产生一种错觉：只要引入了更多层级、更多服务、更多中间件，系统就自然变得专业。图画得越像云原生大会的分享稿，似乎越能证明团队在技术上足够先进。
但真正维护过线上系统的人都知道，复杂度从来不会免费。你把一个函数拆成远程调用，把一次事务拆成事件链，把一个部署单元拆成十几个服务，就等于同时引入网络抖动、版本协同、链路追踪、数据一致性、发布顺序和跨团队沟通成本。
这些成本平时不说话，一旦系统出问题，它们会一起站出来。
模块化单体仍然很有价值
很多项目并不是从单体走向微服务，而是从“没有边界的单体”走向“有边界的系统”。这两者差别很大。
一个设计良好的模块化单体，可以拥有清晰的领域边界、独立的业务目录、稳定的接口约定和可测试的服务层。它的部署仍然简单，调试仍然直接，数据一致性也更容易被理解。对于早中期项目，这种结构往往比一开始就拆成微服务更健康。
微服务真正解决的是组织和伸缩问题，不是代码审美问题。当团队规模、业务边界、流量模型和发布节奏都还没有逼迫你拆分时，过早拆分通常只是在制造分布式版本的混乱。
拆分前先问三个问题
每次想把某块逻辑拆出去之前，我现在会先问自己三个问题：
- 它是否有独立的业务生命周期？
- 它是否有明显不同的伸缩需求？
- 它的故障是否应该和主系统隔离？
如果答案都不明确，那可能先在代码层面做好边界就够了。目录、接口、测试、数据库约束、领域事件，这些东西比仓促多开一个服务更重要。
拆服务不是从复杂走向优雅，而是从一种复杂走向另一种复杂。只有当新的复杂度能换来清晰的组织收益或性能收益，它才值得。
可观测性不是补丁
如果系统已经进入多服务阶段，日志、指标、链路追踪和告警就不再是锦上添花，而是基础设施。没有观测能力的微服务系统，本质上是在黑暗里跑接力赛。每个服务都说自己没问题，但用户请求就是慢，就是失败，就是偶尔丢。
我更愿意把可观测性当成架构设计的一部分：关键链路必须有 trace id，核心错误必须结构化，指标要能回答容量、延迟、失败率和依赖健康度。否则系统越拆，排障越像猜谜。
简单是一种高级能力
后端工程最难的地方，往往不是学会某个新框架，而是在足够多的诱惑面前保持克制。能用数据库唯一索引解决的问题，不一定要引入分布式锁；能用队列削峰的问题，不一定要改造成复杂的事件网；能用模块边界解决的问题，不一定要拆成独立服务。
架构的目标不是显得厉害，而是让系统在真实业务里稳定地跑，让后来的人愿意继续维护。简单不是低级，简单是你认真理解过复杂之后，仍然选择不给未来挖坑。