本文旨在通過對某省高速公路聯網收費營運管理平台的架構設計過程進行案例分析，描述架構設計的決策過程。
1.業務背景
某省的高速公路分為近百個路段，不同的路段歸屬不同的公司建設與營運，造成了車輛在跨越不同路段時，需要停經收費站繳費換卡，降低了高速公路的車輛通行效率。
随着資訊化技術的發展，将全省的高速公路聯網收費的條件成熟，改造後車輛在高速公路上行駛，在出發地上高速時領卡，到目的地出高速時全程隻需繳費一次。随着資訊化推進，未來車輛在全國範圍内高速公路通行，均隻需繳費一次。
為了适應全省聯網收費系統改造，迫切需要能集中對所有路段内的收費交易流水，高清卡口流水與圖像進行檢索，對交易流水進行重新拆分，對全省高速上車輛進行視訊監控與防逃費稽查。與以前最大的改進是資料由分散在各個路段系統，集中到省中心，并提供資訊共享查詢與統計分析報表。
2.關鍵需求
根據業務需求，各個層級系統間資料流向如下圖所示：
1) 全省路網約有100個路段中心；每個路段中心對應幾個到幾十個不等的收費站，每個收費站平均有4個入口車道，2個出口車道，合計全省約有2000個入口車道，1000個出口車道。
2) 車輛駛入收費站上高速時，産生交易入口流水和高清卡口資訊(包含圖像)；車輛從收費站出口繳費時産生交易出口流水資訊。各個車道中裝置的狀态資訊，定時發送到路段中心。
3) 各路段中心的資料需要及時彙總到省營運管理平台。車輛從收費站出口繳費時，收費站系統需要到省營運平台查詢該車輛對應的入口流水資料，以及高清卡扣流水資料，必要時還需要調取高清卡扣圖像進行肉眼比對。
4) 由省收費結算中心根據路段中心提供的交易流水進行費用拆分，并将拆分結果下發給省營運平台。省營運平台再将拆分結果下發給各個路段中心。
5) 省營運平台下發基礎費率、裝置控制指令、營運參數資訊到路段中心。路段中心再逐級下發到收費站。
對業務需求作進一步了解分析，發現系統具有如下特點：
1) 絕大多數場景對實時性要求不高。隻有查詢入口交易流水需要在1秒内響應。
2) 系統的并發通路量小。普通使用者數量小于2000。應用接口查詢并發數小于500。(在不考慮移動APP公衆應用的場景下)
3)複雜的業務邏輯少，系統需求集中于對資料進行查詢分析與資訊管理。隻有交易流水拆分規則較為複雜。
4) 查詢入口交易流水與查詢高清卡口流水要求7 * 24高可用性，否則收費站程式可能會無法對車輛進行收費計算處理，進行人工幹預會大大降低收費效率，易造成交通堵塞。
5)交易流水與高清卡口流水資料量大，日均在3千萬和2千萬以上。業務管理上要求對交易流水存檔一年時間以上，高清卡口流水3個月以上。每張高清卡口圖檔大小為200K，集中存儲在省平台将是巨大的容量。
3.重大決策
在系統設計過程中作重大決策，必須在分析清楚主要功能需求與品質性需求的基礎上，結合已有系統現狀，可支出經濟成本，技術團隊素質現狀，網絡環境，業務管理限制，工期要求等因素作出平衡性取舍。
在該系統的實施過程中，最大的現實限制是工期趕，牽涉到的工程實施方多，開發測試時間被壓縮到2個月内，必須把握好進度不能影響其它機關聯調測試。在架構設計時必須要結合技術團隊現有的知識技能儲備，新技術預研需要成本，同時還會引入風險，必須謹慎。
3.1高性能方面
3.1.1按業務劃分不同資料庫，對大表分區
由于整個系統的業務功能非常多，劃分為15個以上的子系統。對公共的使用者、組織機構、道路、收費站、基礎字典等資訊放在一個資料庫(Schema)中，對其它業務系統不能公用的分别劃分一個資料庫。對于重點業務功能專門劃分一個資料庫。為每一個業務系統配置設定一個獨立的資料庫使用者，便于使用與管理。
充分利用Oracle資料庫其分區表機制，對于入口流水，出口流水，高清卡口流水等大表按照日期(例如按照3天，10天)進行分區，確定每個分區内資料量在1億條以内。這樣在同一個分區内單表查詢時，隻要資料庫索引建立合理，伺服器資源充足，Oracle能保障在1秒内響應。同時在對曆史記錄做清理時可直接删除分區檔案，大資料量删除性能得到很大提升。
3.1.2使用記憶體資料庫提升查詢性能
雖然已經對資料庫作了優化，但由于車輛在收費出口繳費時，收費軟體均要查詢入口流水以及高清流水。如果并發查詢數上升，資料庫在處理并發查詢時就不一定能保證在1秒内響應了。該功能的響應性能，是使用者的痛點，直接決定了該項目被不被認可。
是以必須考慮引入NoSQL資料庫，将最近3天的流水資料加載到記憶體中，處理來自收費站的并發查詢請求，確定查詢在10~100毫秒内完成。
在我們的業務場景中，資料已經持久化在Oracle中，引入分布式緩存或NoSQL産品隻是為了直接從記憶體檢索資料提升性能。于是，對幾款開源的分布式緩存和記憶體資料庫産品做了大緻了解。
Memcached适合做分布式緩存，但它本身不提供檢索查詢功能。它将資料全部放在記憶體中，不實作檔案持久化機制。同時在叢集部署時，節點之間是不作通信的，一旦某個節點當機則該節點上資料全部丢失。要實作查詢檢索功能，應用開發的工作量會比較多，不适合我們的場景。
Redis與MongoDB都提供了持久化到檔案的機制，Redis的查詢性能優于MongoDB。但MongoDB在查詢API上實作了很多類似SQL語句查詢的便利功能，同時在叢集部署時它能自動實作資料分片，災難轉移，應用開發的工作量也要小一些。兩相比較，個人傾向于引入MongoDB的。但是苦于工期短，沒有人力與時間做深入的預研，如果研究的不夠深入，又會增加風險。
後來Vmware公司推薦一款叫GemFire的記憶體資料庫産品，稱在12306網站應用取得了不錯的效果。于是他們的售前就過來給我們洗腦，示範了一些成功案例，讓我們對這個産品增加了很大信心。讓我印象最深刻的是這個産品定位為記憶體計算平台解決方案，可以直接在資料節點進行計算(類似于在資料庫中預先定義好函數，在應用中進行調用)，再将計算的結果合并後傳回給應用，這就是分布式計算的意思了。
由于商業産品可以提供可靠性保障，又能節約我們的人力投入，項目預算也足夠，何樂而不為。後面的實施情況證明，這個産品性能與穩定性還是不錯的，能将查詢時間降低到幾十毫秒級，當然也比較耗費記憶體與CPU(3台伺服器，每台10G記憶體起)。
3.1.3采購高配置硬體網絡裝置
網際網路應用因為伺服器規模龐大，為了節約成本必須去IOE化，大量采用廉價伺服器與開源軟體。企業應用因為規模小，相比之下，伺服器資源沒有那麼大的規模，高配置的硬體成本企業還能負擔。該項目中采用IBM伺服器，EMC存儲，思科的交換機，F5硬負載均衡器。
這種通過硬體來提升性能的方式，在成本允許的條件下，是可以節省力氣的。采用了專用存儲，其自身已經做了備援機制，提供了災備的解決方案。應用層面就不用再去考慮資料災備的問題。硬碟壞了，就換個新硬碟插上去就好了，因為做了RAID10/5已經保證了資料不丢失。若等研究完幾個月的HDFS，終于敢用到項目裡面，項目工期已經結束了。
3.2可靠性與高可用方面
3.2.1采用商用中間件提高可靠性
采用Oracle資料庫RAC叢集，提供了資料庫層面的高可用性。
采用IBM Websphere來部署重要業務系統，例如接口查詢子系統。它自身提供了軟負載均衡和叢集功能，可通過Web界面來對應用伺服器集中管理與監控。這樣應用層的高可用也得到了解決。(在我們的重要業務場景中，接口查詢是無狀态的，會話不需要進行複制，也就是采用粘連性會話即可)。
3.2.2采用消息中間件進行通信
業務場景中，省營運平台還需要下發控制指令，營運參數等資訊到各個路段。同時路段上傳的大量流水資料，如果先緩沖到消息伺服器中，則拆分子系統可以直接從消息伺服器讀取資料，多線程處理或者單線程部署多份，部署模式非常靈活。同時引入消息中間件還可以降低各個子系統的耦合度。
開源的有ActiveMQ、RabbitMQ，商用的也了解了下IBM MQ。比較詫異的是IBM MQ的并發性能測試名額非常差，比前兩者都弱。
最終我們采用了開源的RabbitMQ，看重的是它的并發性能和對于高可用以及災難轉移的支援。目前将服務端部署在省營運平台，路段隻使用用戶端進行連接配接。這樣也是考慮到部署與運維成本，路段的各合作方技術水準有限，分散部署不利于故障診斷。
3.3擴充性方面
3.3.1劃分為多個子系統解耦
一般大點的系統都有必要劃分成多個子系統，易于團隊并行開發，部署更新也快。核心業務系統，我們可以叢集多部署一些執行個體，多給點硬體資源。不重要的業務系統，配置管理類的，甚至單執行個體部署，直接部署到Tomcat上。同時有些背景服務，本身就是一個Java程序，與資料庫相關的，設計時就限定了隻能部署一個執行個體。
子系統和子系統之間，可以通過消息伺服器來解耦，一個子系統當機，不會影響另外的子系統運作。
在整個系統的實施過程中，我們引入了Portal門戶、統一使用者管理、單點登入來進行不同Web之間頁面級的內建。
3.4運維方面
3.4.1基礎設施采用虛拟化技術便于運維管理
借鑒公司私有雲建設的成功經驗(基于Vmware的産品元件)，我們認為可以通過對伺服器進行虛拟化來充分利用資源，降低成本，也便于集中進行運維管理。
在實施過程中，我們将3台豪華配置伺服器虛拟出近百台伺服器，同時為Oracle做叢集留下了2台較高配置的伺服器。
如果不進行虛拟化，可能需要更多的伺服器，同時多個應用部署在一台伺服器上，運維監控起來非常麻煩。虛拟化後，可以根據業務場景動态對伺服器資源進行配置設定，這也是雲計算機的特點。
值得注意的是，在虛拟機上部署叢集應用時，要確定把節點分布到不同的實體機器上，這樣才能真正保證高可用性。
3.5綜合考量方面
3.5.1高清圖檔不集中存儲到省平台
前文提到，高清圖檔資料量大，若集中存儲到省平台耗費存儲容量。用專用存儲來存這些圖檔，有些浪費。若将圖像從路段傳輸到省平台，也将浪費大量的通信帶寬。
實際業務場景中，收費站隻在某些特定場景才調用圖像查詢接口，通路量并不大。也就是說隻有非常少的圖檔真正需要被讀取。于是我們定義了HTTP接口規範，由路段提供服務端實作，省平台負責調用。因為HTTP接口簡單易于實作，給各路段增加的工作量很小。
也就是說，這裡我們犧牲了圖像的查詢性能，節約了帶寬與存儲。
3.5.2直接從路段中間資料庫抽取資料
已有系統的接口方式都是通過中間資料庫來實作的，考慮到引入新的接口方式，路段太多，對合作公司的技術能力與內建工作量都将大大增加。于是我們遵循了以前的方式，定義了中間表規範，由各個路段負責提供一套中間資料庫，往其中寫資料。
考慮到現有系統各種類型的資料庫都存在，于是我們采用了開源資料抽取工具Kettle來進行資料遷移。同時資料庫抽取的資料量較大，各種不同的業務表結構，如果開發接口程式去實作，則工作量會很大，穩定性也是難以保證。
為了保證資料抽取的效率，每10個路段分為一組，部署一套Kettle抽取程式去做搬遷。
也就是說，這裡我們考慮到現實技術條件，用最簡單适用的方式去實作業務功能。實際實施下來，這種資料抽取的方式為項目節省了很多時間。
3.5.3子系統各自緩存使用者資訊
使用者與組織機構資訊是存儲在公用資料庫中的。但是使用者的角色、可通路的資源、以及資源URL等資訊在各個子系統中是不一樣的。為了提升性能，各個子系統将使用者群組織機構資訊緩存到記憶體中，對于授權與通路控制這塊的功能，通過代碼級别(class檔案或者Jar包)的重用實作複用。
實際上，如果子系統數量越來越多，是可以把使用者認證與授權以及查詢使用者資訊這塊的功能服務化，包裝成HTTP REST服務或RPC調用服務。考慮到項目的工期，以及開發的成本，我們并沒有這樣為了技術而技術，直接通過資料庫通路作接口和緩存使用者資訊來提升性能。
注意這裡對使用者資訊作緩存時一定要設定時效性，例如5分鐘。
4.整體架構
下章節表述的是系統的整體架構，用來說明各個子系統及業務元件的劃分與所處的層次，還未細化到足以指導開發工作的程度。
4.1邏輯架構
1) 基礎設施層為伺服器、交換機、路由器、防火牆、安全防護、錄音帶備份等硬體網絡裝置。還包括虛拟化軟體與作業系統。
2)中間件層為商用的資料庫、應用伺服器、記憶體資料庫以及開源的消息中間件、資料抽取軟體。
3) 服務元件層為可複用的業務元件，二次開發架構。
4)業務應用層為各個業務子系統。
4.2元件依賴
1) Kettle将抽取到的流水資料存入資料庫，同時寫入到消息伺服器RabbitMQ。
2)GemFire從流水資料庫裝載最近幾天的流水資料到記憶體。
3)接口查詢服務調用GemFire的用戶端API查詢入口流水。
4)交易流水拆分服務從消息伺服器讀取資料進行處理，将拆分結果寫入業務資料庫。
5) 各個Web子業務系統需要依賴CAS服務實作單點登入。
6)由統一使用者管理系統集中管理使用者與組織機構資訊。
7)單點登入服務從使用者資料庫查詢使用者資訊以實作集中認證。
8)Portal門戶将各個Web子業務系統內建起來。
4.3實體部署
4.4子系統設計
由于子系統設計會涉及到公司具體的業務，這裡不做進一步描述。設計時隻要按照通用功能抽取，不同業務功能劃分不同子系統原則即可。
通常子系統設計中需要描述清楚具體的功能子產品設計，業務處理流程，開發包劃分，領域模型，關鍵的類圖，内部接口及外部接口的規範。
5.結語
玩過即時戰略類電子遊戲的朋友，都知道什麼時候采礦，幾個農民采一堆最大效率，什麼時候造什麼兵種來克制對方，什麼時候偵查與擴張，作戰時候多兵種如何擺陣配合才能發揮最佳優勢。這裡不妨作一下類比，架構設計就是實施戰略的過程，具體的技術是兵種武器，模式理論就是各種戰術。