作者在这篇文章中讲了:架构设计思维-集成.作者按应用架构演变顺序先后将我们讲解了单体架构，SOA架构，微服务架构。
（1）单体架构是指：在Web应用程序发展的早期，在开发服务端企业应用时，应用需要支持各种不同类型的客户端，比如桌面浏览器、移动浏览器以及原生移动应用。应用还需要向第三方提供可访问的API，并通过Web Service或者消息代理与其它应用实现集成。大部分web工程是将所有的功能模块(service side)打包到一起并放在一个web容器中运行，很多企业的Java应用程序打包为war包。应用通过执行业务逻辑、访问数据库、与其它系统交换信息、并返回一条HTML/JSON/XML响应，来处理请求（HTTP请求与消息）。就是我们现在开发网站常用的架构。
（2）SOA架构：是一种粗粒度、开放式、松耦合的服务结构，要求软件产品在开发过程中，按照相关的标准或协议，进行分层开发。通过这种分层设计或架构体系可以使软件产品变得更加弹性和灵活，且尽可能的与第三方软件产品互补兼容，以达到快速扩展，满足或响应市场或客户需求的多样化、多变性。
（3）微服务架构：是一种用于构建应用的架构方案。微服务架构有别于更为传统的单体式方案，可将应用拆分成多个核心功能。每个功能都被称为一项服务，可以单独构建和部署，这意味着各项服务在工作（和出现故障）时不会相互影响。是应用的各项核心功能，而且这些服务均可独立运行。但是，微服务架构不只是应用核心功能间的这种松散耦合，它还涉及重组开发团队、涉及如何进行服务间通信以应对不可避免的故障、满足未来的可扩展性并实现新的功能集成。
架构的集成方式有：点对点方式，网关方式，消息代理方式。点对点方式中，服务之间直接用。每个微服务都开放REST API，并且调用其它微服务的接口。API网关方式的核心要点是，所有的客户端和消费端都通过统一的网关接入微服务，在网关层处理所有的非业务功能个。通常，网关也是提供REST/HTTP的访问API。服务端通过API-GW注册和管理服务。微服务也可以集成在异步的场景下，通过队列和订阅主题，实现消息的发布和订阅。一个微服务可以是消息的发布者，把消息通过异步的方式发送到队列或者订阅主题下。作为消费者的微服务可以从队列或者主题共获取消息。通过消息中间件把服务之间的直接调用解耦。
集成的难点有：数据库服务设计，数据一致性，分布式查询。
对于数据服务设计的难点有：用一库多服还是一库衣服。作者推荐的做法是，为每一个微服务准备一个单独的数据库，也即一库一服 (database per service) 模式。这种模式更加适合微服务架构 - 它满足每一个服务是独立开发、独立部署、独立扩展的特性。当需要对一个服务进行升级或者数据架构改动的时候，无须影响到其他的服务。需要对某个服务进行扩展的时候，也可以手术式的对某一个服务进行局部扩容。另外，如果某些服务对数据库有特殊的需求，这种模式也为下文所讲的混合持久化 (Polyglot Persistence) 提供了可能性。
对于数据库一致性的难题，一个传统的单体应用可以通过ACID事务来强制业务规则从而实现一致性。一种比较常见的做法就是使用分布式事务来搞定，比如2PC等，还有通过Event sourcing （事件源）。Event sourcing （事件源）通过使用根本不同的事件中心方式来获得不需2PC的原子性，保证业务实体的一致性。 这种应用保存业务实体一系列状态改变事件，而不是存储实体现在的状态。应用可以通过重放事件来重建实体现在状态。只要业务实体发生变化，新事件就会添加到时间表中。
对分布式查询的难，在传统的单体应用中，我们通常使用join来实现跨表查询。还有一种解决方案就是通过一种叫CQRS（Command Query Responsibility Segregation）做法来解决分布式查询问题。
看完这篇文章，我意识到架构师的工作就是每天做不断的取舍 ，做好各种利益之间的平衡，最后做出最有益于项目的决定。而了解好各种技术是做好取舍的基础。