基于SSM框架的分布式車險下單系統的設計與實現

程俊達， 黃素娟， 張舵

(上海大學 電子與通信工程，上海 200444)

0 引言

隨著我國經濟的發展和人民生活水平的提高，機動車的數量不斷增加，與之相對的車險市場也呈現出快速發展的態勢。汽車保險已成為我國非壽險市場的主要組成部分，更是財產保險中的第一大險種[1]。市場的擴大和業務量的快速增長使得傳統的辦公模式已越來越不適應行業的發展需求，必須對其進行信息化的改革，轉型迫在眉睫[2]。

本文以互聯網與車險業務為出發點，設計實現一個基于互聯網和移動終端的車險業務交易平臺。這種新型的業務模式具有較高的工作效率、較高的數據安全性和保密性、靈活的模塊化設計應對各種業務擴展等優勢。通過這樣一個互聯網化的車險平臺可以大大降低保險行業的運營成本，提高業務效率，而用戶的投保方式也變得更加便捷和自由化。

1 平臺設計

過去保險行業的業務模式主要為線下銷售，車主需要經過排隊等候和一系列復雜程序才能完成投保，銷售成本較高且效率低下，也就直接導致了較低的利潤率和較差的客戶體驗。而傳統的保險公司的業務平臺大多按照內部開發思路搭建，在不同期間為滿足不同的需求而設計開發，沒有統一的規范標準，當有新的應用需求時，難以進行擴展。而針對新需求去開發新的業務系統又難以做到與以前的系統進行集成以及數據的互通，不同的系統之間形成一個個“信息孤島”，所以經常出現信息斷層的情況[3]。

雖然當下一些主流保險公司已開啟了互聯網車險的業務模式，但各家公司彼此獨立，在用戶進行車險產品的比較選擇時需要登錄多個平臺，所以車主們迫切需要一個整合各大保險公司業務渠道的互聯網車險平臺，來提供更為便捷高效的投保服務。

1.1 主要模塊介紹

如圖1所示。

一個完整的車險平臺主要分為三個模塊：用戶模塊、車險業務模塊、訂單管理模塊。

用戶模塊：該模塊主要工作是負責用戶通過已注冊的賬號進行登錄、登出以及用戶個人信息的編輯修改。

車險下單模塊：該模塊負責車險下單的整個業務流程，也是整個平臺最核心的模塊。主要功能包含通過用戶信息進行一次車型查詢(確定車系)及二次車型查詢(確定車輛型號)、針對用戶選擇的險種各個保險公司進行相應報價、用戶選擇保險公司進行下單及支付、生成訂單。

圖1 系統功能模塊圖

訂單查詢模塊：可以根據訂單的支付狀態、訂單日期、投保狀態等選項進行查詢歷史訂單，并根據查詢出的訂單信息列表導出表格。

1.2 數據庫設計

整個車險平臺的核心業務流程是從用戶進行車型查詢開始，到最終完成訂單結束，中間主要涉及到用戶信息表、車輛信息表以及訂單信息表。如圖2所示。

圖2 數據庫表設計及對應關系

圖2中各張表中包含主要信息的幾個字段，分別為用戶信息表(UserInfo)、車輛信息表(MyVehicle)、訂單表(MyOrderInfo)。圖中1∶1以及1∶N表示數據庫表之間的1對1和1對多的關系。

2 技術框架

2.1 SSM框架

SSM框架是由Spring, Spring MVC和MyBatis三個框架集成的。SSM框架自上而下被分為表現層(Jsp頁面)、控制層(SpringMVC控制)、業務邏輯層(Spring IOC/AOP實現)和數據持久層(Mybatis框架)四層[4]，如下圖3所示。

該框架實現了J2EE層結構設計的技術要求，使每一層的功能和職責定義非常清晰，通過接口在各層之間實現通信，大大提高系統的開發效率，增強系統的穩定性，提高系統的可維護性和可拓展性[5]。

2.2 Dubbo框架

Dubbo是阿里巴巴提供的、基于Java 的Http Client請求、高性能的開源 RPC 遠程服務調用方案，通過Dubbo可以把業務邏輯分離出來，作為一個獨立的模塊，使得前端應用能快速和穩定地響應請求。使用Dubbo架構可以支撐高并發的項目，且低耦合，擴展性、穩定性都很強[6]。其核心部分包含遠程通訊、集群容錯和注冊中心，本項目的注冊中心采用的為zookeeper。Dubbo中注冊中心負責服務地址的注冊與查找，相當于目錄服務，服務提供者和消費在啟動時與注冊中心交互。

圖3 SSM框架整合

通過將項目分為生產者與消費者，分別在注冊中心注冊相應服務，生產者與消費者通過注冊中心進行遠程通訊。采用這種框架不僅使得項目之間耦合成度降低，易于開發和維護，并且當日后系統的訪問量和數據量急劇擴大，也能進行相應的擴展[7]。

3 系統的實現

3.1 框架組合的實現

通過Spring-mvc.xml,Spring-mybatis.xml以及Web.xml這三個配置文件搭建車險平臺。

