转载

微服务的集成架构设计

编辑推荐:

本文来自于cnblogs，本文介绍微服务集成框架的模式，开发集成框架时的部分技术选型等相关内容。

微服务集成框架的模式

微服务已经在架构界流行起来了，但在实践中，难免需要利用其它软件厂商系统的能力，同时也没有办法一步到位把企业内的所有系统都改造成微服务架构的系统，所以系统集成仍然是一个非常重要的问题。在笔者项目的早期阶段，集成是由微服务系统的组件直接对接其它系统处理的，这种方式点对点的集成方式造成了系统和被集成系统的强耦合，影响了微服务系统的进一步发展。

在接手集成框架的设计工作以后，笔者先研究了什么样的集成模式更加符合微服务的架构思想。在Martin Fowler的文章中提到，微服务架构的特征之一是“智能的端点，愚蠢的管道”。作为参照，ESB是智能管道的典型代表，ESB产品通常包括复杂的基础设施，支持消息路由、编排、转换和应用业务规则。在实践中，ESB本身会逐渐发展为系统中一个复杂的单块应用；同时，这也于尽量解耦、内聚的微服务架构思想相左。因此，微服务团队在解决问题时，倡议使用REST API和轻量级消息系统实现系统集成。其中，消息系统仅提供可靠的异步消息传输通道，而不参与消息路由、编排、转换等环节，也不在消息系统中包含业务逻辑。在各种消息通信模式中，事件驱动模式因其完全解耦、高度容错的特性受到了微服务架构系统的欢迎。事件驱动消息系统的中心是一个不做消息路由、编排或者转换的Message Broker，Apache Kafka是很好的选择。

考虑到将要和微服务系统集成的三方系统通常都不符合微服务的架构，同时也不一定支持使用REST API或微服务系统选型的Message Broker。笔者设计集成框架的基本思想是使用Adapter设计模式，为将要集成的每一个三方系统构建一个集成服务。集成服务对外包装所有和三方系统的同步异步交互，对内遵循微服务系统的规范，可以作为一个服务组件部署在当前微服务环境中。注意集成服务是针对每个三方系统独立开发的，每个集成服务都是微服务的Component，都可以独立部署。要避免一个集成服务面对多个三方系统，变成一个单块的集成平台。

微服务的集成架构设计

微服务集成框架的设计和实现

微服务集成架构选则了通用性很强的REST、Kafka、Json格式消息作为标准，只需遵循约定的REST接口和消息定义，集成服务的开发者可以选用自己熟悉的语言、框架来编写。为了能加速集成服务的开发，笔者在定义了微服务集成模式之后，又设计并开发了Java技术栈的微服务集成框架。集成框架提供了和微服务系统内组件同步、异步通信所需要的基础能力，框架的组成主要包括：

服务注册发现服务

Message Broker服务

微服务集成基础Jar包

微服务集成基础Jar包中包括

项目骨架工程框架

异常框架

日志框架

统一配置框架

服务注册和发现客户端

服务封装和访问框架

REST服务文档框架

消息发布和订阅客户端