陳勇

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

前言

互聯(lián)網(wǎng)企業(yè)間有很多都是共享服務的包含數(shù)據(jù)共享、業(yè)務共享、服務共享等，電動汽車充換電行業(yè)也是需要互聯(lián)互通來達到業(yè)務擴大的目的。各個充電樁運營企業(yè)間可以互用對方的基礎設施為各自的客戶提供服務，充電樁運營比較多的企業(yè)可以接入客戶較多的企業(yè)實現(xiàn)業(yè)務的最大化?，F(xiàn)在全國的充電基礎設施累計168萬，當前這個行業(yè)正處在急速發(fā)展中未來的市場還很大，勢必會有更多的企業(yè)參與進來，這樣合作共贏必是大勢所趨。

為了不影響本企業(yè)后端服務于充換電業(yè)務邏輯的應用程序的正常運行，這時消息中間件的使用就是最好的選擇，包括kafka，mqtt，redis緩存服務等都是可選的方案。本文提出的一種基于kafka發(fā)布/訂閱模式的業(yè)務解耦模式運用于企業(yè)間充換電服務共享技術[1]。解決了高并發(fā)模式下業(yè)務解耦的問題。

1 業(yè)務邏輯實例

充換電業(yè)務邏輯中各方：客戶（app），基礎設施（設備），云端后臺處理程序。

客戶（app）：持有充換電企業(yè)服務app的消費者，

基礎設施（設備）：充電樁。

云端后臺處理程序：云端后臺處理程序包含：支付處理程序，開啟充電處理程序，充電中處理程序，停止充電處理程序，結算服務等。

簡要充電服務后端程序流程如圖1所示：

本實例中，各個階段的服務是相互聯(lián)系的一整套流程，作為一家充電服務企業(yè)的主業(yè)務流程，是不需要考慮流程之外的過程，只要確保流程簡單，所要做的后端處理邏輯相對較少，掃碼、下發(fā)費率、開啟、充電、停止（可選）、結算等過程相對可靠，流程上每一步都處在監(jiān)控之下，只要能穩(wěn)定的輸出結果，在高并發(fā)的環(huán)境下，只需要配合比較好的后端服務器資源和網(wǎng)絡資源，保證這個流程的可靠性即可。

但是當有其他家企業(yè)共享本單位的服務，按照中國電力企業(yè)聯(lián)合會的協(xié)議文件，就會出現(xiàn)耦合性的困擾，跨平臺耦合性帶來的軟件開發(fā)和調(diào)試壓力會急劇上升，不僅僅要考慮自有平臺的可靠性，還要結合互聯(lián)平臺提供的接口可靠性，而且第三方平臺是自有平臺無法監(jiān)控的邏輯，導致跨平臺服務共享的可靠性和用戶體驗大打折扣。

綜上就需要消息中間件（比如kafka等應用程序）來解決耦合性的問題，這樣跨平臺服務共享的充電流程和本平臺內(nèi)部的充電服務流程就變成了如下圖的過程：

如圖2所示，本平臺在進行業(yè)務相關流程的時候，只需要第三方平臺一次接入觸發(fā)主流程，接下來自由平臺只需要和消息中心交互，就完成了第三方運營商的接入。這樣降低了雙方平臺的耦合性，完成本平臺主業(yè)務流程的過程中，不需要對第三方接入主流程邏輯做過多的代碼開發(fā)和邏輯關聯(lián)。

2 難點及分析

在高并發(fā)的業(yè)務場景下，汽車充電樁企業(yè)間自由的系統(tǒng)是一個對穩(wěn)定性要求極高的系統(tǒng)，這個穩(wěn)定性關系到客戶的體驗進而影響到整個公司的核心競爭力。企業(yè)自由的系統(tǒng)必須保證高可靠性，這時候就需要把復雜的問題簡單化，整個業(yè)務流程越簡單，出現(xiàn)異常的概率就會越小。但是當有和第三方企業(yè)接入到自由系統(tǒng)，就會增加自由系統(tǒng)的復雜程度，這是一個矛盾的問題。這也是許多企業(yè)在非必要的情況下不愿意和別的平臺進行互聯(lián)互通業(yè)務的重要原因。

綜上，一方面要求系統(tǒng)流程簡單，一方面又是有必須增加系統(tǒng)復雜度的需求，這給工程實施人員增加了難度。需要一種互聯(lián)互通的模式來達到這兩個方面都相互滿足的情況下，使得自有系統(tǒng)的可靠性不降低的情況下，又能達到企業(yè)間互聯(lián)服務的需求，下文將為解決這個難點問題提出一種解耦合的技術方案。

