在阅读完上篇架构设计的分解篇之后，今天又阅读完《架构设计思维-集成》，原文地址：https://mp.weixin.qq.com/s/f1ZlEpvbnox_re14ceCgFQ。
分解的目的是加速开发和降低问题的复杂度，但是如果分解后的内容无法集成在一起，那么分解的存在则是没有意义的。分解+集成联合应用，可以
看为架构最核心的思考方式和方法。架构思维中的分解与集成是随着系统的演化而进行的，集成方式从一开始的直接依赖到ESB为枢纽再到多种形式存在
的微服务集成，接下来就是集中架构的简介。
一、单体架构
它主要应用在web应用程序发展的早期，在开发服务端企业应用时，应用还需向第三方提供可访问的API，并通过web service或者消息代理与其他应用实现集成。
应用采用多层架构或者六角架构，主要由以下几类不同组件构成：展现组件--负责处理HTTP请求并响应HTML或者JSON、XML。业务逻辑--应用的业务逻辑。数据库
访问逻辑--用于访问数据库的数据访问对象，不同逻辑组件分别响应应用中的不同的功能模块。
缺点：1.单体应用的巨大的代码库会使人望而生畏，特别是对于团队中的新成员来说。2.过载的IDE--代码库越大，web容器启动时间越长，极大影响到开发者的生产效率。
4.持续部署困难--巨大的大单体应用本身就是频繁部署的一大障碍。为了更新某个组件，必须重新部署整个应用。5.应用扩展困难--单体架构只能进行一维伸缩。6.难于进行规模
化开发--单一应用是规模化开发的的障碍。
二、SOA架构
SOA架构，是一种粗粒度、开放式、松耦合的服务结构，要求软件产品在开发过程中，按照相关的标准，进行分层开发。通过这种分层设计或架构体系可以使软件产品变得更加弹
性和灵活，且尽可能的与第三方软件产品互补兼容。
SOA架构的缺点：1.可靠性;SOA还没有完全为事务的最高可靠性--不可否认性、消息一定会被传送且仅被传送一次以及事务撤回做好准备。2.安全性：在过去，访问控制只需要登录和
验证；而在SOA环境中，由于一个应用软件的组件很容易去与属于不同领域的其他组件进行对话，所以安全性就变得复杂多了。3.编排：统一协调分布式软件组件以便构建有意义的业务流
程是最复杂的，但它同时也最适合面向服务类型的集成。原因是，建立在SOA上的应用软件被设计成可以按需要拆散、重新组装的服务。3.遗留系统处理。SOA中提供集成遗留系统的适配器，
遗留应用适配器屏蔽了许多占用性API的复杂性和晦涩性。5.语义：定义事务和数据的业务含义，一直是开发面临的最棘手的问题。
三、微服务架构
微服务架构是一种用于构建应用的架构方案。微服务架构有别于更为传统的单体式方案，可将应用拆分为多个核心功能。每个功能都被称为一项服务，可以单独构建和部署，这意味着各项服务在
工作时不会相互影响。
使用微服务架构的挑战:1.构建:必须花时间明确各个服务间的依赖关系。2.测试：集成测试和端到端的测试可能会前所未有的难以实施，但却更加重要。3.版本管理：在更新版本时，要记住向后兼容性
可能会因更新操作而失效。4.部署：这是在首次设置时的一大挑战。5.日志记录：使用分布式系统时，您需要利用集中式日志将所有相关信息集中到一处。6.监控：必须通过一个集中式视图来了解整个系
统的情况。7.调试:无法进行远程调试，因为这种方式无法涵盖数十个或数百个服务。8.连接：考虑使用服务探索功能。
集成方式
SOA体系下，服务之间通过ESB通信，许多业务逻辑在中间层。微服务架构倾向于降低中心消息总线的依赖，将业务逻辑分布在每个局具体的服务终端。大部分微服务基于HTTP、JSON这样的协议标准，
集成不同标准和格式变得不再重要。另外的选择是采用轻量基金的消息总线或者网关，有路由功能，没有复杂的业务逻辑。以下是集中产检的架构方式：
一、点对点方式：在点对点方式中，服务之间直接用。每个微服务都开放REST API，并且调用其他微服务的接口。二、网关方式：该方式是微服务架构中应用最广泛的设计模式。它的核心要点是所有的客户端
和消费端都通过统一的网关接入微服务，在网关层处理所有的非业务功能个。三、消息代理模式：微服务也可以集成在异步的场景下，通过队列和订阅主题，实现消息的发布和订阅。
微服务架构确实好用，但是在应用过程中也发现了其中的几个问题，如数据服务设计、数据一致性、分布式查询等，需要我们在实践中解决。