在做微服务的路上，拆分服务是个很热的话题。而然微服务拆分的过程，是基于某个痛点出发，是业务真正遇到快速迭代和高并发等问题，如果不拆分，将对于业务的发展带来影响，只有这个时候，微服务的拆分才是有确定收益的，增加的运维成本才是值得的。

互联网时代，业务快速变化，应用的交付需要快速响应式交付。通过微服务架构，采用快速迭代的方式进行架构演进，将系统拆分成多个独立的微服务，微服务之间彼此独立，通过服务接口交互。当某个微服务遇到问题时发版修复，不会导致整个系统不可用，从而支撑业务的快速试错。

单体应用开发通常是几十人开发一个系统，代码管理时经常会遇到代码提交冲突。微服务架构通过快速迭代可实现开发独立，将系统拆分成不同的微服务，每个微服务对外提供接口，其他依赖服务不用关注具体的实现细节，只需保证接口正确即可。每几个人维护一个服务模块，降低代码冲突的概率，出现冲突时也可快速解决。

传统模式单次上线的需求通常较多、风险较大，小功能的错误可能会导致大功能无法上线。因此每次上线都会带来较大的工作量。

微服务架构对于快速迭代可带来独立上线的效果。微服务拆分后，在服务接口稳定的情况下，不同的微服务可独立上线。上线的次数增多，单次上线的需求量变小，可随时回滚，风险变小，时间变短，影响面小，从而加快迭代速度。