“云时代架构”经典文章阅读感想七

（架构设计思维二——集成）

　　上周阅读了解了架构分解，有分解，就一定会有合成，因此这周进行阅读了解架构集合，

　　架构分解作为软件架构的关键，为架构设计提供重要的思路方法，但只是其中一步再分解之后再通过合适的方式进行合成。分解只是加速开发和降低问题的复杂度但是如果分解之后无法进行合成，那么分解就没有任何意义。

　　这学期因为正在修软件体系架构这门课程，因此需要对软件架构进行深部了解，老师上课经常说的就是要站在架构师的高度去看设计，在设计师不应该是用户需要什么就实现什么，而是应该站在架构师的高度进行挖掘隐性需求。当我们站在架构师的角度去看问题时，视野也会更加明朗，因此一个合格的架构师应该具备的基本修养便是着眼于高远。

架构设计的主要工作是：划分模块，定义模块功能，定义模块接口，定义模块间互相交互的数据结构，编写核心代码，编写衔接各个模块的代码。

“模块间互相交互的数据结构”区别于“模块内部的数据结构”，“模块内部的数据结构”和“模块内部的函数”都由负责这个模块的人自己设计，架构师不负责模块内部工作。

　　系统集成的工作是：划分模块，定义模块功能，编写核心代码（很多情况没有），编写衔接各个模块的代码（很多情况没有）。

　　系统集成的工作很多情况还没有“编写核心代码”和“编写衔接各个模块的代码”。系统集成的工作一定没有“定义模块接口”和“定义模块间互相交互的数据结构”，但这两个是最难最重要的工作，这就是架构设计和系统集成的主要区别。

　　系统集成是很简单的工作，大多数情况的工作就是“划分模块”和“定义模块功能”，完全不可与架构设计同日而语、相提并论。写过两三年代码的程序员都可很容易做系统集成。

　　SOA体系下，服务之间通过企业服务总线（Enterprise Service Bus）通信，许多业务逻辑在中间层（消息的路由、转换和组织）。

　　微服务架构倾向于降低中心消息总线（类似于ESB）的依赖，将业务逻辑分布在每个具体的服务终端。大部分微服务基于HTTP、JSON这样的标准协议，集成不同标准和格式变的不再重要。另外一个选择是采用轻量级的消息总线或者网关，有路由功能，没有复杂的业务逻辑。下面就介绍几种常见的架构方式。

集成的难点有哪些呢：分解时可以将系统分为各个功能，交付给不同的人完成，随着系统的增大，需要分解的模块单元越来越多。随着而来的问题便是：

数据服务的设计。因为分为了多个模块，在设计数据库是是应该设计为一个数据库还是多个数据库？

解决方法：一库一服or一库多服、混合持久化、数据一致性。

　　分解集成的架构设计方法仅仅是软件架构设计中的一种方法，在架构设计中还有许多其他的设计方法，在今后的学习中还是应该多阅读，多学习才能够好的提高自己。