程俊達， 黃素娟， 張舵

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

0 引言

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

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

1 平臺設(shè)計

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

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

1.1 主要模塊介紹

如圖1所示。

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

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

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

圖1 系統(tǒng)功能模塊圖

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

1.2 數(shù)據(jù)庫設(shè)計

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

圖2 數(shù)據(jù)庫表設(shè)計及對應關(guān)系

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

2 技術(shù)框架

2.1 SSM框架

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

該框架實現(xiàn)了J2EE層結(jié)構(gòu)設(shè)計的技術(shù)要求，使每一層的功能和職責定義非常清晰，通過接口在各層之間實現(xiàn)通信，大大提高系統(tǒng)的開發(fā)效率，增強系統(tǒng)的穩(wěn)定性，提高系統(tǒng)的可維護性和可拓展性[5]。

2.2 Dubbo框架

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

圖3 SSM框架整合

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

3 系統(tǒng)的實現(xiàn)

3.1 框架組合的實現(xiàn)

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

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

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

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

3.2 車險業(yè)務模塊的實現(xiàn)

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

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

圖4 車險下單業(yè)務流程

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

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

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

3.3 訂單管理模塊的實現(xiàn)

一個完善的車險平臺不僅要為用戶提供便捷的投保渠道，也要針對已經(jīng)產(chǎn)生的訂單為用戶提供一個便捷有效的管理方式。訂單查詢模塊為用戶提供多種方式的訂單查詢方式，由用戶在頁面上自行選擇訂單生成的起止日期、保險公司類別、支付狀態(tài)、投保狀態(tài)等查詢條件，因為這些查詢條件會有多種組合方式，且隨著業(yè)務規(guī)則的變化查詢參數(shù)的個數(shù)和種類也會隨著規(guī)則變化，所以開發(fā)的時候如果采用固定入?yún)⒌牟樵兎椒ㄊ欠浅７爆嵉?。因此我們采用根?jù)入?yún)⒌牟煌M行動態(tài)查詢的方案。整個訂單查詢操作所經(jīng)歷的流程如圖5所示。

圖5 訂單查詢流程示意圖

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

3.4 系統(tǒng)的分布式化

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

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

圖6 Dubbo配置信息示例

4 總結(jié)

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

表1 測試結(jié)果

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