这是一道高频的面试题，下面，我们一起来看看如何回答会更好。
首先，微服务架构并非就一定比单体架构好，我一直反对这种没有独立思考的人云亦云的答案，每种架构都有其适用场景。
第一，我们来看看单体架构适用的场景
单体架构特别适合初创公司的初创项目，可以小成本快速试错，且系统模块之间的调用，是进程内的通信，所以整体的性能表现会非常好，所以这类型的项目，我推荐采用单体架构足以，在市场还没有打开之前，采用各类看似高大上的技术，除非是为了卖弄技术，否则毫无意义。
做产品，需要考虑MVP模式，架构除了考虑技术，更应该考虑成本，成本意识是很关键的。
第二，我们来看看，微服务架构适合的场景
当系统经过一段时间的运营之后，如果运气不错，用户量有了一定的增量，业务也随着市场需求有了扩展，从而慢慢的整个系统的业务变得复杂而庞大，这个时候一个系统的启动时间，重新编译的时间，都可能会非常耗时，一个功能的修改也需要做全盘的回归测试，所谓牵一发而动全身，这个时候就适合对系统进行服务拆分，拆分成多个服务子系统，每个子系统可以更灵活做升级。注意！此时原先的模块之间的通信，由原先的进程内通信变为进程间的通信，所以其响应速度会有所影响。
第三，我们再来看看，微服务拆分的原则
一般我们根据业务的边界来拆分，比如按照商品，购物车，订单等等业务边界进行服务的拆分，另外一个，系统中存在的共性基础服务，比如像短信，邮件，日志等等，我们也可以作为单独的服务进行拆分，作为基础服务层供上层服务复用。
好了，今天的面试题分享就说到你，希望对你有所帮助！
