在业务发展初期，应用规模比较小，基于JEE构建的垂直应用架构还能够有效支撑业务的发展。随着业务的不短发展，应用规模日趋庞大，传统垂直架构开发模式的弊端变得越来越突出。
1）复杂应用的开发维护成本变高，部署效率逐渐降低。因为随着业务功能的不断膨胀，代码全量编译和部署一次所需的时间非常长。更为严重的是只要某个功能编译出错或者功能测试出问题，就需要重新打包编译，软件的部署效率极地。
2）团队协作效率差，部分公共功能重复开发，代码重复率居高不下。随着业务的发展，团队规模不断扩大，研发被打散到不同的开发小组中。不同的功能模块可能会依赖一些公共能力组件，由于没有类似服务化这种技术契约约束，很难在不同团队间实现wu无缝沟通和共享，加之公共能力都是些本地API实现，这就导致公共API被重复开发，不能在团队间有效重用，这会导致编写大量的重复代码。
3）系统可靠性变差。随着业务的发展，访问量逐渐攀升，网络流量、负载均衡、数据库连接等都面临着巨大的压力。某个借点的故障会导致分摊到其他节点的流量陡增，引起“雪崩效应”，高并发、大流量对系统的可靠性要求非常高。垂直家规将所有的应用模块都部署到一个进程中，如果某个应用接口发生故障，例如内存泄漏，会导致整个节点宕机。由于是对等集群部署，这就意味着其他节点也有类似的问题，宕机可能会此起彼伏，严重影响业务的正常运行。
4）维护和定制困难。由于业务代码不断膨胀，功能越来越复杂，已有垂直架构模式下无法对复杂的业务进行拆分，代码修改牵一发而动全身，维护和定制都非常困难。
5）新功能上线周期变长。主要有两个原因导致交付效率下降。（1）公共API变更导致测试工作量激增。前面已经介绍过垂直架构存在大量的重复代码，当某个被重复开发的公共API发生变更后，会导致多处代码需要重复修改，重复测试，这会引入大量的回归测试工作量；（2）新特性无法独立部署和交付。新功能需要跟其他老功能一起编译、打包和测试，如果测试出bug，整个系统需要重新打包和部署，这种强耦合会导致整个交付效率下降。究其根本是传统的垂直架构无法做到按照服务或者特性独立交付和运维。
当垂直引用越来越多，应用之间交互不可避免，将核心业务抽取出来，作为独立的服务，逐渐形成稳定的服务中心，使前端应用能更快速的响应多变吧的市场需求。同时将公共能力API抽取出来，作为独立的公共服务供其他调用者消费，以实现服务的共享和重用，降低开发和运维成本。应用拆分之后会按照模块独立部署，接口调用由本地API演进成跨进程的远程方法调用，此时RPC框架应运而生。
以上内容出自《分布式服务框架原理与实践》