微服務架構在商務領域信息系統集中化建設中的應用研究

桂思思 陳幺華 秦 偉

(1.武漢科技大學 城市學院,湖北 武漢 430083；2. 神龍汽車有限公司, 湖北 武漢 430056)

0 引言

近年來隨著移動業務的迅猛發展，汽車廠商傳統業務模式受到了移動互聯網新型業務模式的沖擊，客戶服務觸點中移動互聯的應用日趨活躍，傳統渠道認知向數字媒介認知轉向，產品競爭向服務競爭轉化。部分汽車廠商開始嘗試從BtoBtoC向BtoCtoB的模式進行轉變，給用戶帶來更極致的業務體驗將對營銷環節起到重要作用。在此環境下，需要商務領域的信息系統承接更多面向最終用戶的業務需求，并且能夠滿足應用入口多樣化；操作友好，流程短；應用、服務變化快的特點。

1 商務領域信息系統架構對比

1.1 系統建立模式對比

絕大多數廠商商務領域信息系統建設，一方面滿足業務發展要求；另一方面結合技術環境和發展方向，建立最適合主機廠的系統模式。我國主機廠的商務領域系統大體上有兩種建設模式：

(1)分散式，主要表現為系統按照業務或功能類別劃分為多個單體結構系統，單體系統各自獨立部署，獨立存在，系統與系統之間通過各類接口進行數據交互，如商務領域涉及售后保修的保用系統、涉及車輛采購與分配的整車管理系統等。此種模式，對單個系統而言，不易進行大規模的功能擴展，任何修改都需要將應用重新發布部署，編譯時間長，且系統與系統之間存在數據冗余，耦合性較大，接口多，數據交互復雜。

(2)集中式，將分散的各個單體結構系統融合建立成統一的系統，例如將經銷商管理功能、整車管理功能、售后保修功能等均融合在新建的系統中，實現商務領域數據的集中存儲。此種模式減少了系統間的各種數據交互，減少接口數量，增加系統處理的效率與及時性，新功能擴展也更靈活，很好的解決了垂直架構弊端。

通過對國內主機廠的商務領域系統架構進行調研時發現，2012年前，受到當時網絡帶寬、服務器性能等硬件環境的限制，商務領域系統大多采用分散模式，經銷商管理系統采用C/S架構。2012年后主機廠開始向商務領域全功能集中式的平臺發展，將經銷商管理系統與其他商務領域管理系統進行融合建立，實現數據庫集中。

1.2 集中式系統架構對比

對于集中式架構，主機廠主要采用的系統架構主要有兩種，SOA架構與微服務架構。

SOA架構將應用部分功能進行拆分，以服務形式提供，系統與服務之間通過ESB采用webservice、異步接口等方式進行通信。此種架構，系統與服務的界限模糊，服務的粒度過大，系統與服務之間耦合性高，雖然使用了ESB，但是服務的接口協議不固定，種類繁多。

對微服務架構，業務邏輯被拆分成一系列小而松散耦合的分布式組件，共同構成了較大的應用。每個組件都被稱為微服務，而每個微服務都在整體架構中執行單獨的任務，或負責單獨的功能。每個微服務可能會被一個或多個其他微服務調用，以執行較大應用需要完成的具體任務。此種架構強調的是微服務之間總是松耦合，著重分散管理，微服務的目的是有效的拆分應用，實現開發和部署。

SOA架構與微服務架構的對比，如表1所示。

表1 SOA架構與微服務架構的對比

微服務架構和SOA架構相比更適合面向最終用戶的移動互聯網的應用模式，更傾向于基于多種技術棧的敏捷開發和快速上線，并能支持服務級別的獨立部署更新及面向不同用戶的灰度發布。在近1～2年中，新建主機廠在商務領域系統建設中采用了集中式的微服務架構，一方面實現所有商務領域數據的集中化管理；另一方面通過業務功能的顆粒度切分，實現新功能的靈活發布與調用。滿足應用入口多樣化，應用、服務變化快的業務要求。

2 商務領域系統集中式微服務架構

