系统集成的技术演进

简介: 系统集成的各种技术方案介绍和对比

系统集成是一个历史悠久的话题,一般会存在两种类型的集成方式:

  • 数据集成
  • 产品集成


数据集成就是让各个系统间的数据能够互通,数据互通也存在两种方式:

  • 系统A将数据推送给系统B
  • 系统A查询系统B的数据

下面以一个案例来说明不同系统数据集成的技术演进方式。假设现在有三个系统:

  • 系统A:专注于审批业务
  • 系统B:专注于销售业务
  • 系统C:专注于财务业务

客户的业务场景如下:


从上面的业务场景可以看出三个系统需要通过协作完成一项客户业务链路的闭环,完成这样的业务链路闭环有三种解法:

  • 第一种方式是客户线下在各个系统间录入数据,从而把业务流程串联起来。例如客户在系统B录入的销售信息和工程信息,然后在在系统A中提交审批,当审批通过后在系统C中录入相关的工程财务成本数据,从而进入下面的财务的业务流程
  • 第二种方式是各个系统间的数据进行集成。例如系统B中录入执行单据后会将该数据推送到A系统从而自动提交审批,当审批通过后系统A会将通过信息推送到系统C,系统C查询系统B的工程数据后自动录入本系统,从而执行后续的财务链路
  • 第三种方式是各个系统进行产品集成。产品集成的前提是系统间已经进行了数据集成,例如开发一个系统D来承载系统A、B、C的界面,这样在一个系统D中就可以完成业务的链路闭环,不用在各个系统中进行跳转。


显然第一种方式用户体验非常差,第三种方式用户体验会很好但是会带来比较大的系统改造和复杂度,因此在这里我们只关注在第二种方式数据集成上。




针对上面的客户诉求,如果通过数据集成那么最简单的方式是各个系统之间进行点到点的对接,例如:

点对点的对接方式看起来比较简单但是也会存在一些问题。例如系统B在调用系统A的时候可能会存在调用失败,如何进行失败重试,如何记录调用过程以便进行问题排查以及手工重试,如何统计调用失败情况和调用耗时等。如果通过点对点的方式那么任何一个系统都需要自行完成这些链路的调用统计和失败策略,但是很显然这些功能在各个系统上都是大同小异的,如果有一个统一的系统来处理那么将大大简化系统间的调用。


经过改良后的系统间对接链路如下:

任何系统间的调用都通过连接平台进行转发,这样连接平台可以进行调用链路记录和问题排查以及失败重试等,从而简化了各个系统之间的对接流程。


如果系统B调用系统A只是从直接调用变成了通过连接平台来转发调用,那么还会存在下面的问题:系统B调用系统A的数据是需要符合系统A的接口规范,如果客户的审批系统使用了另一套产品那么系统B需要再次对接一套审批系统接口。对于M+N个系统点对点对接的时候是需要M*N个系统间适配的。

针对上面的问题,钉钉连接平台侧可以通过配置连接器来解决,在介绍解决方案之前先介绍一下连接器连接器是系统数据集成的一种实现方式,一般来说一个系统会对应一个或多个连接器连接器下可以创建触发器执行动作


所谓触发器是当某件事情发生的时候(这里的发生可以是用户的操作行为例如点击某个按钮,也可以是系统业务逻辑例如当收到邮件的时候,还可以是轮询每隔一段时间触发等等),能够通过触发器来触发相应的动作从而执行后续的行为。例如当用户在系统A的某个表单填入数据后点击提交,这时候可以通过触发器把表单提交的数据推送出去从而被系统B消费。


执行动作表示的是执行的业务行为,可以是接收外部系统的数据,也可以是提供数据给外部系统。

对于系统B调用系统A的链路来说,系统B的工作是在连接平台注册一个触发器,系统A的工作是在连接平台上注册一个执行动作:

对于系统B来说其工作为:

  • 推送数据
  • 在连接平台定义推送数据的模型MB

对于系统A来说其工作为:

  • 在连接平台定义接收数据模型MA
  • 接收数据

