单体应用随着时间的推移和反复的迭代开发，往往会进化成一个大泥球结构。在这种结构下，各个模块关系繁杂且牵一发而动全身，严重影响应用的可维护性、可扩展性和可测试性。针对日益庞杂的单体应用，应用的垂直拆分是一种必然选择。而应用拆分之后，则从单体架构演变成分布式架构。一个经典的分布式架构的部署图如下：
为了应对日益复杂的业务场景，根据业务场景拆分整个应用是一种合理的选择。这样，整个业务分成不同的产品线，如交易系统可将首页、卖家、卖家、订单等拆分成不同的产品线，分归不同的业务团队负责。拆分后，每个产品线维护的应用独立部署维护，各子应用之间通过消息队列等进行数据通信。随着业务拆分越来越小，存储系统越来越庞大。为避免所有应用都和数据库连接，导致数据库连接池资源不足，针对可复用的业务连接数据库，提供公用业务服务。针对其他公共业务，也抽取相关服务。如认证鉴权服务、NoSQL数据库读写服务、缓存读写服务等等。
SOA
在分布式架构的演进中，SOA(Service Oriented Architecture，面向服务的架构)获得一部分技术厂商的青睐。SOA 是一种在计算环境中设计、开发、部署和管理离散逻辑单元（服务）模型的方法。 SOA 并不是一个新鲜事物，而只是面向对象模型的一种替代。虽然基于 SOA 的系统并不排除使用 OOD 来构建单个服务，但是其整体设计却是面向服务的。由于 SOA 考虑到了系统内的对象，所以虽然SOA 是基于对象的，但是作为一个整体，它却不是面向对象的。一个经典的SOA架构的部署图如下：
SOA架构遇到的一个问题是，服务拆分后，如何对外统一提供服务。API Gateway是一种解决策略，API Gateway是外部世界进入应用的入口。它负责请求路由、API组合和身份验证等多项功能。来自外部的所有API请求先转到API Gateway，然后API Gateway再将请求路由到相应的服务。
SOA中的每个服务都包含执行完整的独立业务功能(如用户鉴权、订单、购物车、交易等)所需的代码和数据集成。这些服务接口提供松耦合能力，这意味着，即使基本或根本不知道服务如何在底层集成，也可以调用服务公开的接口。
在SOA架构中使用服务总线连接各服务。ESB（企业服务总线）是一种模式，集中式组件可通过这种模式执行与后端系统的集成，然后将这些集成作为服务接口提供。ESB是一个智能管线，它会转换数据模型、深度连接、路由机制以及组合多个请求，并将它们作为单个服务接口提供，以供新应用程序复用。从理论上讲，开发者可以在不使用 ESB 的情况下实施 SOA，但每个应用程序所有者都必须通过自己独有的方式来公开服务接口，这就需要完成大量工作（即使接口最终可复用也不例外），并且在未来会带来巨大的维护挑战。 实际上，ESB 最终被认为是所有 SOA 实施都包含的事实元素，以致于有时将这两个术语作为同义词使用，从而造成了混乱。
微服务架构
