基于消息中间件的充电桩服务跨平台解耦合技术研究

陈勇

（度普（上海）新能源技术有限公司 上海 200120）

前言

互联网企业间有很多都是共享服务的包含数据共享、业务共享、服务共享等，电动汽车充换电行业也是需要互联互通来达到业务扩大的目的。各个充电桩运营企业间可以互用对方的基础设施为各自的客户提供服务，充电桩运营比较多的企业可以接入客户较多的企业实现业务的最大化。现在全国的充电基础设施累计168万，当前这个行业正处在急速发展中未来的市场还很大，势必会有更多的企业参与进来，这样合作共赢必是大势所趋。

为了不影响本企业后端服务于充换电业务逻辑的应用程序的正常运行，这时消息中间件的使用就是最好的选择，包括kafka，mqtt，redis缓存服务等都是可选的方案。本文提出的一种基于kafka发布/订阅模式的业务解耦模式运用于企业间充换电服务共享技术[1]。解决了高并发模式下业务解耦的问题。

1 业务逻辑实例

充换电业务逻辑中各方：客户（app），基础设施（设备），云端后台处理程序。

客户（app）：持有充换电企业服务app的消费者，

基础设施（设备）：充电桩。

云端后台处理程序：云端后台处理程序包含：支付处理程序，开启充电处理程序，充电中处理程序，停止充电处理程序，结算服务等。

简要充电服务后端程序流程如图1所示：

本实例中，各个阶段的服务是相互联系的一整套流程，作为一家充电服务企业的主业务流程，是不需要考虑流程之外的过程，只要确保流程简单，所要做的后端处理逻辑相对较少，扫码、下发费率、开启、充电、停止（可选）、结算等过程相对可靠，流程上每一步都处在监控之下，只要能稳定的输出结果，在高并发的环境下，只需要配合比较好的后端服务器资源和网络资源，保证这个流程的可靠性即可。

但是当有其他家企业共享本单位的服务，按照中国电力企业联合会的协议文件，就会出现耦合性的困扰，跨平台耦合性带来的软件开发和调试压力会急剧上升，不仅仅要考虑自有平台的可靠性，还要结合互联平台提供的接口可靠性，而且第三方平台是自有平台无法监控的逻辑，导致跨平台服务共享的可靠性和用户体验大打折扣。

综上就需要消息中间件（比如kafka等应用程序）来解决耦合性的问题，这样跨平台服务共享的充电流程和本平台内部的充电服务流程就变成了如下图的过程：

如图2所示，本平台在进行业务相关流程的时候，只需要第三方平台一次接入触发主流程，接下来自由平台只需要和消息中心交互，就完成了第三方运营商的接入。这样降低了双方平台的耦合性，完成本平台主业务流程的过程中，不需要对第三方接入主流程逻辑做过多的代码开发和逻辑关联。

2 难点及分析

在高并发的业务场景下，汽车充电桩企业间自由的系统是一个对稳定性要求极高的系统，这个稳定性关系到客户的体验进而影响到整个公司的核心竞争力。企业自由的系统必须保证高可靠性，这时候就需要把复杂的问题简单化，整个业务流程越简单，出现异常的概率就会越小。但是当有和第三方企业接入到自由系统，就会增加自由系统的复杂程度，这是一个矛盾的问题。这也是许多企业在非必要的情况下不愿意和别的平台进行互联互通业务的重要原因。

综上，一方面要求系统流程简单，一方面又是有必须增加系统复杂度的需求，这给工程实施人员增加了难度。需要一种互联互通的模式来达到这两个方面都相互满足的情况下，使得自有系统的可靠性不降低的情况下，又能达到企业间互联服务的需求，下文将为解决这个难点问题提出一种解耦合的技术方案。

3 业务解耦架构

3.1 应用场景

当我们调用第三方服务接口的过程中，势必建立起了双方平台之间的耦合关系，以请求第三方的一个接口为例（如图3）来说明耦合关系。

这种在语法上是函数之间的调用，对语言和平台要求要一致，并且调用讲究时序，必须等到被调用的接口有相应的反应或者是超时，才会进行下一步操作，服务请求方和服务提供方程序逻辑不独立。

消息队列的引入，解决了不同平台之间应用不独立的耦合性问题，改进之后的请求关系如图4所示。

在图4中，请求者只需要把需要请求服务的信息广播给消息中心即可，不用等待返回，接着进行主流程的业务逻辑。消息中心按照一定队列规则，请求第三方的服务，请求完成之后再把请求结果广播给请求者。特别是面对高并发的场景，消息队列的引入极好的解决了接口请求拥塞的问题[2]（Too Many Connections异常）。

3.2 技术方案

使用kafka分布式实时数据流平台，实现跨平台服务间的解耦操作。

一个kafka系统包含生产者（Producer），消费者（Consumer）。生产者将消息发布到kafka集群指定的Topic中存储，消费者从kafka集群中按照Topic消费这一条消息。这样充电流程就变成如图5的过程：

如图2所示，虚线是一种消息广播路径，只是在本系统业务流程中广播出当前流程的消息，至于哪个消费者消费这个消息，不需要做处理。就是说本系统中扫码到结算是一整套流程，其他平台调用我们的系统逻辑只是调用开启到结算的过程，而且这个过程是通过消息中间件来解耦操作，扫码到调用开启充电接口的过程是别的平台来完成的[3]（第三方app）。

业务流程中涉及到的发布订阅方：

（1）消息生产者：这个是以本系统作为消息生产者，当有一个充电服务请求发起的时候，本系统只是当这个请求是本系统发起的，系统只需要完成一次正常的业务流程即可。当这个请求是由第三方发起的，就会把每一步的流程广播到kafka集群。

（2）消息消费者：这个是本系统内为了适配第三方服务开发的应用程序，应为双方平台接口文档是不同的，这里要有一个适配的应用程序。当监听程序监听到响应的Topic，就会做出相应的反应，比如最后客户汽车已经满充，上报了停止充电的成功的指令，监听服务监听到已经停止的指令，就会按照这个指令出来的信息，将结算的信息作为body去调用第三方的结算接口。

（3）Topic：kafka是按照Topic为标识来区分不同业务类型的消息的。在电动汽车充电业务中，都是用Topic（charging）来确认这是一个充电业务进行中的Topic。kafka集群的消费者按照这个Topic来消费业务消息，不同业务之间互不干扰。

综上，业务流程经过解耦的技术操作之后，不仅开发人员可以独立进行自有平台充电服务逻辑的开发和维护，跨平台之间的调用也是一套独立的业务处理程序，相互之间的联系采用消息中间件（kafka）来完成。两个流程之间不再是函数之间的调用，而是信息的发布和订阅。

4 结束语

本文研究了跨平台接口调用耦合性的问题，并提出了一种基于kafka数据流平台的消息队列机制来解决微服务解耦的问题。特别是在高并发和大数据量的情况下，消息队列的引入极大的缓解了接口拥塞的问题。本文提出了一种在物联网技术背景下，汽车充电桩行业跨平台共享服务及其互联互通的方案，这种方案极大的减少了开发人员的技术难度和在生产环境的资源消耗，增加了物联网行业技术上的可选择性和系统上的可靠性。