对于系统B来说只管往连接平台推送数据模型为MB的数据即可,不需要关心系统A(也可以是系统C、系统D等等)如何获取这份数据;对于系统A(也可以是系统C、系统D等等,只要订阅了模型MB的数据)来说只管接收从连接平台推送过来的数据模型为MA的数据即可,无需关心这份数据从哪里来。


那数据是怎么从系统B到达系统A的?数据要想在各个系统之间流转,那么需要把推送的数据和接收的数据连接起来行程一个连接对,例如:

在连接的同时提供从模型MB到模型MA的转换映射即可。


上面的链路解决了系统B不需要关心系统A的接口数据模型的问题,但是其仍然没有解决M+N个系统间对接需要M*N次配置的问题,如果要解决这个问题那么需要定义一个统一的领域数据模型:

对于系统B来说其工作为:

  • 推送数据
  • 在连接平台定义推送数据的模型MB
  • 在连接平台配置模型转换MB->M

对于系统A来说其工作为:

  • 在连接平台定义接收数据模型MA
  • 在连接平台配置模型转换M->MA
  • 接收数据

对于连接平台来说其工作为:

  • 定义统一模型M,让各个应用方都Follow这个模型标准,从而实现互通


通过上面的方式对于M+N个系统之间的连接只需要M+N个触发器和执行动作即可,大大降低了对接的个数;但是如何定义这里的统一模型M是十分关键的,这需要具有相当深的领域基础来统一各个系统的通用的领域模型。一般来说在前期对应的统一模型M是会不停迭代修改的,但是随着接入的系统越来越多这个模型M会越来越趋于稳定,最终会变成对应领域的模型规范。


至此已经介绍了系统间进行数据集成几种演进方式,你们的业务系统中数据集成使用的是哪种方式呢?

相关文章
|
1月前
|
存储 资源调度 运维
未来云平台的演进与挑战
随着数字化转型的加速推进,云计算作为基础设施的重要性日益凸显。未来云平台将面临诸多挑战,包括安全性、可靠性、弹性等方面的提升需求。本文将探讨未来云平台的发展趋势,分析其面临的挑战,并提出应对之策。
13 2
|
4月前
|
Kubernetes Cloud Native 持续交付
探索云原生时代:技术驱动的业务架构革新
探索云原生时代:技术驱动的业务架构革新
100 0
|
6月前
|
Web App开发 人工智能 Linux
开源数字孪生基础设施
开源数字孪生基础设施
95 0
|
7月前
|
安全 数据安全/隐私保护
安全体系与支撑基座的融合建设实践(二)
安全体系与支撑基座的融合建设实践(二)
53 0
|
7月前
|
安全
安全体系与支撑基座的融合建设实践(三)
安全体系与支撑基座的融合建设实践(三)
76 0
|
7月前
|
安全 数据安全/隐私保护 网络虚拟化
安全体系与支撑基座的融合建设实践(一)
安全体系与支撑基座的融合建设实践(一)
62 1
|
11月前
|
存储 供应链 安全
【企业技术架构】企业自动化是下一代架构吗?
【企业技术架构】企业自动化是下一代架构吗?
|
存储 安全 小程序
DaaS架构及落地 (一)
DaaS 数据即服务是一种服务模式,即将数据以服务的形式,向客户提供价值,参与到客户的业务中,它也是软件即服务的一种细分领域。同时DaaS 拥有云计算的通用特点,包括以租代买,按需付费、按用付费。 本文介绍 DaaS 的架构及实现选择,对于拥有大量优质数据资源的企业,可以参考构建起数据业务线,进而实现数据的资产化、价值化。需要说明的是本文中的各种图例仅是逻辑示意,均做了简化。
830 1
DaaS架构及落地 (一)
|
存储 运维 Kubernetes
从规模化平台工程实践,我们学到了什么?
本文尝试从平台工程、专用语言、分治、建模、自动化和协同文化等几个角度阐述规模化平台工程实践中的挑战和最佳实践。希望通过把我们平台工程的理念和实践分享给更多企业和团队,一起让一些有意思的变化发生。
|
存储 JSON 前端开发
如何设计支持快速交付的技术中台战略?
快速交付的技术中台的设计原则
333 0
如何设计支持快速交付的技术中台战略?