通用接口开放平台设计与实现——(1)开篇

首先简单聊下背景,大概是几年前,工作中遇到这么一个复杂的应用场景,大型企业中的物流系统,需要跟众多的内外部系统交互,对接的系统达到十几个,接口数量在50个左右,并且后续还会大量增加新的对接方,并且很多对接方是类似的,例如跟汽运物流厂商的运输管理系统TMS,进行运输委托、运力反馈、运费结算、签收回传等交互。

如何还是按照传统模式去做点对点集成,会消耗大量成本,包括时间和费用,并且上线后还会搭上大量的运维成本。同时,伴随的问题,当业务发生变更时,接口的升级更新,也是大麻烦,往往涉及到多方协调、开发、联调、上线。

基于这个背景,思考一种优雅的解决方案,能低成本、高效率解决这个难题。

最终思路是实现一套物流系统的接口开放平台,由平台对外提供一套标准的Rest风格的API服务作为服务接口,相关方系统通过这些API服务进行数据查询或数据更新。

同时,为了规避相关方系统需要定时轮询来获取数据变动的弊端,另外提供一套服务的消息服务机制,接口开放平台作为消息服务中心,接收物流系统作为生产者产生的业务消息,如委托单创建、车辆入厂、用户签收,然后查找订阅该消息主题的相关方系统,实时以消息推送的方式通知相关方系统。

由平台技术框架部分,承担通用的逻辑实现,如数据验证、服务分发与调用、权限、日志、异常,而具体的业务API服务和业务系统的开发,仅需关注业务逻辑的实现即可。

总结下,也就是依托面向对象设计理念,对接口和消息进行组织:功能模块->业务实体->功能接口及消息
通用接口开放平台设计与实现——(1)开篇_第1张图片

API服务实现业务数据交换,消息服务实现数据变动通知。

该平台主要由两部分组成,API服务和消息服务。
API服务:物流接口平台对外提供统一的数据接口服务,其他应用系统通过调用API服务,一方面,可以查询权限范围内的物流数据,另一方面,可以将自身系统产生的数据推送至物流系统。
消息服务:物流接口平台提供消息服务,主动将物流系统的数据的变化以消息的形式推送给其他系统。消息服务基于Socket技术,调用方系统与物流接口平台建立长连接,实时接收消息通知,避免调用方定时轮询,提高API调用效率,降低双方服务器负荷。

这样做,最大的优点就是实现了标准化,相关方来对接时,如果现有的API能满足需求,只需提供标准化的服务接口,做简单的初始化配置(账号、密钥、权限、角色等)即可,最多加一点技术支持(解答疑问、联调);如果现有的API服务不能满足需求,则只需要设计和实现新的业务API服务就行了,并且新服务开发发布后,以后还能复用。

按照这种模式来实现,接口开发平台自身的设计和开发比较复杂,投入大一些,但一旦搭建出平台后,后续的业务开发成本就很低了,特别是对接工作和运维工作将非常简单,没有耦合和依赖。例如,我们做物流跟踪,市面上有多家服务提供商,如果是按照这种模式来,如跟某厂家合作一段时间后,对其服务能力不满意,则可以轻松更换一家,不需要进行接口的定制和调整。

该平台并并不局限于某一特定系统或行业,具备通用性。

接下来,我会将整个平台的设计与实现,包括中间方案的选择,进行的重构和优化,用一系列文章进行介绍和说明,欢迎评论、交流、收藏和转发。

开源地址:传送门

你可能感兴趣的:(接口开放平台设计与实现,接口,开放平台,实战,应用,netty)