架构思维中的分解和集成是随着系统的演化进行演化，从单体架构到ESB为代表的SOA架构再到现在流行的微服务，集成方式也从直接依赖到ESB为枢纽再到多种形式存在的微服务集成。
应用架构的演变
1.单体架构
Web应用程序发展的早期，在开发服务端企业应用时，应用需要支持各种不同类型的客户端，比如桌面浏览器、移动浏览器以及原生移动应用。应用还需要向第三方提供可访问的API，并通过Web Service或者消息代理与其它应用实现集成。大部分web工程是将所有的功能模块(service side)打包到一起并放在一个web容器中运行，很多企业的Java应用程序打包为war包。应用通过执行业务逻辑、访问数据库、与其它系统交换信息、并返回一条HTML/JSON/XML响应，来处理请求（HTTP请求与消息）。
2.SOA架构
SOA架构，是一种粗粒度、开放式、松耦合的服务结构，要求软件产品在开发过程中，按照相关的标准或协议，进行分层开发。通过这种分层设计或架构体系可以使软件产品变得更加弹性和灵活，且尽可能的与第三方软件产品互补兼容，以达到快速扩展，满足或响应市场或客户需求的多样化、多变性。
3.微服务架构
微服务是一种用于构建应用的架构方案。微服务架构有别于更为传统的单体式方案，可将应用拆分成多个核心功能。每个功能都被称为一项服务，可以单独构建和部署，这意味着各项服务在工作（和出现故障）时不会相互影响。是应用的各项核心功能，而且这些服务均可独立运行。但是，微服务架构不只是应用核心功能间的这种松散耦合，它还涉及重组开发团队、涉及如何进行服务间通信以应对不可避免的故障、满足未来的可扩展性并实现新的功能集成。
集成方式
SOA体系下，服务之间通过企业服务总线（Enterprise Service Bus）通信，许多业务逻辑在中间层（消息的路由、转换和组织）。
微服务架构倾向于降低中心消息总线（类似于ESB）的依赖，将业务逻辑分布在每个具体的服务终端。大部分微服务基于HTTP、JSON这样的标准协议，集成不同标准和格式变的不再重要。另外一个选择是采用轻量级的消息总线或者网关，有路由功能，没有复杂的业务逻辑。下面就介绍几种常见的架构方式。
1.点对点方式
点对点方式中，服务之间直接用。每个微服务都开放REST API，并且调用其它微服务的接口。
2.网关方式
API网关方式的核心要点是，所有的客户端和消费端都通过统一的网关接入微服务，在网关层处理所有的非业务功能个。通常，网关也是提供REST/HTTP的访问API。服务端通过API-GW注册和管理服务。
3.消息代理方式
微服务也可以集成在异步的场景下，通过队列和订阅主题，实现消息的发布和订阅。一个微服务可以是消息的发布者，把消息通过异步的方式发送到队列或者订阅主题下。作为消费者的微服务可以从队列或者主题共获取消息。通过消息中间件把服务之间的直接调用解耦。
原文地址：https://mp.weixin.qq.com/s?__biz=MzAwNTQ4MTQ4NQ==&mid=2453562428&idx=1&sn=32b7025abfa590dc2164b8e1749421fd&chksm=8cd1315ebba6b848312b28584d97aa52f68922aa23ffaa96e8a8d7a2f886051bb09fc96f90cf&mpshare=1&scene=23&srcid=#rd