2.1 商務領域一體化構建

對于新建的主機廠，在沒有建立任何商務領域系統時，可以直接構建集中式的微服務架構系統。但是對老主機廠，經過了早期的系統部署，已建立了分散式模式，在建立新的集中式微服務架構的商務領域系統的同時，還需要考慮已有系統的功能及歷史數據遷移。因此對分散式模式的老主機廠，商務領域集中化信息系統的構建有兩個主要的實現過程：一方面基于現有系統的功能及新的功能演變要求構建集中式的微服務架構系統；另一方面需要將各個獨立的單體系統的數據進行遷移，對特殊應用進行特殊處理。

2.2 微服務應用架構

微服務的應用架構大致可分為4層：

(1)應用層。提供各種功能模塊，例如售前相關功能，整車相關功能等，同時面向主機廠、經銷商、最終用戶提供不同形式的使用窗口，如經銷商可通過門戶或客戶端或移動端使用線索跟蹤、整車采購等功能，用戶通過官網、商城或微信等渠道使用在線訂單、在線支付等功能。

(2)網關層。服務或微服務通過網關層提供給各類應用調研，根據應用類型，可能會有不同的網關，如面向移動應用的網關，面向外部第三方系統的調用網關等。

(3)服務層。服務層屬于整個系統的中臺，為所有的應用功能提供服務支撐，根據業務需求完成微服務的拆分與邏輯劃分，如和用戶相關的所有微服務都屬于用戶中心，和銷售相關的微服務都屬于銷售中心。所有的微服務需要在服務層進行注冊和配置，實現微服務的對外提供及微服務間的通信。同時服務層還需具備安全認證、資源動態調整、微服務監控等多種公共功能與監控功能。

(4)數據層。基于系統的數據結構考慮建立一體化的交易數據庫，用于存儲結構化的數據，對流媒體、語音、圖片等數據可考慮存放到非結構化數據庫中，根據實際情況考慮采用私有云、共有云或混合云的模式進行各類數據的存儲。

微服務應用架構，如圖1所示。

圖1 微服務應用架構

2.3 技術架構及工具

目前開源的微服務框架工具比較多，比較普遍使用的有springcloud、DUBBO等，框架中已涵蓋基于分布式系統的微服務配置管理、微服務的發布、負載均衡、消息隊列、事件、斷路器、智能路由、控制總線等開發工具包功能。在微服務的注冊/協同上，不同的微服務框架有些區別，dubbo的注冊中心可以選擇zk,redis等多種，springcloud的注冊中心可使用eureka。微服務和前端的API調用大多會提供輕量化的接口模式，如Spring Cloud框架支持REST(HTTP、HTTPS等)方式，DUBBO的框架支持RPC(二進制接口消息)方式。對于各種形式的前端展現，可通過前端數據API及數據緩存實現應用端的數據快速調用。微服務框架可支持Oracle、MySql、Nosql等各類數據庫，并支持不同類型數據庫之間的數據存儲與調用。技術架構如圖2所示。

圖2 微服務技術架構

2.4 微服務拆分

采用微服務架構構建系統時的一個重要設計環節是微服務的拆分，按照業務的功能進行拆分，直到每個微服務的功能和職責單一，甚至不可再拆分為止，每個服務都能獨立部署，擴容和縮容方便，能夠有效地提高利用率。拆得越細，服務的內聚性越好，越適合敏捷開發和上線。然而，拆得太細會導致系統的微服務數量較多，相互依賴的關系較復雜，微服務的調度協調難度增加，運維困難。對微服務的拆分顆粒度應該保持適當的度，原則是拆分到讓使用方自由地編排獲得相應的組合服務即可。

圖3 線索管理中心微服務拆分

微服的拆分從業務層面進行拆分，也可從性能層面進行拆分。從業務層面的拆分主要是保證微服務的獨立性和完整性，在提供服務的同時也能被其他服務所調用。從性能層面的拆分主要將有特殊性能要求，或經常進行變更的微服務拆分出來，滿足微服務的特殊環境要求，并能在微服務變化不影響其他微服務。