Spring-mvc.xml文件是springmvc的一些相關配置配置 ，其中〈mvc:annotation-driven/〉相當于注冊DefaultAnnotationHandlerMapping(映射器)和 AnnotationHandlerAdapter(適配器)兩個bean，即解決了@Controller注解的使用前提配置。context:component-scan對指定的包進行掃描，實現注釋驅動Bean定義，同時將bean自動注入容器中使用。即解決了@Controller標識的類的bean的注入和使用。同時也可在其中配置視圖解析器。

Spring-mybatis.xml文件通過〈context:component-scan base-package=" xxx"/〉 自動掃描,將標注Spring注解的類自動轉化Bean，同時完成Bean的注入。配置數據源并通過sql -SessionFactory 并將數據源注入，同時需創建數據映射器，如果有需要的話可在其中配置事務管理。

Web.xml文件中通過context-param配置了spring的上下文位置，并通過listener配置通知容器加載spring配置文件，同時需配置一個前端控制器Spring MVC核心控制器(Spring MVC 核心控制器)。

3.2 車險業務模塊的實現

用戶在車險平臺進行車險購買的過程中大致需要經過“車型查詢-二次車型查詢-險別選擇-報價-下單支付”的流程。詳細流程如圖4所示。

用戶通過在網頁上輸入個人信息、投保地區及車型名稱，以上述信息作為查詢參數進行一次車型查詢，用于判定當前查詢車輛是否曾經在該平臺上購買過車險，此處調用的是本地數據庫。二次車型查詢建立在一次查詢的基礎上，用于精準確認需要購買車險的車輛的詳細信息。因為車輛查詢的請求參數和返回參數較多，從代碼的美觀性和可維護性考慮，我們通過建立一個ReqVehicleInfo以及ResVehicleInfo的中間類來對要這個過程中需要進行傳遞的車牌號、車架號、車主等數據進行封裝，方便在后續的開發中可以便捷的調用和操作這些中間信息。

圖4 車險下單業務流程

用戶確認車型之后，需要對險別進行選擇生成一套保險方案并進行報價。而報價的實現則是通過與各家保險公司對接，以Http請求通信的方式實現遠程調用接口，獲取精確報價。

用戶在得到各家保險公司的報價之后可以自由選擇其中一個進行下單支付，系統通過保險公司返回的數據結合之前流程中由中間類保存下來的數據，最后生成訂單，存入數據庫中，并在訂單查詢模塊進行展示。

整個車險購買的流程，通過采用SpringMVC框架的表示層控制頁面間的跳轉、利用Ajax技術實現頁面不刷新情況下用戶與后臺間的數據交互，通過Mybatis框架的持久層進行數據的查詢和存儲。

3.3 訂單管理模塊的實現

一個完善的車險平臺不僅要為用戶提供便捷的投保渠道，也要針對已經產生的訂單為用戶提供一個便捷有效的管理方式。訂單查詢模塊為用戶提供多種方式的訂單查詢方式，由用戶在頁面上自行選擇訂單生成的起止日期、保險公司類別、支付狀態、投保狀態等查詢條件，因為這些查詢條件會有多種組合方式，且隨著業務規則的變化查詢參數的個數和種類也會隨著規則變化，所以開發的時候如果采用固定入參的查詢方法是非常繁瑣的。因此我們采用根據入參的不同進行動態查詢的方案。整個訂單查詢操作所經歷的流程如圖5所示。

圖5 訂單查詢流程示意圖

訂單信息的導出，可以通過引入jxl.write.*的jar包，利用其中的WritableWorkbook以及WritableSheet兩個類，創建表格對象，將要導出的字段信息與表格的相應欄進行匹配，通過IO流將表格導出。

3.4 系統的分布式化

我們在設計和實現這樣一個車險平臺時，需要考慮到隨著時間的推移，用戶訪問量和數據量都會日益擴大，而且保險的業務規則也是處于一種隨時變化的狀態。因此，我們可以將車險平臺設計成一個分布式系統，以此來提升系統的可擴展性和可維護性，便于針對應對大數據量和高并發的情況進行系統升級，和針對業務規則變更進行業務擴展。這樣一來也大大降低了開發的難度和復雜度，便于日后代碼的維護和修改。

本項目采用Dubbo的分布式框架，配合zookeeper注冊中心，實現系統的分布式化。在本項目中，我們將系統的web模塊作為消費者，后臺接口模塊作為生產者，通過注冊中心進行服務注冊，由注冊中心作為中轉實現消費者對生產者所提供的后臺服務的調用。通過applicationContext-dubbo.xml的配置文件來實現對Dubbo框架的配置，其配置方法大致如圖6所示。

圖6 Dubbo配置信息示例

4 總結

本文結合當今車險行業的發展需求和車險下單的流程特點，在整合了SSM與Dubbo框架的基礎上，設計并實現了一個整合各大保險公司業務的車險平臺。開發過程中實現了業務邏輯、數據庫、前端界面的分離，大大降低各模塊間的耦合度。最終開發完成的車險平臺具有高度的可拓展性和可維護性，且用戶操作簡便。系統功能測試結果如表1所示：

表1 測試結果

經過測試，一個新用戶從登陸平臺到下單完成，用時控制在十分鐘之內，相較傳統的保險運營模式其效率有了很大提升，實現了高效便捷、用戶體驗好的設計初衷。