首先简单聊下背景，大概是几年前，工作中遇到这么一个复杂的应用场景，大型企业中的物流系统，需要跟众多的内外部系统交互，对接的系统达到十几个，接口数量在50个左右，并且后续还会大量增加新的对接方，并且很多对接方是类似的，例如跟汽运物流厂商的运输管理系统TMS，进行运输委托、运力反馈、运费结算、签收回传等交互。
如何还是按照传统模式去做点对点集成，会消耗大量成本，包括时间和费用，并且上线后还会搭上大量的运维成本。伴随的问题，当业务发生变更时，接口的升级更新，也是大麻烦，往往涉及到多方协调、开发、联调、上线。
基于这个背景，思考一种优雅的解决方案，能低成本、高效率解决这个难题。
最终思路是实现一套物流系统的接口开放平台，由平台对外提供一套标准的Rest风格的API服务作为服务接口，相关方系统通过这些API服务进行数据查询或数据更新。
为了规避相关方系统需要定时轮询来获取数据变动的弊端，另外提供一套服务的消息服务机制，接口开放平台作为消息服务中心，接收物流系统作为生产者产生的业务消息，如委托单创建、车辆入厂、用户签收，然后查找订阅该消息主题的相关方系统，实时以消息推送的方式通知相关方系统。
由平台技术框架部分，承担通用的逻辑实现，如数据验证、服务分发与调用、权限、日志、异常，而具体的业务API服务和业务系统的开发，仅需关注业务逻辑的实现即可。
总结下，也就是依托面向对象设计理念，对接口和消息进行组织：功能模块->业务实体->功能接口及消息
API服务接口实现具体功能，消息服务接口实现消息通知。
该平台主要由两部分组成，API服务和消息服务。API服务：物流接口平台对外提供统一的数据接口服务，其他应用系统通过调用API服务，一方面，可以查询权限范围内的物流数据，另一方面，可以将自身系统产生的数据推送至物流系统。消息服务：物流接口平台提供消息服务，主动将物流系统的数据的变化以消息的形式推送给其他系统。消息服务基于Socket技术，调用方系统与物流接口平台建立长连接，实时接收消息通知，避免调用方定时轮询，提高API调用效率，降低双方服务器负荷。
这样做，最大的优点就是实现了标准化，相关方来对接时，如果现有的API能满足需求，只需提供标准化的服务接口，做简单的初始化配置即可，最多加一点技术支持；如果现有的API服务不能满足需求，则只需要设计和实现新的业务API服务就行了，并且新服务开发发布后，以后还能复用。
按照这种模式来实现，接口开发平台自身的设计和开发比较复杂，投入大一些，但一旦搭建出平台后，后续的业务开发成本就很低了，特别是对接工作和运维工作将非常简单，没有耦合和依赖。例如，我们做物流跟踪，市面上有多家服务提供商，如果是按照这种模式来，如跟某厂家合作一段时间后，对其服务能力不满意，则可以轻松更换一家，不需要进行接口的定制和调整。
文章为作者独立观点，不代表股票交易接口观点
相关文章
股民评论