单体应用
单体应用整个项目代码都在同一个应用工程中，这种方式在早期可以有效提高开发效率，测试、部署和运维也比较方便。少量的开发人员就可以完成所有工作。然而随着业务规模、数据量的不断扩大，单体应用就会出现问题，
- 部署测试效率低下：每次修改了代码需要进行测试验证时必须将整个应用进行编译、打包以及部署，耗费大量时间；
- 后期维护和迭代时开发难度大：单体应用的所有代码都在同一应用中，进行迭代时新需求涉及的代码可能遍布在应用的各个地方，进行改动时就要求开发人员对整个项目的代码结构，整体架构和业务有充分的了解，否则就可能导致开发效率低下，变更时遗漏一些关联业务处理的问题。
- 线上系统可用性：单体应用所有功能最后都打包在一个 war 包中，运行在同一个 tomcat 进程中，一旦某一功能涉及的代码或资源有问题，就会影响到项目中其他的功能，一个功能出错就可能让整个服务不可用。
服务化
服务化把传统的单机应用通过 jar 包依赖产生的本地调用改造成 RPC 接口远程方法调用，在编写业务代码时，可将一些具有通用性的功能抽离为独立的模块，进行复用；一些具有关联的业务也可抽离为单独的服务， 这对于代码复用和业务理解都有很大的益处；这样，服务可以进行独立部署，不同的服务可交由专门的团队负责，解决团队开发耦合度高，协作效率低下的问题；后期业务膨胀时也能更有效的进行控制。
应用服务化也带来了一些问题
服务间协作时依赖关系复杂
随着而来的问题是无法做到一个服务因变更进行打包部署时只需要操作该服务，因为服务间的依赖关系，一个服务重新打包部署时如果对外暴露的 api 部分有变更，则依赖到该服务的其他服务也需要重新进行打包部署，往往网关应用也需要重新打包部署。
解决方式为在早期划分服务时需要充分考虑各个服务间可能出现的依赖关系，划分服务时理清该服务需要提供哪些核心功能，确保这些功能有一定关联性，能共同完成特定领域的业务，同时还要考虑服务可能依赖到的其他领域的数据，思考这些数据是否可以归到当前服务中，或明显属于另一个领域业务的数据。
开发过程中 debug 和测试难度增加，操作繁琐
服务化后同一系统的多个服务间会出现依赖关系，在开发过程中当某一服务的代码开发完成，需要进行 debug 或测试时，需要考虑当前服务所依赖到的其他服务是否也有变更，要求这些服务都处于可用状态，且代码状态需与当前模块开发时相关 Api 被期望提供的输出保持一致。这也就导致一个服务的变更往往需要对关联服务进行确认，从而导致测试难度提升以及繁琐的操作。
导致这个问题的一部分原因是第一个问题中提到的服务间协作依赖关系复杂，各个服务明确自己的职责，降低与其他服务的耦合，这个问题也就能得到改善。