下载掌阅APP，畅读海量书库
立即打开
MVC模式构建的垂直应用非常适合项目初期，使用其能够方便地进行开发、部署、测试，但随着业务的发展与访问量的增加，垂直应用的问题也随之暴露出来，而微服务架构可以很好地解决这些问题。
垂直应用里，大部分逻辑都部署在一个集中化、单一的环境或服务器中运行。垂直应用程序通常很大，由一个大型团队或多个团队维护。庞大的代码库可能给希望熟悉代码的开发人员增加学习成本，还会让应用程序开发过程中使用的开发环境工具和运行容器不堪重负，最终导致开发效率降低，可能会阻止对执行更改的尝试。
微服务架构将这个庞大并且复杂的应用拆分成多个逻辑简单且独立的小应用，每个小应用交由不同的团队或开发人员维护，彼此之间互不干扰，通过标准接口互相通信。对于希望熟悉代码的开发人员来说只需掌握他所负责的应用即可，这样做的好处是简单、快速、逻辑清晰。
垂直应用需要处理一个庞大的应用程序，编译、部署需要花费很长时间，一个小的修改就可能导致重新构建整个项目。
微服务架构中对其中某一个服务进行修改，只需重新编译、部署被改动的服务模块。
垂直应用里，当请求量过大导致单台服务器无法支撑时，一般会将垂直应用部署在多台服务器形成服务集群，并通过反向代理实现负载均衡。集群中的每个服务必须部署完整的应用，但在实际业务需求中仅有部分功能使用频繁，但这种架构必须为不常用的功能分配计算资源。
微服务将提供功能的各服务拆分为多个服务模块，它具有天生的集群属性，能够轻松地根据用量部署。
例如系统中的消息功能使用频率占了整个系统的90%，而密码找回功能则只占到2%。为了分解消息功能的压力，以传统负载均衡的方式进行集群化时，每个服务必须为使用量只有2%的密码找回功能分配资源，这无疑造成了浪费。
在微服务架构中，消息功能使用率占据90%，则将消息模块多部署几个实例形成集群，而密码找回功能所在的用户模块只部署一个就可以了。
垂直应用中如果有一个小的问题，就可能使整个系统崩溃。
微服务所拆分出的各个模块中，由于模块之间的耦合度很低，当发生问题时影响范围被固定在该模块本身，整个系统依然健全。