1 產品技術方案
1.1 技術方案概述
1.1.1 系統功能架構
在銀行電商平臺中，包括各總分支行的管理人員、各家合作商戶、會員、物流公司、支付平臺等主要角色，通過電商平臺進行信息流、資金流的交互，並藉助物流公司提供的物流服務，來完電商平臺的購物活動。
電商平臺從功能架構上來說，可以用如下的功能架構示意圖表示：
1.1.2 系統技術架構
上圖可以清晰的瞭解到整個系統的層次劃分，系統從最底部的EIS層（圖中爲數據庫、分佈式緩存系統、其他與電子商務交互的系統）開始，經由業務邏輯層（基礎組件、產品組件、客戶化組件）一層一層的向上提供接口服務，最終實現按業務要求的操作界面和其他系統接口。各層次專注於自身功能的接口實現，整個層次保持相對的穩定。系統各組件之間保持接口穩定性，可在各個層次、各個組件內部進行優化的策略，在不影響整個業務的前提下，不斷的完善和改進。
1.2 技術方案設計原則
1.2.1 投資保護性原則
銀行B2C商城技術方案充分考慮目前已實施的業務系統的實際情況，充分利用原系統資源，在實現新系統建設同時保護原有系統的投資。
任何一個系統的建設，如果不能合理和有效地利用以前的投資，這樣的系統應該算不了成功或絕對的成功。因此，在進行該系統建設時，充分考慮如何利用以前的信息系統、網絡和其他設備，並對以前實施的應用系統進行整合，一方面保證原有的設備可以重新利用，另一方面保證以前的應用重獲新生。在真正意義上做到既完成了新系統的建設又保護了原有設備和系統的投資。
1.2.2 安全性與可靠性原則
考慮到電子商務平臺項目建設的安全性、可靠性的需求，在系統設計中，應充分注意系統的安全性和可靠性，採用多種安全防範技術和措施，保障系統的信息安全，保障系統長期穩定可靠運行，同時在系統設計要充分考慮系統運行性能，達到“簡便、實用、快捷、安全、準確”的目的。
1.2.3 先進性原則
由於IT技術發展的速度驚人，在電子商務項目進行系統總體規劃時，我們選擇業界到目前爲止最爲先進和成熟的技術作爲整個系統的技術架構，以保證系統有不斷髮展和擴充的餘地。 系統總體設計的先進性原則主要體現在以下幾個方面：
平臺的分層架構，本着各層次之間松耦合，各層次內部高內聚的設計原則，使得平臺具有良好的擴展性和可移植性。
平臺的設計中利用先進的面向對象技術、設計模式和可插入組件技術來提高軟件的通用性、複用性和擴展性。
1.3 技術方案組件
平臺核心組件和應用組件如下圖所示：
下面我們將逐一介紹技術平臺的基礎技術組件和產品的核心業務組件。
1.3.1 搜索引擎組件
在電商平臺中，商品搜索服務佔有舉足輕重的位置，直接影響客戶購物體驗，產品提供了專業的商品搜索服務引擎，支持多維搜索。
搜索可以按照各種方式進行排序：按產品最終提供者,按產品類別,按產品期限,按產品風險級別（金融類產品）等。
支持搜索過濾：按產品最終提供者,按產品類別,按產品期限,按產品風險級別。
支持分面搜索，客戶根據自己的需要選取不同的分面（如：商品品牌, 商品類別, 商品價格）進行篩選；構建自己的搜索路徑，並且可以隨時擴大和縮小結果範圍；避免了無搜索結果的情況，在搜索選項內包含的結果數量，給用戶良好的操作前提示，增加用戶體驗。
搜索支持關鍵字模糊匹配和智能提示，支持組合關鍵詞搜索。
向客戶推薦搜索最多的商品，關注最多的商品，購買最多的商品等，爲客戶消費購物決策提供支持。
平臺支持中文全文檢索，支持主流格式文檔（PDF、WORD、HTML等）。
支持分面搜索，基於標準的開放接口，高速建立索引，高性能搜索，支持分佈式搜索，處理海量數據 ，易管理。
多種文檔格式：
Plain text
Rich Text Format
XML
HTML
Microsoft Word / Excel / Powerpoint
Adobe PDF
特性：
給特定的自定義結構內容置頂索引,可以自定義搜索的Field,進行定義和配置。
集成了 snowball stemmer 包,可以對多種拉丁語進行分詞。
可以對生成的內容片斷進行關鍵詞高亮顯示。
提供商品比價功能：通過授權後對第三方電子商務網站進行爬蟲，根據設定的分類、品牌、名字設定權重進行頁面分析，然後再調用搜索引擎創建索引。
1.3.2 工作流引擎組件
在電子商務平臺中，涉及到多種業務流程的管理，如商品發佈流程、資訊/公告等信息發佈流程等。在產品中，這些業務流程都納入到統一的電子商務工作流引擎中進行統一管理。工作流引擎提供工作流的配置定義功能，使得工作流程可依據銀行電商平臺的需求進行靈活的定義。
在工作流引擎的使用中首先需要業務人員定義好業務流程（如：vsd格式的流程圖），再由技術人員通過流程設計器設計出相應的流程定義文件（.bpmn20.xml），及生成對應的流程定義圖片(.jpg)。
在工作流引擎的內部實例對象中，一個流程實例（InstProcess）由一個流程實例變量（InstProcessVariable）、1個或多個活動實例（InstActivity）、1個或多個轉移實例（InstTransition）組成，而一個活動實例包括一個活動實例變量（InstActivityVariable）和1個或多個工作項實例（Workitem）組成。
啓動工作流引擎，成功部署流程定義文件，由操作人員觸發並啓動流程，此時一個流程定義的實例便以生成，流程啓動需將啓動流程的操作人員（Initiator）放入流程實例中，該變量在流程中的任何環節都可獲取，直至流程結束後才失效；流程啓動也可將業務數據、角色等信息存放在流程變量中（Map）。
在流程實例中任務主要分爲用戶任務（UserTask）和服務任務（ServiceTask），二者主要責任爲：用戶任務需要操作員參與纔可完成，主要包括4種狀態：未簽收、辦理中、運行中、已完成；服務任務則無需人工參與，當流程走到該節點時由引擎調用業務系統的服務組件完成任務。
工作流引擎存儲庫（Repository）:存放流程定義、流程的資源（圖片、規則等）。
工作流引擎運行庫（Runtime）:這個運行時的庫存儲着流程變量、用戶任務、變量、作業等內的運行時的數據，運行時的庫存儲流程實例執行期間的運行時數據，當流程實例結束時，將刪除這些記錄。這就保持了這些運行時庫小且快。
工作流引擎歷史庫（History）: 包含着歷史的相關數據，如：結束的流程實例、變量、任務、等等。
工作流引擎的歷史歸檔級別分爲四種：None、Acitivity、Audit、Full；
1.3.3 規則引擎組件
在電商平臺的設計實現上需要設計應用很多規則，譬如：商品費率折扣規則、商品組合設置的規則、商品各類排行榜規則等。這些規則在整個運營過程中需要進行動態的調整、設置。
在銀行產品中，以上這些規則的定義和執行都通過規則引擎來執行，規則引擎包含了規則的定義和規則的計算執行兩部分內容：
在銀行產品中的規則引擎有以下特點：
規則參數可配置
支持預定義的規則模板
支持基於腳本語言定義的規則定義（可支持二次開發）
電商平臺運營管理人員可以通過運營中心提供的配置界面，進行規則的可視化配置。下圖是規則引擎的結構示意：
1.3.4 調度引擎組件
調度引擎主要實現定時任務的自動調度，在電商平臺中主要完成批處理任務、定時任務的調度執行如：生成清算報表、日終對賬等任務。下圖是調度引擎組件的示意圖：
任務調度引擎將任務的定義與任務的調度相分離。調度引擎支持獨立的應用部署，可以支持大任務量併發處理。任務的定義支持配置文件方式和數據庫方式存儲。
產品的調度服務引擎的結構設計圖如下所示：
由上圖可看到，計劃任務模塊由Schedule Manager統一對任務進行調度，而任務大致分爲簡單週期（simple）任務和複雜週期（cron）任務。其中複雜週期任務又可能需要輔助有工作日定義。
定時服務組件主要有以下4個模塊組成：
Schedule Manager
是整個計劃任務的管理員角色，以EMP服務(Service)形式根據外部XML配置對一系列任務進行安排和調度。實質上是一個接口，在其之上採用JDK Timer、commonj、Quartz等具體方式進行實現。
簡單週期任務（simple）
按照一定週期反覆執行任務，可設定週期、延時、重複次數等。
複雜週期任務（cron）
在每月、每週或每天的某個時刻執行任務，可設定條件、工作日等。並可根據工作日服務過濾或增加工作日管理。
常用任務實現
執行一個類或一個ActionProcess等產品常用任務的實現。
執行一個類是指可調用任意一個java類中的方法來完成一個任務。
執行一個ActionProcess是調用一個產品中的業務邏輯處理對象。
1.3.5 內容管理組件
在電商平臺中包括商品管理、營銷活動管理、廣告等管理等業務都需要涉及內容的製作和發佈管理，在產品中，通過內容管理組件實現對電商平臺的內容製作和發佈管理。
內容管理基於強大的Velocity作爲模板引擎， 把內容（Content）的製作和內容的的展現形式（網頁）徹底分離開來。網頁的展現表現形式及內容組織方式由模板文件來確定，網頁的內容則存儲於數據庫中。這樣的分離方式所帶來的好處是很明顯的，頁面的展現形式可以變的更加靈活，而網站內容可以得到重複的利用，這樣將大大降低了電商平臺的的運維成本。這樣即便網上商城需要對界面改版或升級，也不需要重新構建已有的數據。
另外通過發佈管理，可以輕鬆將你的網站從內容管理服務器發佈到WEB服務器。基本的功能包括：
支持靜態文件發佈模式，自動將內容數據通過靜態文件進行保存發佈到服務器上，減少訪問對服務器的壓力。
支持多任務發佈；
一個站點發布到多臺服務器；
發佈方式設置（FTP/COPY）；
不同站點的不同發佈任務；
發佈條件過濾；
1.3.6 社會化網絡服務組件
社會化網絡是一個可以展示自我（Indentity），維持和拓展人際圈子（relationships），並且有很多事情（activity）可以做的網絡服務。社會化網絡服務廣義上涵蓋了博客、微博、WIKI等功能。社會化網絡服務組件給電子商務平臺客戶提供了一個可以展示自我，維持和拓展人際關係的平臺，可以起到增加電子商務網站的粘性和推廣網站的知名度的作用。社會化網絡涵蓋了關係、互動機制、用戶需求三方面內容，如下圖所示：
如下圖所示：社會化網絡服務組件設計爲核心和非核心兩部分，核心部分涉及到個人數據存儲、好友關係、好友動態以及包括即時通信等在內的一些通用功能；非核心部分涉及到圈子、羣組、論壇、App應用以及開放平臺等需要具體定製實現的功能。
社會化網絡服務組件基於通用的推拉結合的方式實現，即好友動態以推送的方式發佈給所有關注的人（主體），如下圖所示：
推拉模式之推
客戶（主體）以拉的方式可以主動查看所有好友的動態，如下圖所示：
1.3.7 數據集成/交互/報文處理引擎組件
在電商平臺設計實現上，可能需要對多個外圍系統（支付網關、短信平臺等）系統進行數據通訊和交易的請求處理，i2Shopping產品基於i2FSP平臺提供的多種外圍系統的交易適配器，根據不同的交易請求，在交易引擎中定製業務邏輯應該訪問的一組後臺交易適配器，完成一次系統間的請求交互。
後臺交易適配器包含兩部分：交易報文格式化/解析和通訊協議適配器，在產品包中提供了支持多種常用通訊協議的通訊協議適配器。對於交易報文的格式化/解析組件，在產品包中包含了多種標準報文協議的支持，如：定長，XML,JSON,ISO8583報文等。交易適配器封裝了對外圍系統交易的請求處理。
1.3.8 權限管理組件
技術平臺提供出色的權限管理功能，通過管理角色的添加、權限的設置、權限的繼承功能與後臺管理人員、後臺管理功能結合在一起。權限管理達到了配置靈活，又安全可靠目的，對於全行級別的電子商務平臺而言，可以按照總分支行來劃分崗位和角色。從控制力度來看，可以將權限管理分爲兩大類：功能級權限管理和數據級權限管理。技術平臺通過不同手段來實現這兩類權限管理：
功能級權限管理技術實現
技術平臺功能權限管理，使用基於角色訪問控制技術RBAC（Role Based Access Control），該技術模型如下圖示：
數據級權限管理技術實現
數據級權限管理涉及到如何給不同的人分配不同的查詢數據權限、如何給不同的人分配不同的數據操作權限的問題，i2FSP技術平臺通過規則引擎配置來實現數據級權限管理和業務的松耦合。例如：領導查詢數據範圍和普通員工查詢的數據範圍不同，客戶經理能夠查詢客戶聯繫方式字段，而其他人不能查看客戶聯繫方式字段等等。
1.3.9 異常處理組件
技術平臺提供了統一的異常處理組件，該模塊以面向切面（AOP）的方式植入至系統的應用處理的各個環節，實現了異常處理與業務處理的分離。通過統一的異常處理機制，確保了系統中所有的異常信息均能夠被捕獲，並根據業務以及審計的需要進行相應的記錄和處理。
異常處理模塊對於捕獲的異常，通常採用信息記錄的方式記錄至相應的存儲結構中（比如日誌文件、數據庫表等），平臺提供了靈活的異常處理配置，可以在運行時調整異常處理的策略，比如異常信息記錄的級別，異常處理的方式等。
異常處理處理組件如下圖所示：
1.3.10 審計日誌組件
審計日誌主要用來跟蹤功能操作的主體，客體，發生的時間，並定期產生審計報表。平臺以面向切面的方式插入到各個業務功能中。通過配置文件或者數據庫的方式定義需要審計的功能和要素，通過暴露接口給各個業務功能，由該業務功能實現者產生審計日誌的數據並配置審計日誌的切面連接點，當業務功能被執行時由審計日誌組件產生審計日誌時間，相應的審計日誌監聽器會接收到該時間，並將該事件持久化到數據庫中。
技術平臺採用面向切面的設計思想和異步處理的機制，審計日誌的處理和業務功能實現了松耦合和併發處理。如下圖所示：
1.3.11 緩存組件
對於對於數據密集型的B2C電子商務類應用，緩存組件可以極大提高系統的吞吐量並減少請求響應時間。技術平臺的緩存組件由是本地的Java的分佈式緩存和遠地的Memecached集中式緩存結合而成。對於只讀類型的數據，例如系統中的類似省份城市的相對穩定的數據，產品採用基於Java的本地緩存，具有快速、簡單、多種緩存策略（FIFO、LRU、LFU）的特性，通過配置的方式針對接口的方法調用實現內存、硬盤的二級緩存機制，無需考慮擔心內存不足導致緩存失效的問題，此外緩存數據還可以在JVM虛擬機重啓的過程中持久化到硬盤中以防止緩存數據的意外丟失；對於讀寫型數據，例如系統中類似於商品描述、商品價格等頻繁變動的數據，產品採用基於Memcached的遠地集中式緩存，Memecached使用內存管理數據，通過緩存數據庫查詢或者與其他系統交互返回的結果，減少與數據庫或者其他系統交互的次數，減少響應時間，此外Memecached使用客戶端實現負載均衡，可支持緩存服務器水平和垂直擴展。技術平臺的緩存框架基於AOP實現了對兩種緩存的封裝，對於業務邏輯實現者可以透明的使用方法調用返回的數據，而無需關心數據本身是否來自緩存。下圖爲緩存框架的示意圖：
1.3.12 通用會話組件
HTTP協議是無狀態的，但通過Session機制，就能把無狀態的變成有狀態的。Session的功能就是保存HTTP請求之間的狀態數據；有了session的支持，就很容易實現諸如用戶登錄、購物車等網站功能。
會話保持可以由客戶端和服務器端來分別實現，客戶端使用Cookie保存會話數據，服務器端使用Session保持會話數據。但使用服務器端保持會話會有諸多限制：如容量限制、會話複製的限制等等。爲了確保電商平臺良好的伸縮行和可擴展性，i2Shopping提供了同時支持Cookie和Session的會話組件。
通過精心設計，會話組件良好的伸縮性和可擴展性表現在以下幾個方面：
• 使用標準的HttpSession接口，而不是增加新的API。這樣任何WEB應用，都可以輕易在兩種不同的session機制之間切換。
• 應用程序不需要知道session中的對象是被保存到了cookie中還是別的什麼地方。
• Session框架可以把同一個Session中的不同的對象分別保存到不同的地方去，應用程序同樣不需要關心這些。例如，把一般信息放到cookie中，關鍵信息放到DB中。甚至同是cookie，也有持久和臨時之分，有生命期長短之分。
通用會話組件的示意圖如下所示：
1.3.13 安全組件
安全組件面向Web應用安全中常見的腳本注入（Injection）、跨站腳本攻擊（XSS）、跨站請求僞造（CSRF）、不安全的直接對象引用等，構建了一道可定製化、可監控的安全防線。目前保護Web應用安全的兩種方式有兩種方式：黑名單機制（阻止含有非法內容的請求）和白名單機制（允許含有安全內容的請求）。Web應用安全有兩部分組成：Web應用安全檢測插件（可插入、易擴展）和Web應用安全威脅處理插件（可追溯、實時性）。
Web應用安全有兩部分組成
Web應用安全檢查處理流程
1.4 系統高穩定性、高容量、高性能
1.4.1 高穩定性、高容量、高性能方案
高穩定性、高容量、高性能主要表現在系統的可靠性、吞吐性能、可擴展性、負載均衡能力和系統伸縮能力等方面。本方案電子商務產品進行過全面、大量、嚴格的性能測試，應用系統的各項性能指標表現優異。
1.4.1.1 高穩定性
電商平臺的高穩定性，能保證網絡系統中各主機24小時正常運行，並保證系統在訪問高峯期能做到正常工作且快速響應。系統提供數據、進程的備份和恢復機制，防止各種可能的問題而造成損失。
本方案建議使用標準的J2EE應用服務器以及成熟的i2Shopping 產品，以下幾個方面確保了平臺系統的高穩定性：
系統採用成熟的平臺，最大程度上保證了系統的穩定性。
基於的開發流程是成熟穩定的：基於的系統的開發，採用參數化定製的方式，輔以集成開發工具IDE。因此基於i2Shopping的系統的開發是一個規範的開發過程。
平臺自身的會話重建技術，保證了客戶信息的不可丟失性，從數據層面保障了系統的穩定性。
λ 支持集羣部署，既能充分保證電商平臺具有強勁的處理能力，又能在系統關鍵處理環節上避免單點故障。
支持7天×24小時不間斷平穩運行，系統可用性達到99.999%，生產運行和維護互不影響。
平臺支持橫向擴展（增加服務器數量）和縱向擴展（增加單臺服務器的硬件配置），並支持聯機擴展。
完善的交易日誌處理，保障了交易信息的可恢復性和問題的可定位特性。
準確的交易定位和監測，通過系統跟蹤手段，能夠準確、快速的定位和分析問題、解決問題，保證系統的正常運行。
有效的監控平臺，實現對網絡節點（設備）和應用系統的實時、全面的監控和預警。
監控平臺實時的在線維護能力，有效促進了對系統問題的處理能力和系統恢復能力。
嚴密的安全手段，屏蔽外來干擾。
1.4.1.2 高容量
系統本身不對註冊用戶容量進行限制，註冊用戶容量的增長對應用系統的影響主要集中在當註冊用戶容量增加後，相關數據表操作的性能降低，因此這種影響的技術解決辦法主要集中在數據庫處理層面的調整和優化，因此如何保障數據庫處理層面的併發讀寫和可擴展性尤爲重要，在多年實施經驗中我們積累了對數據庫處理層面的調整和優化的最佳實踐–數據庫切分。
數據庫切分的基本思想就要把一個數據庫切分成多個部分放到不同的數據庫上，從而緩解單一數據庫的性能問題。
對於海量數據的數據庫，如果是因爲表多而數據多，這時候適合使用垂直切分，即把關係緊密（比如同一模塊）的表切分出來放在一個數據庫實例上（如系統配置參數相關表）。如果表並不多，但每張表（如用戶表和訂單表）的數據非常多，這時候適合水平切分，即把表的數據按某種規則（比如按ID散列）切分到多個數據庫實例上。當然，現實中更多是這兩種情況混雜在一起，這時候需要根據實際情況做出選擇，也可能會綜合使用垂直與水平切分，從而將原有數據庫切分成類似矩陣一樣可以無限擴充的數據庫陣列。
垂直切分的最大特點就是規則簡單，實施也更爲方便，尤其適合各業務之間的耦合度非常低，相互影響很小，業務邏輯非常清晰的系統。在這種系統中，可以很容易做到將不同業
務模塊所使用的表分拆到不同的數據庫中。根據不同的表來進行拆分，對應用程序的影響也更小，拆分規則也會比較簡單清晰。水平切分於垂直切分相比，相對來說稍微複雜一些。因爲要將同一個表中的不同數據拆分到不同的數據庫中，對於應用程序來說，拆分規則本身就較根據表名來拆分更爲複雜，後期的數據維護也會更爲複雜一些。
產品對切分後的多個數據庫提供了統一的數據訪問層（DAL），屏蔽了切分後的數據庫訪問的複雜性。
1.4.1.3 高性能
系統響應時間是指客戶端接發起用戶請求到客戶端接收到服務器發來的數據所需的時間。響應時間直接影響用戶的購物體驗，從一定程度上決定了用戶對於該網站的認可度。系統採用各種技術：分層緩存、壓縮傳輸，集羣等提高性能，並大量採用局部刷新、異步加載等，致力於最大程度提高用戶購物體驗。
我們從以下兩個大的方面降低系統響應時間：
多維度緩存：從商城整體架構上來說，選擇合適的緩存策略能帶來性能的極大提升，產品提供兩個維度的緩存。
緩存的位置：從緩存使用者的角度來定義的，本地緩存是進程內緩存，適合於只讀數據，遠地緩存是進程外緩存，適合於讀寫數據。
緩存的內容：從緩存中存放的具體內容來定義的，視圖緩存、處理結果緩存、數據緩存分別對應於架構體系的視圖層、業務邏輯層和數據訪問層。
基於事件驅動的異步處理: 事件驅動模型可以通過併發提高系統的容量和性能。事件驅動有以下三個要素：事件源：產生事件的源體；監聽器：能夠接收事件源通知的對象；事件處理程序：用於處理事件的對象。
產品針對事件驅動模型提供了三種實現：JMS、ActiveMQ、組件容器事件發佈器和監聽器，商城的發送郵件、手機短信均採用事件驅動的方式實現。此外產品在對系統資源的使用方面（如端口監聽和文件讀寫）採用了非阻塞API，如日終對賬文件的讀取使用NIO的Channel和Buffer。
此外，本方案還將採用了以下方式確保系統的高效運行：
平臺化總控改造，規範和簡化了交易請求機制，提升了交易的處理能力。
對現有系統的系統資源的使用進行了調整，規範系統資源的合理調度。
數據（數據字典和系統參數，以及頻繁調度的靜態交易數據）高速緩衝技術，有效的減少系統資源的佔用，提升系統處理速度。
系統中交易流程、組件等對象實例的複用，減少了內存的開銷和對象創建、銷燬的過程，節省了時間，提升了速度。
系統對有限的系統資源（如數據庫資源、通信資源等）採用緩衝池技術管理，保障系統對資源的快速調度。
多線程處理技術的使用，提升了交易請求的併發度和處理速度。
系統中，對大部分交易對象和組件實例進行高速緩存處理，大大的減少了在對象創建上浪費的時間和資源。
配置參數化文件的緩存處理，配置文件僅在系統啓動時的訪問磁盤，減少系統IO處理，有效的提升了處理速度。
本系統自有的會話管理，採用可定製管理模式，提升了系統的處理效率。
1.4.2 性能指標
結合銀行電商平臺項目的性能需求設計，預計項目投產半年內，運營方根據經驗預估註冊用戶數在200萬的情況下，日均訪問量120萬人次/日；預計未來一年內，註冊用戶在500萬的情況下，日均訪問量300萬/日；預計未來三年內，註冊用戶在1000萬的情況下，日均訪問量600萬/日。以下列表爲按照需求設計計算出的預期指標：
指標數據計算說明：
瀏覽頁面數量=訪問人次*8
訂單轉化數=訪問人次*1%
最大併發數=會員人數*活躍比例0.03*8*0.8*10000/(5*3600)
在線人數=5分鐘內在線訪問的UV數，按照80%的訪問量發生在20%時間內計算產品在近期由IBM實施的性能測試的中性能表現良好，下表中爲商城首頁的部分測試數據，其中：平均響應時間單位爲秒，Web服務器集羣由4個Web服務器實例構成(Dell R720)，App服務器集羣由6個App服務器實例構成(Dell R720 )，DB服務器由2個構成(Dell R720 )，測試過程中忽略思考時間。
分析對比銀行電商平臺的性能需求設計與產品性能測試數據可知:在合理的軟硬件配置下和應用系統自身優化後,產品可以滿足用戶600併發響應時間控制在5秒左右，根據項目上線的具體情況有所浮動。
網絡寬帶估量
總用戶數活躍用戶比例每人人均PV*80%*每個頁面大小數*8=峯值時期的bit數
24小時*20%*60*60=峯值時期的秒數
峯值時期的bit數/峯值時期的秒數=寬帶數
每個頁面不含圖片130k
每個圖片74.3K，每個頁面平均7個圖片 共計520k
頁面大小爲：130k+520k=650k
例如：(1200000*3%*8*80%*650k*8)/（24*20%*60*60）=10400bps = 102Mbps
1.5 系統監控
1.5.1 監控系統的設計目標
一個系統的運行環境包括網絡、硬件和軟件三個部分，要保障系統的正常運行，監控系統必須能夠從網絡節點（包括網絡和設備）和應用這兩個層次對系統進行全面監控。
網絡節點的監控，是實現對系統運行環境的物理資源的監控，對一個交易系統來說，網絡節點的監控，就是實現對交易流程中涉及的各個設備環節的監控，也即交易節點監控。應用監控是對系統運行環境的邏輯資源進行監控。
監控系統要能夠確保系統的正常運行，及時的發現問題，並做出響應，監控系統必須滿足以下基本求：
1.5.1.1 網絡節點監控
網絡節點監控，可以迅速判定系統架構中的性能故障，而且不需要在被監控的服務器上安裝任何軟件，從而將監控帶來的性能方面的負面影響降到最小，我們可以稱爲交易節點監控系統。
1.5.1.1.1 硬件級監控
一個運行系統環境，接入了很多的設備，每一個設備（網絡節點）都是一個監控點，要實現對系統的網絡進行全面監控，必須達到：
網絡節點間的網絡情況監控：是否暢通，網速大小等
網絡節點（設備）與網絡節點（設備）之間的暢通性
支持動態網絡節點增減
1.5.1.1.2 系統級監控
系統級監控就是實現對設備的運行情況監控，如對系統是否在運行，系統內存、CPU、交換區、磁盤空間、系統IO，以及對外服務端口等系統資源情況監控等等。設備監控是從系統級別的監控。
1.5.1.1.3 網路節點監控的特點
網絡節點監控具備如下特點：
快速方便的實施
方便的安裝、使用和配置
無代理、非嵌入式結構，不需要在被監控服務器上安裝軟件，從而將對系統的影響降到最低
對網絡資源和系統、如服務器Cluster的運行持續的進行狀態輪詢
收集系統部件的詳細性能數據，如CPU、虛存、交換區、進程、服務可用性等
對其他管理工具提供廣泛的支持，如爲Microsoft、Citrix、BEA、Sun、Oracle、SAP和Siebel提供API
對業界標準的廣泛支持，如SNMP(v1、v2&v3)、Telent、FTP、News、email、DNS、LDAP、Radius以及其他一些服務
支持從其他來源收集性能數據，如日誌、命令行或批處理文件
支持動態或靜態基線的門限值設定
故障確定後提供多種方式的告警
支持監控的網絡節點動態增減
1.5.1.2 應用監控
應用監控就是監控設備上運行的應用軟件的運行狀態。對不同的應用軟件，監控功能不一樣。
對應用的監控，除了實現對應用系統的運行情況進行全面監控外，還要對應用流程實現全流程監控：從應用流程的發起點到應用結束點，涵蓋所有的流程環節。
1.5.1 監控系統設計
監控系統的運行要求配置一個監控服務器，實現如下監控模式：
根據監控系統配置的監控規則（如服務器類型，操作系統類型，採用的協議模式，訪問授權信息等），主動獲取監控對象的監控數據。
根據參數配置，啓動監控守護線程，被動接收從監控代理髮送過來的監控數據信息
分析監控數據，按照監控規則進行處理，如預警處理，監控信息通知，監控報表生成等
監控人員通過監控終端，登錄監控服務器，查看被監控的系統狀態，並對被監控的系統進行實時在線維護。
1.5.2.1 網絡節點監控方案設計
網絡節點的監控，需要支持動態的網絡檢點增減，因此對網絡節點的監控主要是針對具體的監控設備或網段，採用主動獲取的監控方式，監控網絡暢通狀態和設備狀態，獲取監控信息。
網絡節點的監控對所有的應用系統同。
1.5.2.2 應用監控方案設計
應用監控主要是實現業務的全流程監控，從業務流程的發起點到業務流程的結束，完成對各個應用環節的監控。
應用監控分主動監控數據獲取和被動監控數據獲取兩種方式，主動獲取由監控服務器發起，被動監控數據由部署在各環節上的監控代理獲取，然後發送到監控服務器。監控人員通過監控終端登錄監控服務器，查看應用狀態和業務流程狀態，以及各個環節的運行狀態，並進行在線實時維護。
對不同的應用，應用監控要求各不一樣，需要針對不同的應用軟件環境和硬件環境，進行定製。
1.5.3 電商平臺系統監控設計
對於電商平臺系統來說，最爲直接和迫切需要的，就是可實時報警和反饋的監控系統。該系統可以7x24不間斷訪問測試系統，提供最爲實時和直接的警告。使系統管理員及時加以處理，減少反應的時間。
電商平臺系統的監控也需要從網絡節點（包括網絡和設備）和應用這兩個層次實現全面監控。
1.5.3.1 網絡節點監控
如網絡節點監控設計目標所述，網絡節點監控包括網絡級監控和系統級監控，在電商平臺系統會員中心繫統中，將根據接入設備和網絡部署情況，進行監控策略定製，實現對系統的各個環節進行有效的監控和維護。
系統網絡節點的監控實現參見上節的監控系統設計。
1.5.3.2 系統應用監控
電商平臺是一個7x24不間斷的客戶交易系統，通過監控系統進行分析，以確定系統的運行情況和故障環節。就是實現對電商平臺的WEB服務器的應用軟件、應用服務器的應用軟件和數據庫服務器的應用軟件的運行情況進行監控，尤其是應用服務器的應用軟件——電商平臺門戶的運行情況進行監控。
監控系統對電商平臺門戶的監控，應該包容如下內容：
監控：
系統狀態查看
系統資源情況
系統登錄用戶數、併發用戶數監控
系統維護
監控啓動停止操作
應用系統啓動停止操作
系統資源在線維護
系統內部組件在線實時調整
系統參數在線實時維護
系統耗時對象併發數在線控制
以上只是部分功能列舉，監控系統必須具備靈活的擴展性，可根據具體的應用需要，可進行擴展。
電商平臺會員中心繫統的基礎平臺，符合JMX標準，能通過監控平臺Monitor進行全面的應用監控，如系統運行狀況、資源狀態、耗時對象等等的監控，並能夠針對問題，對生產系統進行實時在線調整維護。
1.5.4 監控平臺Monitor介紹
1.1.1.1 Monitor的邏輯框架
應用中，各個組件被包通過配置文件透明地被導出成一個一個的MBean，註冊到MBeanServer中。
用戶通過瀏覽器以HTTP協議向i2FSP Monitor發出監控請求，Monitor MVC接受用戶請求，通過調用RMIConnector與被監控端i2FSP應用中的RMIConnectorServer建立連接，調用相應MBean的方法，完成用戶監控請求。
在RMI連接中，有以下幾類數據流：
1 從Monitor端發起，獲取監控組件屬性；
2 從Monitor端發起，設置監控組件屬性；
3 從Monitor端發起，調用監控組件的監控方法；
4 從被監控的i2FSP應用端發起，向對應的監聽器發送監控報警信息。
Monitor接收到報警信息後，根據配置，會調用郵件接口或短信接口把報警信息發送到對應的郵件接收者或短信接收者。
1.5.4.2 Monitor的實現原理
Monitor監控系統採用JMX（Java Management Extensions）技術。
在應用服務器端，針對一個平臺上的應用，應用服務器平臺自動提供可配置的JMX管理服務器端，可對外提供基於JMX標準框架的監控服務。
在平臺基礎上，建立我們的基於JMX框架的監控應用，平臺上的監控應用採用Web框架，同樣架構在基礎應用平臺之上，是一個完全遵循JMX管理框架的監控服務器應用，可以連接標準的JMX MBean Server。並提供應用監控、應用管理和用戶管理等功能。在監控平臺上，封裝了標準的JMX RMI協議支持的JMX訪問連接器和基於JMXMP協議支持的訪問連接器。
監控系統的整體設計保證了平臺在監控功能上對JMX的完全兼容能力。應用所提供的JMX監控功能能夠被所有的基於標準的JMX監控客戶端所訪問，也保證了基於平臺上的監控系統應用能夠訪問所有的標準的基於JMX監控服務器對象。
1.5.4.3 Monitor的功能
1.5.4.3.1 對基於平臺的系統監控
系統資源狀態
查看i2FSP系統服務器負載情況，如：登錄人數、交易併發人數、數據庫最大連接數、數據庫當前連接數、MQ最大連接數、MQ連接數、TCP/IP連接數等應用指標參數進行查詢。
JVM屬性配置查詢
查看應用服務器部署的系統環境參數，如語言，應用路徑等信息。
JVM進程運行狀況
查看當前JAVA進程的線程堆棧，瞭解JVM的運行狀況。
後臺系統狀態
查看i2FSP平臺所連接的後臺系統信息（如地址端口設定）和連接狀態（如連接數、連接處理時間）。
內部公共組件的狀態
查看渠道整合系統的內部公共組件狀態（如數據庫連接服務連接數等）；該功能實現對對被監控應用系統中重要的系統組件，如：數據庫連接緩衝池、通信緩衝持、對象池等，進行參數信息在線實時調整，以及資源釋放和分配、可用性控制等維護。
交易異常的跟蹤
查看渠道整合系統內交易執行情況，及查看交易異常記錄、查看交易異常文件跟蹤或交易日誌等。
交易對象監控
監控某個交易的執行情況，如併發數、用戶分佈情況等信息。
交易日誌的統計
該功能用於對被監控應用系統中交易日誌進行查詢、分析操作。
1.5.4.3.2 對基於平臺的系統控制
監控啓動或停止
爲了最小化監控對應用系統性能的影響，系統的監控並非是7x24小時必需的，只有在需要的情況下才啓動監控。
通過監控系統，可以對被監控的系統是否啓動監控進行動態維護。
公共資源的控制
通過監控系統，對中的一些公共資源參數在運行狀態中進行重新設定，例如重新設定數據訪問服務連接最大數、會話超時時間等等。
內存資源回收
通過監控系統，對被監控應用系統內存資源執行主動回收動作，並展示相應內存使用情況列表：系統內存數、剩餘內存數和已使用的內存數。
系統參數在線維護
通過監控系統，對被監控的、基於實現的系統參數文件或數據表，進行重新讀取或更新操作。
交易參數配置文件維護
該功能用於對被監控應用系統中，交易參數配置文件進行交易列表展示，並對選定交易配置信息進行在線初始化操作。
受限交易列表維護
該功能用於對被監控應用系統中,需要控制併發數的受限交易列表進行展示展示，並對選下受限交易最大交易數進行修改操作，或禁用改交易的操作。
即時消息推送
該功能用於對被監控應用系統中產生的異常信息及時的進行提示和告警，便於維護人員及時處理。
1.5.5 完善的監控體系所產生的效益
實施以上建議的監控體系，可以產生的效益是比較明顯的，主要有：
提供從業務出發的、7x24的實時業務性能視圖
提供服務水平和故障診斷報告
對能夠影響業務系統運作的潛在故障進行主動定位和告警
將測試階段使用的生產環境中加以利用，監視故障的響應時間
增強系統的穩定性和正常工作時間
降低對服務檯的支持請求次數
改善用戶體驗，提高用戶滿意度，從而提高在爭取用戶方面的競爭力
通過數據分析得到趨勢報表，進而反映業務系統中存在的問題並主動進行解決
1.6 系統部署架構
1.6.1 系統部署拓撲
整個應用系統按照不同的業務功能和安全等級使用防火牆劃分爲不同的區域，包括Internet區域、DMZ區域、應用服務區域、Intranet（OA）辦公區域。
Internet區域是商城客戶、商戶操作員、第三方應用使用網絡環境區域。
DMZ區域指上圖中第一道防火牆和第二道防火牆之間的部分，主要放置需要對外提供服務的Web服務器（含購物中心、商戶中心等外網應用）。
應用服務區域是商城應用系統和北農商銀行其他外圍渠道系統，主要包括電商平臺應用服務器、數據庫服務器、支付平臺、短信平臺、郵件平臺、ODS、在線客服系統等。
Intranet區域是北農商銀行內部的辦公或者業務區域，運營中心操作員在此區域訪問銀行電商平臺的運營中心。
防火牆：
防火牆是Internet與銀行之間的路由選擇，同時對流到北農商銀行的數據流進行過濾的功能，也就是對北農商銀行內部網起安全保護的作用，它只允許被開放的協議數據包被傳送到北農商銀行內部網絡。系統共設有兩道防火牆，組成系統的停火區。
電商平臺WEB服務器：
電子商務平臺WEB服務器主要有以下的幾個功能和作用：
負責提供電子商務平臺應用系統靜態資源，比如：html、圖片、JavaScript腳本文件等。對於靜態資源的處理，WEB服務器比J2EE應用服務器的效率要高的多，使用WEB服務器處理這類請求將大大提高應用系統的響應速度。
轉發商戶或商城客戶通過Internet提交的請求到後端應用服務器上進行處理，比如：JSP、Servlet。
通過Web服務器將應用系統的應用服務器隔離在第二層防火牆之後,提高應用系統的安全等級。商城門戶/商戶服務WEB服務器既可以分開不同的硬件部署，也可以放置在一臺服務器上，通過使用虛擬主機技術進行配置。爲了避免單點故障，建議部署兩臺WEB服務器集羣。（隨業務發展需要，可以進行集羣橫向的擴展。譬如：如果業務壓力過大，可以採用負載均衡來增加系統處理吞吐量、提高系統可用性）。
應用服務器：
應用服務區用於部署了電商平臺應用系統，包括面向商城客戶的商城門戶應用系統，面向商戶服務和商城內部管理的商城管理應用系統（商戶和商城內部管理可以集成也可分離進行部署），搜索引擎服務器，電子郵件服務器。
應用服務器，可以通過應用服務器的羣集功能，採用多臺服務器組成負載均衡模式下的應用服務器集羣系統，以達到最大的高可用性。
數據庫服務器：
電商平臺數據庫服務器存放電商平臺相關的數據，由多臺數據庫服務器組成水平集羣。
支付平臺
對電子商務平臺而言，網上支付平臺主要提供兩個方面的功能：一.接收客戶的支付請求，並將支付結果返回給客戶：支付平臺將Internet傳來的數據包解密，並按照銀行系統內部的通信協議將數據重新打包；接收銀行系統內部的傳回來的響應消息，將數據轉換爲Internet傳送的數據格式，並對其進行加密。即支付網關主要完成通信、協議轉換和數據加解密功能，以保護銀行內部網絡。
二.接收銀行電子商務平臺運營中心發起的對支付訂單的管理類請求，如訂單退款、對賬等。
短信平臺
短信平臺主要用來發送短信給通知反饋客戶其操作行爲和結果，起到了預警和確認的作用，譬如：客戶註冊、購買商品時，電子商務平臺通過調用短信平臺的相關接口，發送相應的短信到客戶預留的手機中。
郵件平臺
郵件平臺主要用來發郵件通知反饋客戶其操作行爲和結果，起到了預警和確認的作用，譬如：客戶註冊、購買商品時，電子商務平臺通過調用郵件平臺的相關接口，發送相應的郵件到客戶預留的Email郵箱中。
在線客服
在線客戶通過即時通訊的方式爲電商平臺提供與訪問者對話的平臺，起到了增加營銷渠道、增加銷售機會、降低運營成本、鞏固客戶關係等的作用。
統一身份認證平臺
統一身份認證平臺通過多個異構系統統一在一個驗證體系進行用戶驗證，保障了用戶及其權限的一致性，簡化客戶的操作流程，增加客戶對電商平臺及相關網站的粘滯性。
互聯網SNS
通過在瀏覽器端調用其他互聯網服務提供商的開放API接口，可以實現商品的分享和推薦。
1.6.2 系統拓撲結構特點
本系統網絡拓撲具有以下特點：
採用兩層防火牆結構，具有較高的安全性，能有效地抵禦來自內部、外部、中間部分的入侵；建議外防火牆採用雙機熱備份方式，以保證系統穩定性；
使用防火牆，將網絡劃分爲不同安全級別的區域：限制DMZ、核心業務區、Intranet；
內外防火牆不直接相連，在限制DMZ區的服務器均有兩張網卡，分別跨接在內外防火牆的網段上，並且取消路由轉發；即便外層防火牆被攻破，入侵者也無法直接抵達內部防火牆，增強了系統安全性。
Internet區
Internet區域不是用戶自主的區域，該區域通過專線接入到用戶的邊緣路由器，邊緣路由器再與外層防火牆連接。路由器和防火牆是防範外部入侵的第一道防線，配置上應格外小心。
邊緣路由器應選用帶有防火牆過濾功能的路由器；
邊緣路由器與防火牆之間不宜再添加交換機，一方面可以減少設備的投入，另一方面也減少了入侵的立足點；
邊緣路由器和防火牆之間的網絡地址應使用Internet保留的私有地址，如10.0.0.0/8，這樣可以保證從Internet不可以直接訪問到路由器的對內網絡和防火牆的對外網口；
在防火牆的安全規則中應禁止來自邊緣路由器各端口對內、外層防火牆各端口的訪問，萬一邊緣路由器被攻破，該規則可以防止來自邊緣路由器的攻擊。
雙防火牆熱備份結構
內、外層防火牆採用的是雙機的結構，通過防火牆軟件自身的HA功能或系統級的HA功能，可以實現防火牆的熱備份功能，同一時刻，內層和外層防火牆都只能有一個防火牆處於工作狀態（Active），另一個處於等待狀態（Standby），兩個防火牆之間建立私有的心跳網絡並通過該網絡相互檢測對方的可用性，處於等待狀態的主機一旦檢測到處於工作狀態的主機失效時，會自動從等待狀態轉到工作狀態並將服務接管過來。
DMZ區域
該區域是整個網絡拓撲對外服務的核心部分，擁有最高的安全級別，用戶對外的主要服務器一般放置在該區域：
該區使用Internet合法地址，因此防火牆相應的網口必須使用Internet合法地址；
該區域的服務器對內訪問時，只可以訪問核心業務區；
該區服務器必須配置兩個網口，一個網口連接到對外的獨立交換機，一個連接到對內的獨立交換機；
由於服務器對內對外使用不同的網絡接口，可以提高服務器的網絡流量；
由於外層防火牆和內層防火牆未直接連接，萬一外層防火牆被入侵，入侵者仍無法直接攻擊內層防火牆；
應用服務區域
應用服務器需要與DMZ區的Web服務器和核心業務區系統進行通訊；
應用服務器需要與核心業務區、通過內部網的交易通訊網關或者直接與後端核心業務系統通訊。
Intranet
該區域是銀行管理人員的內部網絡
1.7 系統軟硬件配置
下表羅列的軟、硬件配置參照交行信用卡商城生產環境編寫，實際部署情況可能會有改動，此僅供參考。
所有服務器暫時在同一個機房部署，等以後再進行劃分。
1.7.1 Web服務器
1.7.1 應用服務器
1.7.3 數據庫服務器
