一个服务还是多个：什么时候拆

为什么单体不是脏话

一个系统更容易部署、调试，也更容易做跨领域的改动。大多数过早拆分的项目，在还没得到任何好处之前，就先付了拆分的全部代价——网络、版本、分布式监控、一致性。

到时候了的信号

因为团队互相等待而卡住的发布；资源需求完全不同的组件；需要单独可用性级别或单独合规要求的部分；不同区域之间变更节奏差异很大。

不够充分的信号：「因为现在都这么建」。

怎么拆才对

按业务边界拆，而不是按技术分层拆。每个服务持有自己的数据，不去调用别人的数据库。通过明确的契约通信，能用事件的地方就不用同步调用。

拆之前，先确认这些边界在单体内部就能立住：分离良好的模块是一次便宜的彩排。