您可以捐助,支持我们的公益事业。

1元 10元 50元





认证码:  验证码,看不清楚?请点击刷新验证码 必填



  求知 文章 文库 Lib 视频 iPerson 课程 认证 咨询 工具 讲座 Model Center   Code  
会员   
   
 
     
   
 订阅
  捐助
微服务的集成架构设计
 
  7811  次浏览      16
 2019-5-27
 
编辑推荐:
本文来自于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服务文档框架

消息发布和订阅客户端

下图展示了开发集成框架时的部分技术选型,供读者参考

   
7811 次浏览       16
相关文章

企业架构、TOGAF与ArchiMate概览
架构师之路-如何做好业务建模?
大型网站电商网站架构案例和技术架构的示例
完整的Archimate视点指南(包括示例)
相关文档

数据中台技术架构方法论与实践
适用ArchiMate、EA 和 iSpace进行企业架构建模
Zachman企业架构框架简介
企业架构让SOA落地
相关课程

云平台与微服务架构设计
中台战略、中台建设与数字商业
亿级用户高并发、高可用系统架构
高可用分布式架构设计与实践