通用接口开放平台设计与实现——（1）整体介绍

背景

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

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

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

解决方案

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

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

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

API服务接口实现具体功能，消息服务接口实现消息通知。依托面向对象设计理念，对接口和消息进行组织：功能模块->业务实体->功能接口及消息

方案优势

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

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

该平台具有通用性，物流只是一个比较典型的应用场景而已，接下来，我会将整个平台的设计与实现，包括中间方案的选择，进行的重构和优化，用一系列文章进行介绍和说明，欢迎评论、交流、收藏和转发。

平台组成

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

功能架构

前面说过，接口开放平台主要有两部分功能组成，一是处于主体地位的API接口，对外提供数据服务；二是处于辅助角色的消息服务，用于通知数据变动。
实际上，客观上还需要平台自身管理功能，来维护平台的基础数据和功能，例如应用管理、服务管理、消息管理，权限控制，日志查看等。

系统功能架构图如下所示：

模块划分

platform-cip-common：公共基础
platform-cip-api：对外提供API数据接口，提供API服务
platform-cip-message：基于netty的web socket服务端提供消息服务
platform-cip-manage：平台自身基础数据的维护，如应用、API服务、消息服务、数据权限管理等。
4个模块内关系为manage依赖common，api和message相互独立，但都依赖于manage。

此外，cip-client是消息客户端，独立部署与运行。

开源平台资料

平台名称：一二三开发平台
简介： 企业级通用低代码开发平台
设计资料：CSDN专栏
开源地址：Gitee
开源协议：MIT
欢迎收藏、点赞、评论，你的支持是我前行的动力。