圖3為線索管理中心的微服拆分及服務的調用與組合。線索管理相關功能可以切分為多個的細小的微服務，如線索清洗微服務、重復商機清理微服務等，各種微服務的排列組合，形成多種不同的功能或服務，這些服務通過服務網關提供給展現層的不同客戶群的不同應用，形成不同的功能模塊。

3 系統架構遷移

3.1 歷史數據遷移

原有系統經過了多年的運行已產生了大量的歷史數據，歷史數據為新系統的運行提供數據支撐，保證業務的連續性。歷史數據需要遷移到新搭建的商務領域集中化的系統中，保證歷史數據在新系統的正常呈現和調取。歷史數據的遷移大致包含以下幾個步驟：

(1)環境準備。準備相關的硬件、軟件環境，并確定遷移歷史數據的范圍，時間點。

(2)歷史數據鏡像。將單系統的歷史數據進行全量備份和數據量檢測。

(3)臨界數據處理。后臺抽取并檢查未處理完成的臨界數據，由用戶完成臨界數據的處理，完成中間業務流程的操作。

(4)數據遷移。停用舊系統，啟用新系統，完成新系統初始化數據的導入，將第2步的歷史數據進行導入，核對歷史數據的完整性。

(5)系統跟蹤。跟蹤用戶作業熟練度、跟蹤系統線上線下作業效率、跟蹤系統問題、跟蹤業務規范情況。

3.2 特殊業務處理

對部分特殊的應用在商務領域系統集中化后會受到較大影響，因此特殊應用需要特殊分析。

3.2.1 語音業務

語音業務需要考慮兩個方面的業務整合和處理：①主機廠語音業務的整合。對于主機廠會有很多面向用戶的語音業務分支，如客戶關系維系、車聯網語音業務等，從主機廠的角度需要考慮語音業務平臺的業務功能整合，能實時調取所有的商務領域及車聯網業務數據，保證客服人員隨時查看用戶或車輛的全維度數據，并能記錄最新信息；②主機廠語音業務與網點語音業務的互通。主機廠到網點之間存在工單派發及工單更新、跟蹤的相關功能，因此需要實現主機廠客服人員與網點客服人員的語音互轉，及工單數據的實時傳遞。

對語音業務的處理方案包括：①基于商務領域系統集中化平臺建立相關的語音業務服務功能，例如用戶呼叫工單建立，工單的派發與跟蹤，用戶基本信息的查詢等功能；②在主機廠統一建立語音平臺，實現話務功能，包括客戶的呼入呼出、座席間的轉呼等，網點客服作為新建語音平臺的遠程客服接入，實現語音的互轉；③引入新型智能化功能，例如智能機器人、智能排班、智能外呼等，并實現新型智能化功能與商務領域系統集中化平臺的數據交互。

3.2.2 車間透明化業務

車間透明化業務涉及到網點的車牌識別、車間派工、質檢、客戶看板、交車看板等功能，以及車牌識別攝像頭、車間攝像頭、存儲設備、車間PAD、各類看板等硬件設備。建立商務領域集中化平臺后，對車間透明化業務也會造成較大的改動。網點端仍需部署透明車間的服務，包括車牌識別服務、工位攝像頭信息讀取服務等，通過新部署的服務實現視頻信息與工單數據的組合或校驗。新部署的服務需要從網點或云端調取網點的車牌信息或車間視頻信息，并從商務領域集中化平臺獲取工單及工單狀態信息，并將車牌信息、視頻信息、工單信息等進行各類數據匹配實現相應的看板功能。

4 結語

商務領域信息系統的集中化建設能夠實現數據統一存取，打破現有的分散式信息系統的數據傳輸壁壘，實現數據的統一存取標準，提升數據的使用效率，簡化信息流程。通過微服務架構實現應用功能的切分和松耦合，快速實現新應用或新功能的快速部署，應對需求的快速變化，面向用戶提供多入口的應用接入，聚焦客戶體驗，提升一體化客戶服務能力。