微服务的集成架构设计

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

    在接手集成框架的设计工做之后，笔者先研究了什么样的集成模式更加符合微服务的架构思想。在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服务文档框架
• 消息发布和订阅客户端