3 業(yè)務解耦架構

3.1 應用場景

當我們調(diào)用第三方服務接口的過程中，勢必建立起了雙方平臺之間的耦合關系，以請求第三方的一個接口為例（如圖3）來說明耦合關系。

這種在語法上是函數(shù)之間的調(diào)用，對語言和平臺要求要一致，并且調(diào)用講究時序，必須等到被調(diào)用的接口有相應的反應或者是超時，才會進行下一步操作，服務請求方和服務提供方程序邏輯不獨立。

消息隊列的引入，解決了不同平臺之間應用不獨立的耦合性問題，改進之后的請求關系如圖4所示。

在圖4中，請求者只需要把需要請求服務的信息廣播給消息中心即可，不用等待返回，接著進行主流程的業(yè)務邏輯。消息中心按照一定隊列規(guī)則，請求第三方的服務，請求完成之后再把請求結果廣播給請求者。特別是面對高并發(fā)的場景，消息隊列的引入極好的解決了接口請求擁塞的問題[2]（Too Many Connections異常）。

3.2 技術方案

使用kafka分布式實時數(shù)據(jù)流平臺，實現(xiàn)跨平臺服務間的解耦操作。

一個kafka系統(tǒng)包含生產(chǎn)者（Producer），消費者（Consumer）。生產(chǎn)者將消息發(fā)布到kafka集群指定的Topic中存儲，消費者從kafka集群中按照Topic消費這一條消息。這樣充電流程就變成如圖5的過程：

如圖2所示，虛線是一種消息廣播路徑，只是在本系統(tǒng)業(yè)務流程中廣播出當前流程的消息，至于哪個消費者消費這個消息，不需要做處理。就是說本系統(tǒng)中掃碼到結算是一整套流程，其他平臺調(diào)用我們的系統(tǒng)邏輯只是調(diào)用開啟到結算的過程，而且這個過程是通過消息中間件來解耦操作，掃碼到調(diào)用開啟充電接口的過程是別的平臺來完成的[3]（第三方app）。

業(yè)務流程中涉及到的發(fā)布訂閱方：

（1）消息生產(chǎn)者：這個是以本系統(tǒng)作為消息生產(chǎn)者，當有一個充電服務請求發(fā)起的時候，本系統(tǒng)只是當這個請求是本系統(tǒng)發(fā)起的，系統(tǒng)只需要完成一次正常的業(yè)務流程即可。當這個請求是由第三方發(fā)起的，就會把每一步的流程廣播到kafka集群。

（2）消息消費者：這個是本系統(tǒng)內(nèi)為了適配第三方服務開發(fā)的應用程序，應為雙方平臺接口文檔是不同的，這里要有一個適配的應用程序。當監(jiān)聽程序監(jiān)聽到響應的Topic，就會做出相應的反應，比如最后客戶汽車已經(jīng)滿充，上報了停止充電的成功的指令，監(jiān)聽服務監(jiān)聽到已經(jīng)停止的指令，就會按照這個指令出來的信息，將結算的信息作為body去調(diào)用第三方的結算接口。

（3）Topic：kafka是按照Topic為標識來區(qū)分不同業(yè)務類型的消息的。在電動汽車充電業(yè)務中，都是用Topic（charging）來確認這是一個充電業(yè)務進行中的Topic。kafka集群的消費者按照這個Topic來消費業(yè)務消息，不同業(yè)務之間互不干擾。

綜上，業(yè)務流程經(jīng)過解耦的技術操作之后，不僅開發(fā)人員可以獨立進行自有平臺充電服務邏輯的開發(fā)和維護，跨平臺之間的調(diào)用也是一套獨立的業(yè)務處理程序，相互之間的聯(lián)系采用消息中間件（kafka）來完成。兩個流程之間不再是函數(shù)之間的調(diào)用，而是信息的發(fā)布和訂閱。

4 結束語

本文研究了跨平臺接口調(diào)用耦合性的問題，并提出了一種基于kafka數(shù)據(jù)流平臺的消息隊列機制來解決微服務解耦的問題。特別是在高并發(fā)和大數(shù)據(jù)量的情況下，消息隊列的引入極大的緩解了接口擁塞的問題。本文提出了一種在物聯(lián)網(wǎng)技術背景下，汽車充電樁行業(yè)跨平臺共享服務及其互聯(lián)互通的方案，這種方案極大的減少了開發(fā)人員的技術難度和在生產(chǎn)環(huán)境的資源消耗，增加了物聯(lián)網(wǎng)行業(yè)技術上的可選擇性和系統(tǒng)上的可靠性。