All-In-One 架构

All-In-One是以前企业级应用最常见的做法，把大量业务了逻辑功能堆积到一个单体架构中。对于初创企业或者时间仓促的项目，初期的开发效率很高，但随之而来，应用随时间推移越来越大，业务逻辑日益复杂。在日后想要进行快速迭代，是很困难的，动一发而牵全身。同时，以这样的单体架构运行，由于提供了大量的业务功能，随着功能的升级，整个研发、发布、定位问题，扩展，升级这样一个“怪物”系统会变得越来越困难。

All-In-One架构的应用一般有以下特点：

设计、开发、部署为一个单独的单元。
会变得越来越复杂，最后导致维护、升级、新增功能变得异常困难
很难以敏捷研发模式进行开发和发布
部分更新，都需要重新部署整个应用
水平扩展：必须以应用为单位进行扩展，在资源需求有冲突时扩展变得比较困难（部分服务需要更多的计算资源，部分需要更多内存资源）
可用性：一个服务的不稳定会导致整个应用出问题
创新困难：很难引入新的技术和框架，所有的功能都构建在同质的框架之上

All-In-One往SOA的演变

SOA 架构

SOA的思路是把应用中相近的业务逻辑功能聚合到一起，以服务的形式提供出去。因此基于SOA架构的应用可以理解为一批服务的组合。SOA带来的问题是，引入了大量的服务、消息格式定义和规范(RMI,SOAP等)。各层级接口服务，还存在相互调用等复杂逻辑关系，随业务的飞速增长，没人想去做这个接盘侠

使用SOA架构，用ESB对外提供服务

百度百科解析:

企业服务总线（EnterpriseServiceBus，ESB）从面向服务体系架构（Service-OrientedArchitecture，SOA）发展而来，是传统中间件技术与XML、Web服务等技术结合的产物。
ESB的出现改变了传统的软件架构，可以提供比传统中间件产品更为低廉的解决方案，同时它还可以消除不同应用之间的技术差异，让不同的应用服务器协调运作，实现了不同服务之间的通信与整合。从功能上看，ESB提供了事件驱动和文档导向的处理模式，以及分布式的运行管理机制，它支持基于内容的路由和过滤，具备了复杂数据的传输能力，并可以提供一系列的标准接口。

自此，调用者无需理会服务所需在的url以及通信传输协议，通过一种约定好的传输协议与总线进行通信，即可调用对应的服务，总线会找到对应的服务，调用并返回给调用者

进化，微服务

微服务架构的核心思想是，一个应用是由多个小的、相互独立的、微服务组成，这些服务运行在自己的进程中，开发和发布都没有依赖。
微服务强调的是，彻底组件化和服务化,将原有的业务系统拆分为多个独立开发，运行，维护的小应用，这些小服务除了本身业务功能外，还需要消费外部其他小应用提供的服务，自身也提供对外服务。

用一句话来区别SOA和微服务，即微服务不再强调传统SOA架构里面比较重的ESB企业服务总线，实现去中心化，同时SOA的思想进入到单个业务系统内部实现真正的组件化。

单个模块的逻辑层即需要消费外部通用服务层，也对外提供业务服务功能。
基于这样的思想，业务经过分析拆分后，围绕着业务来创建应用，这些应用就可以独立、并行地进行开发、管理。分散的应用在部署上可以按需分配，应用功能上线交付更简单，资源利用更合理。

参考引用

SOA和微服务架构的区别？
「Chris Richardson 微服务系列」服务发现的可行方案以及实践案例
SOA与微服务的比较和对比
微服务实战：从架构到发布（一）
微服务实战：从架构到发布（二）

All-In-One -> SOA -> 微服务