上一篇阅读笔记简单说了一下架构设计中分解的问题，这次是说如何将分解完成的各个组件或子系统，通过恰当的方式，最终还可以集成为一个完整的整体，分解是加速开发和降低问题复杂度的便捷方法，如果分解之后无法集成，那么分解就没有意义。因此分解＋集成是架构最核心的思考方式和方法。
架构思维中的分解和集成是随着系统的演化进行演化，从单体架构到ESB为代表的SOA架构再到现在流行的微服务。移动互联网出现以后，各种各样的业务：共享单车、支付宝、微信支付等等，业务经历着飞速的变革与创新。
单体架构，Web应用程序发展的早期，在开发服务端企业应用时，应用需要支持各种不同类型的客户端，比如桌面浏览器、移动浏览器以及原生移动应用。应用还需要向第三方提供可访问的API，并通过Web Service或者消息代理与其它应用实现集成。大部分web工程是将所有的功能模块(service side)打包到一起并放在一个web容器中运行，很多企业的Java应用程序打包为war包。应用通过执行业务逻辑、访问数据库、与其它系统交换信息、并返回一条HTML/JSON/XML响应，来处理请求（HTTP请求与消息）。
应用采用多层架构或者六角架构，主要由以下几类不同组件构成：
展现组件——负责处理HTTP请求并响应HTML或者JSON/XML（对于web Services APIs）
业务逻辑——应用的业务逻辑
数据库访问逻辑——用于访问数据库的数据访问对象
不同逻辑组件分别响应应用中的不同功能模块。
SOA架构，SOA架构，是一种粗粒度、开放式、松耦合的服务结构，要求软件产品在开发过程中，按照相关的标准或协议，进行分层开发。通过这种分层设计或架构体系可以使软件产品变得更加弹性和灵活，且尽可能的与第三方软件产品互补兼容，以达到快速扩展，满足或响应市场或客户需求的多样化、多变性。
微服务架构，微服务是一种用于构建应用的架构方案。微服务架构有别于更为传统的单体式方案，可将应用拆分成多个核心功能。每个功能都被称为一项服务，可以单独构建和部署，这意味着各项服务在工作（和出现故障）时不会相互影响。是应用的各项核心功能，而且这些服务均可独立运行。但是，微服务架构不只是应用核心功能间的这种松散耦合，它还涉及重组开发团队、涉及如何进行服务间通信以应对不可避免的故障、满足未来的可扩展性并实现新的功能集成。
集成方式：点对点方式，网关方式，消息代理方式，
在微服务集成过程中，数据服务，事务，查询这些我们需要特别的处理，不像过去的单体架构，基于ESB的SOA架构一样，微服务遇到了之前不存在的问题，现在许多应用一个人无法完成，而且复杂到光靠一个人理解是不可能的，这种情况下，应用就必须拆分成一个个模块，在单体应用中，模块被定义为比方一个java package ,然而这种做法在实践中并不是很理想，时间长了，单体应用就会变得越来越庞大，微服务架构把服务作为一个模块单元，每个服务都有一个不可渗透且很难违反的边界，也就是每个微服务都要提供一种单独而独立的能力
总而言之，架构师每天的工作是不断的做取舍，不断的发掘一个合适的架构思路。架构思维真的很重要！