单体架构与微服务架构的比较，以及服务拆分的原则。

首先，单体架构不一定比微服务架构更好，各自有其适用的场景。

单体架构适合用户量少、业务简单的初创项目，可以小成本快速试错。且由于系统模块之间的调用是进程内通信，系统整体性能表现更好。

系统经过一段时间的运营后，随着用户量扩大，业务类型扩展，整个系统的业务量会变的复杂而庞大。这时系统的启动时间、重新编译时间都会非常耗时，且系统某个位置出现异常可能会导致整个系统崩溃，所谓牵一发而动全身。对一个功能的修复也需要做全盘的回归测试，并且要重新部署整个应用，使得系统的变更非常不灵活。这时候更适合使用微服务架构，将单体系统拆分为多个服务子系统，每个子系统可以独立地开发、升级维护和部署，各子系统结合业务及团队特点选择适合的技术栈，灵活性更高。但是系统模块间通信，从进程内通信变成进程间通信，所以系统响应速度会受到影响。

服务拆分的原则：一般按照业务边界来拆分。比如订单管理服务、日志管理服务、商品管理服务等。