演进式架构：微服务设计好坏看能否轻松持续重组，而非拆了多少个

很多人在做微服务设计时，会把”应该把单体拆成多少个微服务”当作设计重点，但这其实是一个误区。Martin Fowler提出微服务时提到过一个重要特征——演进式架构，它以支持增量的、非破坏性的变更作为第一原则，同时支持应用程序结构层面的多维度变化。判断一次微服务设计是否合理的方法很简单：随着业务发展或需求变更，当领域模型和微服务需要被重新拆分、或者被重新组合成新的微服务时，这个过程是否会大幅增加软件开发和维护成本——如果这个演进过程能够轻松、简单地完成，就说明设计是合理的；反之，如果每次业务模式发生大变化都要推倒重做，说明这次设计从一开始就没有把”未来会变化”这件事考虑进去。这条判断标准提醒：微服务设计的目标从来不是”当下这一刻拆得对不对”，而是”未来需要再拆或再合的时候，代价高不高”——一次微服务设计如果只优化了”现在看起来边界清晰”，却没有为将来必然发生的重组预留余地，本质上只是把问题推迟，而不是真正解决了问题。