建站
咨詢
售后
建站咨詢
新聞中心
關于架構，筆者認為并不是越復雜越好，而是相反，簡單就是硬道理也提現(xiàn)在這里。這也是微服務能夠流行的原因，看看市場上曾經(jīng)出現(xiàn)的服務架 構：EJB、SCA、Dubbo等等，都比微服務先進，都比微服務功能完善，但它們都沒有微服務這么深入民心，就是因為他們過于復雜。簡單就是高科技，蘋 果手機據(jù)說專門有個團隊研究如何能讓用戶更加簡單的操作。大公司都是由小公司發(fā)展起來的，如果小公司在開始技術選型時感覺某個框架費時費力就不會選擇，而 小公司發(fā)展到大公司的過程，一般也伴隨著系統(tǒng)不斷優(yōu)化的過程，而不斷優(yōu)化往往不會重新選擇開發(fā)技術和框架，而是在原來基礎改進，這也許就是簡單框架流行的 本質(zhì)。
假設我們需要為超高業(yè)務量的保險代理企業(yè)設計一個“互聯(lián)網(wǎng)+”保險平臺。假設這家保險代理企業(yè)網(wǎng)上保險注冊用戶規(guī)模為2千萬，門店及加盟商銷售 人員2萬，年保單量2億單（中國平安總用戶規(guī)模達1.67億，擁有超過79.8萬名壽險銷售人員和約24.6萬名正式雇員。截至2015年6月30日，集 團總資產(chǎn)達4.63萬億元，歸屬母公司股東權益為3,311.90億元。而目前互聯(lián)網(wǎng)保險領頭羊眾安保險，經(jīng)營以小額貸款為主，由于背靠阿里巴巴，日保單 銷售量可達1億，不過別人很難復制眾安保險的模式）。因此我們?nèi)〈笮突ヂ?lián)網(wǎng)企業(yè)和眾安保險的折衷來考慮這個保險O2O平臺。
l 需求分析
參考保險業(yè)務相關文檔（文檔不全），獲得如下核心需求矩陣（因為涉及功能太多，只取大的功能點）。
|
分類 |
功能 |
質(zhì)量 |
約束 |
|
電子商務（B2C） |
產(chǎn)品展示（搜索、詳情展示等） |
及時響應、安全性、健壯性、易用性 |
多種險種，處理方式可能不同 |
|
產(chǎn)品購買（提交訂單、支付） |
及時響應、安全性、健壯性、易用性 |
多種險種，處理方式可能不同 | |
|
用戶中心（我的保單、我的理賠等） |
及時響應、安全性、健壯性、易用性 |
多種險種，處理方式可能不同 | |
|
代理人管理（加盟商管理） |
車險投保（詢價、錄單、繳費） |
及時響應、健壯性、可擴展性 |
多種險種，處理方式可能不同 |
|
非車險投保（詢價、錄單、繳費） |
及時響應、健壯性、可擴展性 |
多種險種，處理方式可能不同 | |
|
保單查詢 |
及時響應、健壯性、可擴展性 |
||
|
單證管理 |
及時響應、健壯性、可擴展性 |
||
|
我的賬戶（我的保單、傭金結算等） |
及時響應、安全性、可靠性、易用性 |
多種險種，處理方式可能不同 | |
|
案卷管理 |
案卷錄入 |
及時響應、健壯性、可擴展性 |
多種險種，處理方式可能不同 |
|
索賠資料收取 |
及時響應、健壯性、可擴展性 |
||
|
案卷交接 |
及時響應、健壯性、可擴展性 |
||
|
案卷跟蹤 |
及時響應、健壯性、可擴展性 |
||
|
客戶管理 |
客戶信息維護 |
及時響應、健壯性、可擴展性 |
上傳大量文件 |
|
客戶活動管理 |
及時響應、健壯性、可擴展性 |
||
|
商機管理 |
及時響應、健壯性、可擴展性 |
||
|
我的工作臺（消息、活動、商機） |
及時響應、健壯性、可擴展性 |
||
|
保險公估 |
車險定損過程跟蹤協(xié)助 |
及時響應、健壯性、可擴展性 |
多種險種，處理方式可能不同 |
|
人傷出險協(xié)助 |
及時響應、健壯性、可擴展性 |
多種險種，處理方式可能不同 | |
|
法律援助服務 |
及時響應、健壯性、可擴展性 |
多種險種，處理方式可能不同 |
從O2O的概念來看：“O2O即Online To Offline，也即將線下商務的機會與互聯(lián)網(wǎng)結 合在了一起，讓互聯(lián)網(wǎng)成為線下交易的前臺。這樣線下服務就可以用線上來攬客，消費者可以用線上來篩選服務，還有成交可以在線結算，很快達到規(guī)模。該模式最 重要的特點是：推廣效果可查，每筆交易可跟蹤（百度百科）”，不是每一種服務都適合O2O。商品類的銷售不適合O2O，因為你直接從網(wǎng)店就可以購買根本不 需要線下店。但保險類服務的確需要線下和線上結合，如果是純線上將不能滿足客戶的服務需求。O2O的線下服務可以是加盟商、代理人，也可以是直營店。
上面的需求是按照用戶角度提出的，雖然使用“系統(tǒng)”一詞，但這里的系統(tǒng)是一個抽象概念，可能包括軟件系統(tǒng)以及人事、制度等在內(nèi)。上面的需求可以 分為三大類，一類是針對終端用戶純線上服務：電子商務網(wǎng)站（B2C）；一類是專門針對代理人服務的：代理人系統(tǒng)；剩下的是一些公共服務，有可能電子商務網(wǎng) 站和代理人系統(tǒng)都會用到的一些服務。另外保險業(yè)務最大的一個問題是多個險種，不同險種處理方式有很大不同，這跟普通電子商務網(wǎng)站區(qū)別很大，比如天貓，所有 商品都是同樣的下單方式，同樣售后服務（主要就是快遞這塊），而保險產(chǎn)品即使是線上B2C網(wǎng)站下單操作，短險、壽險、車險等也是不同的，更何況保險有一大 堆售后服務，這些售后服務更加不相同。傳統(tǒng)保險公司在處理這方面時，一般會做多個系統(tǒng)，比如壽險系統(tǒng)，車險系統(tǒng)等等。
l 系統(tǒng)分析
安裝之前提到的業(yè)務規(guī)模我們分析（假設）出一些比較重要的性能需求：
a)產(chǎn)品方面：繼續(xù)上線當前沒有的保險產(chǎn)品
b)B2C網(wǎng)站日訪問量：5000萬PV
c)B2C產(chǎn)品購買并發(fā)高峰：2000 TPS
d)運維系統(tǒng)同時在線：1萬（共有2萬銷售員或代理人）
e)運維系統(tǒng)并發(fā)高峰：2000 TPS
f)短險訂單：每年1.85億單
g)長險訂單：每年500萬
h)車險訂單：每年1000萬
i)案卷信息：每年新增100萬單
日訪問量5000萬和產(chǎn)品并發(fā)2000 TPS是我們假設的，客戶信息和案卷信息是隨訂單數(shù)據(jù)量變化而變化，在前面我們雖然假設了總共每年產(chǎn)生2億個訂單，但是根據(jù)保險種類，短險（旅游險、傷殘 險）明顯產(chǎn)生了90%的訂單量，這一點需要特殊處理。除此之外車險和長險（主要指壽險等）無論是投保還是售后服務都有明顯不同，所以也需要特殊處理。
那么我們按照上面的需求，進行系統(tǒng)分析，首先按大的職責將職責相同的劃分為一個服務。并且有了上面這個性能需求，所有功能需求都需要增加一項 “質(zhì)量”特性，那就是“高并發(fā)”，高并發(fā)會影響到所有設計。另外如果要將互聯(lián)網(wǎng)保險平臺質(zhì)量特性排個序，最重要的是可擴展性、安全性，因為保險的種類多而 且處理方式不同，除此之外，高并發(fā)和可靠性也會直接影響功能的實現(xiàn)，但并沒有可擴展性影響大。深入分析職責后把每一種功能的實現(xiàn)關鍵技術列出，如下：
|
需求分類 |
實現(xiàn)需求 |
實現(xiàn)子系統(tǒng)及服務 |
軟硬件實現(xiàn)技術 |
|
客戶端 |
B2C電子商務網(wǎng)站 |
B2C Web客戶端 |
集群部署、高速緩存、分布式緩存、搜索引擎技術、靜態(tài)化 |
|
B2C電子商務網(wǎng)站手機客戶端 |
B2C App客戶端 |
||
|
代理人管理 |
代理人Web客戶端 |
集群部署、高速緩存、分布式緩存、搜索引擎技術、靜態(tài)化 | |
|
代理人管理手機客戶端 |
代理人App客戶端 |
||
|
案卷處理管理 |
案卷處理Web客戶端 |
集群部署、分布式緩存 | |
|
客戶管理管理 |
客戶管理Web客戶端 |
集群部署、分布式緩存 | |
|
保險公估管理 |
保險公估Web客戶端 |
集群部署、分布式緩存 | |
|
運維產(chǎn)品管理 |
產(chǎn)品管理Web客戶端 |
集群部署、分布式緩存 | |
|
報表及財務統(tǒng)計 |
報表及財務統(tǒng)計Web客戶端 |
集群部署、分布式緩存 | |
|
公共服務 |
運維產(chǎn)品管理、Web前端產(chǎn)品訪問 |
產(chǎn)品服務 |
集群部署、分布式緩存 |
|
電子商務或代理人訂單管理 |
訂單服務 |
集群部署、分布式緩存 | |
|
電子商務或代理人等涉及財務操作 |
總賬服務 |
集群部署、分布式緩存 | |
|
報表及財務統(tǒng)計 |
報表服務 |
集群部署、分布式緩存 | |
|
業(yè)務服務 |
B2C電子商務網(wǎng)站及手機客戶端個人賬戶 |
B2C個人賬戶服務 |
集群部署、分布式緩存 |
|
代理人管理 |
代理人管理服務 |
集群部署、分布式緩存 | |
|
案卷處理管理 |
案卷處理管理服務 |
集群部署、分布式緩存 | |
|
客戶管理 |
客戶管理服務 |
集群部署、分布式緩存 | |
|
保險公估管理 |
保險公估管理服務 |
集群部署、分布式緩存 | |
|
短險開放式接入 |
開放式接入平臺服務 |
集群部署、分布式緩存 | |
|
工具性服務 |
保險公司產(chǎn)品對接 |
產(chǎn)品對接服務 |
集群部署、消息隊列 |
|
在線支付 |
第三方支付服務 |
集群部署 | |
|
短信郵件通知 |
通知服務 |
集群部署、消息隊列 | |
|
性能監(jiān)控 |
日志采集服務 |
集群部署、消息隊列 | |
|
文件服務器 |
文件服務 |
集群部署、消息隊列 | |
|
服務授權與審計 |
服務授權與審計服務 |
集群部署 | |
|
分布式事務管理 |
分布式事務管理服務 |
集群部署 | |
|
定時任務管理 |
定時任務服務 |
集群部署 |
各個子系統(tǒng)及模塊的關系如下圖。
其中訂單服務、產(chǎn)品服務、財務服務、工具服務為基礎服務，其它各個業(yè)務模塊的服務會調(diào)用這些基礎服務。各個業(yè)務模塊的服務都是根據(jù)業(yè)務領域進行劃分的，同 一業(yè)務領域下實現(xiàn)技術不同會被劃分為兩個服務，比如產(chǎn)品展示和訂單原本屬于同一個大的領域，但其因為實現(xiàn)技術和質(zhì)量要求不同需要劃分為兩個服務。因為短險 接入量大，而且大部分是跟第三方合作接入，因此設計短險接入公共接口服務平臺處理大量短險訂單。
l 存儲及緩存架構
對于大型的高并發(fā)系統(tǒng)來講，最重要的當屬數(shù)據(jù)的架構。我們在前面也提到過，web系統(tǒng)業(yè)務處理模塊本身就可以集群部署，當用戶出現(xiàn)高并發(fā)時最先 遇到的瓶頸就是數(shù)據(jù)庫訪問的瓶頸。這也是我們說數(shù)據(jù)架構最為重要的原因。其實web系統(tǒng)是典型的“計算機信息系統(tǒng)”，也就是說一切以數(shù)據(jù)（信息）為基礎， 所有的功能都是圍繞著數(shù)據(jù)來的。這也是我們在這里說數(shù)據(jù)是web系統(tǒng)最重要的，很多公司在做少用戶量web系統(tǒng)時直接設計好數(shù)據(jù)庫就可以開發(fā)了。
按照上面劃分的業(yè)務領域我們設計多個數(shù)據(jù)庫，技術選項包括“是否讀寫分離”、“是否水平切分”及“路由鍵”。其中路由鍵是指在進行水平切分后，我們使用那個“標識”去查詢數(shù)據(jù)庫，一般來說會使用該業(yè)務領域聚合根對象的主鍵作為路由鍵。
|
數(shù)據(jù)庫 |
是否讀寫分離 |
是否水平切分 |
水平切分路由鍵 |
|
產(chǎn)品數(shù)據(jù)庫 |
是 |
||
|
訂單數(shù)據(jù)庫 |
是 |
客戶ID | |
|
公共數(shù)據(jù)庫（元數(shù)據(jù)、公共數(shù)據(jù)） |
是 |
||
|
客戶管理數(shù)據(jù)庫 |
是 |
客戶ID | |
|
案卷管理數(shù)據(jù)庫 |
是 |
客戶ID | |
|
代理人服務數(shù)據(jù)庫 |
是 |
代理人ID | |
|
B2C電子商務個人賬戶數(shù)據(jù)庫 |
是 |
客戶ID | |
|
保險公估數(shù)據(jù)庫 |
是 |
客戶ID | |
|
工具數(shù)據(jù)庫（短信、支付、文件） |
是 |
客戶ID | |
|
報表數(shù)據(jù)庫 |
是 |
||
|
日志采集服務數(shù)據(jù)庫 |
是 |
日志ID |
除工具數(shù)據(jù)庫外，其它的數(shù)據(jù)庫的劃分很容易理解。工具數(shù)據(jù)庫的數(shù)據(jù)也大都跟客戶或說用戶有關，比如“產(chǎn)品對接服務”，產(chǎn)品對接服務是指用戶在購買了保單 后，系統(tǒng)會自動對接到具體的保險公司接口去上傳保單信息和下載保單，所以水平切分數(shù)據(jù)庫時可以采用用戶ID作為路由鍵?！霸诰€支付”和“通知服務”也是類 似，都是保存用戶相關的數(shù)據(jù)，在線支付服務保存的是用戶在線支付的流水，通知服務保存的是發(fā)送給某用戶的短信或郵件。
另外在數(shù)據(jù)架構中我們也可以看到一個規(guī)律，就是使用了水平分庫的存儲結構就不能再使用讀寫分離，原因是防止存儲單元過度泛濫，因為使用了水平分庫之后，本 身也要為數(shù)據(jù)庫建立多個備份庫，這個時候如果再用讀寫分離需要建立一套只讀庫，數(shù)據(jù)庫的數(shù)量將增加一倍。使用了分庫后我們可以把熱點數(shù)據(jù)存儲在分布式緩存 中以起到讀寫分離類似的作用。
另外緩存也是存儲技術的一種，而且非常重要。從日常生活中我們也可以看到這一點。比如你要去購買一臺電腦，你會發(fā)現(xiàn)二級緩存和內(nèi)存大的價格高出很 多，如果你的顯卡顯存巨大，那將是頂級配置，發(fā)燒級配置。手機也是一樣，內(nèi)存大的手機速度明顯快，價格也高，如果內(nèi)存和持久化存儲都高，那也是頂級配置。 對于web系統(tǒng)也是一樣，有些大型web系統(tǒng)只要緩存處理的好，數(shù)據(jù)庫不需要分庫就可以承載億級的用戶，比如維基百科、新浪微博等。也因此，不管是電子商 務網(wǎng)站還是互聯(lián)網(wǎng)+大型應用，都會在它們的架構中看到緩存大量使用的情況。
從整個web系統(tǒng)的架構來看，緩存在兩個層面大量使用，分別是展示層和邏輯層，展示層通常使用高速的頁面緩存，邏輯層通常使用高并發(fā)的分布式緩存。當然有些分布式緩存工具既可以在邏輯層使用也可以在顯示層使用。
|
系統(tǒng) |
是否使用CDN |
是否使用高速緩存服務器（varnish） |
是否使用分布式緩存（redis） |
|
B2C電子商務網(wǎng)站 |
是 |
是 |
|
|
報表及財務統(tǒng)計Web端 |
是 |
||
|
B2C個人賬戶服務 |
是 | ||
|
代理人管理服務 |
是 | ||
|
案卷處理管理服務 |
是 | ||
|
客戶管理服務 |
是 | ||
|
保險公估管理服務 |
是 | ||
|
B2C個人賬戶服務 |
是 | ||
|
短險公共平臺服務 |
是 |
l 邏輯架構
在給出系統(tǒng)總體的邏輯架構前，我們先看看系統(tǒng)前端和服務層直接的關系。前端是客戶端，可以有多個客戶端，也可以有多種客戶端，比如手機端 （APP、WAP、微信）等?？蛻舳撕头罩g的架構是典型的MVC架構，V是客戶端，C就是spring mvc或servlet開發(fā)的控制層，對于Web應用V和C在開發(fā)角度是一個工程，剩下的M就是服務層。這是對于web系統(tǒng)來說的，對于app或者使用 html直接實現(xiàn)的客戶端，或者是.net實現(xiàn)的桌面客戶端，由于這些客戶端是單獨開發(fā)的，沒有控制層，因此需要增加一層“API 網(wǎng)關”作為這些客戶端的控制層。
圖中的服務組件就是指各個業(yè)務服務，這些服務可以看成是組件的概念。通常前端界面一個界面中需要的數(shù)據(jù)通常不僅僅來自于同一個服務，即使是來自于同 一個服務，那也來自于很多不同的接口，servlet或api 網(wǎng)關作為控制層，所起到的作用就是組合接口、組合數(shù)據(jù)，并處理接口間的事務性。另外服務組件也是分層的，圖中并沒有展現(xiàn)，一般可以分為3層，從低到高依次 是工具性服務組件、基礎業(yè)務層服務組件、業(yè)務層服務組件。前端界面的請求按照從高到底向下傳遞和處理請求。
按照職責、通用性、技術特性綜合考慮和計量，邏輯架構設計如下圖：
十幾個子系統(tǒng)分別分布在服務層、控制層、表現(xiàn)層（典型的三層架構）。實體層和接口訪問層雖然屬于“層”，但 它們并不單獨發(fā)布，而是使用Jar包類庫的方式提供給其它服務調(diào)用，是邏輯上的層。服務組件的構成大都是按照業(yè)務領域劃分的，只有一個除外，就是“B2C 網(wǎng)站”，B2C網(wǎng)站由于是面向終端用戶的高并發(fā)電子商務網(wǎng)站，為了處理高并發(fā)，我們將其拆分為兩個業(yè)務領域（也可以拆分成多個業(yè)務領域，看實際并發(fā)量）， 分別是用戶賬戶和產(chǎn)品。用戶瀏覽產(chǎn)品并購買，這是電子商務網(wǎng)站最基本的兩個領域。其中產(chǎn)品瀏覽等功能由更底層的產(chǎn)品服務提供，用戶賬戶功能由會員服務提 供。還有一些功能，比如推薦商品可能是由其它服務提供，這些可以在控制層直接組合這些服務。
l 服務架構
服務框架采用典型的“服務注冊表”模式，注冊表使用redis。服務組件在啟動時將自己注冊進服務注冊表，web服務器或api 網(wǎng)關在訪問服務時查詢服務注冊表得到服務的uri，然后調(diào)用某服務接口。
淘寶的dubbo使用的是zookeeper作為服務注冊表，之所以使用zookeeper，主要是使用它的負載均衡的功能。筆者認為restful接口 沒有必要使用zookeeper做負載均衡，可以使用nginx（負載均衡服務器都可以），所以沒必要選用動態(tài)的zookeeper作為注冊表，而是使用 “redis+心跳監(jiān)測”機制（redis也可以換為LDAP等）來完成服務注冊和監(jiān)控失效服務的功能。這個方案至少比dubbo簡單幾個數(shù)量級，簡單就 是硬道理。
在注冊服務時只需要注冊nginx服務器的IP以及服務描述信息即可。反觀dubbo還要注冊接口進注冊表，筆者認為這個沒必要，因為調(diào)用一個服務 接口的充分必要條件就是知道服務器的IP即可。至于調(diào)用什么服務接口，肯定在代碼里已經(jīng)寫死，目標服務器必定存在這個服務接口。將服務接口注冊進服務注冊 表如果是為了監(jiān)控審計服務的使用情況，那這個功能使用訪問日志來實現(xiàn)能做的更好。
總體的分布式拓補結構如下圖：
對于服務集群來講，看上去像是一個大哥（nginx）帶有眾多小弟的結構。訪問某服務群組只需要訪問其nginx服務器即可，這里nginx均采用高可用 方案，防止單臺nginx出現(xiàn)問題。至于高層服務調(diào)用底層服務也是直接訪問其服務器組的nginx。這個執(zhí)行的流程其實和日常生活中的概念很像，如公司內(nèi) 部的執(zhí)行流也是如此：老板分配任務給部門經(jīng)理，部門經(jīng)理分配任務給主管，主管分配任務給具體的個人（某單臺服務器）。領導們起到的作用也是負載均衡和監(jiān) 控，負載均衡就是把任務可以分配給多個人同時執(zhí)行（并且某個執(zhí)行失敗自動切換），監(jiān)控就不必說了就是監(jiān)控任務完成情況。在我們的方案里，會專門有個服務去 監(jiān)控所有服務器的執(zhí)行情況，很簡單的服務就可以做到。
l 關于分布式事務
如果研究一下EJB就會發(fā)現(xiàn)，EJB和微服務的架構基本相同，甚至所有面向服務（SCA、SOA等等）的架構都相差不大。很多人反對EJB，并 不是EJB不夠強大，而是它不夠簡單，它給項目帶來的復雜性甚至超過了項目本身（這也是筆者不建議使用dubbo框架的原因）。曾有人說過：你要么把事情 做的盡可能簡單，讓人挑不出毛??；要么把事情做的盡可能復雜，讓人找不出毛病，EJB就是后者。EJB分布式事務機制實現(xiàn)的很好，可惜的是這種“一刀切” 的事務機制，大大降低了web系統(tǒng)的性能，所以幾乎所有面向互聯(lián)網(wǎng)的應用都極少使用分布式事務，也就不會采用EJB?；ヂ?lián)網(wǎng)應用本身事務性操作并不多，一 些新聞、博客之類的網(wǎng)站甚至都不需要事務。另外一個方面，即使出現(xiàn)一個或兩個分布式事務應用場景，也可以通過其它手段解決，比如事件機制等等。
在之前的文章中我們也提到過對于分布式事務最佳的策略是盡量避免。如果避免不了將按以下方式實現(xiàn)。
1） 將分布式事務性操作封裝在一個服務中，這個服務使用XA或鏈式分布式事務管理。
2） 可以使用事件機制協(xié)調(diào)事務管理（具體做法就是事務失敗后發(fā)失敗事件到可持久化的消息隊列，然后需回滾操作的接口監(jiān)控此事件并執(zhí)行回滾）。
3） 使用自定義分布式事務管理器管理分布式事務。
筆者設想的自定義分布式事務管理器主要是封裝了流程及分布式事務相關功能，筆者將在其它文章專門討論。如圖所示，假設有一個事務需要依次調(diào)用 ABCDE五個接口，我們首先調(diào)用分布式事務管理接口創(chuàng)建這條“流程”的實例，實例中五個接口分別對應五個狀態(tài)，調(diào)用成功后將該接口對應的狀態(tài)設置為“成 功”，反之就是“失敗”，流程處理結束后，分布式事務檢查狀態(tài)，然后按照一定的策略調(diào)用失敗接口的反向操作接口去回滾數(shù)據(jù)（前提條件也是參與分布式事務操 作的接口要開發(fā)反向操作接口）。這既是一個簡單的流程引擎，也是一個分布式事務協(xié)調(diào)處理裝置，具體是否有必要做的復雜（比如處理并行流程），還要看實際環(huán) 境下分布式事務的情況，但筆者認為互聯(lián)網(wǎng)前端應用使用簡單流程應該足以應付。
l 開發(fā)架構
系統(tǒng)所需的工程，“[ ]”里面表示工程的名稱。
從圖中不難看出，我們將運維相關前端界面合并為一個前端系統(tǒng)，總體來講前端只有3種，B2C前端、APP前端、運維前端。把運維前端合并為一個 項目有利于加快前期的開發(fā)、部署的效率，在后期如果某子系統(tǒng)功能界面太多，可以將前端系統(tǒng)獨立，比如公估系統(tǒng)、客戶管理系統(tǒng)等，獨立后的系統(tǒng)需要使用單點 登錄，這樣就可以在各個系統(tǒng)之間免登陸切換。
開發(fā)環(huán)境：
編碼：UTF-8
工具：Myeclipse 10
SVN：Site-1.8.22
Web服務器：Tomcat7
JDK: JDK1.7、 Java EE 5
開發(fā)環(huán)境：Maven 3
開發(fā)技術選型：
表現(xiàn)層：Bootstrap+Html+Jquery
MVC框架：Spring MVC 3.2
安全框架：Spring security 3.2
Rest接口實現(xiàn)：Spring MVC Rest
持久層：Mybatis3.2
分布式緩存：Redis
數(shù)據(jù)庫：MySql 5.6
新聞名稱：互聯(lián)網(wǎng)保險O2O平臺微服務架構設計
當前鏈接：http://www.dlmjj.cn/article/dhoseih.html
