集團公司服務總線ESB方案計劃書

1、企業(yè)服務總線ESB方案書1 需求綜述 31.1 主數(shù)據(jù)平臺接口 31.2 業(yè)務數(shù)據(jù)接口 31.3 OA 系統(tǒng)接口： 41.4 國家法定信息發(fā)布媒體： 42 系統(tǒng)解決方案 52.1 系統(tǒng)技術架構 52.1.1 運行平臺 52.1.2 開發(fā)平臺 62.1.3 監(jiān)控平臺 62.1.4 公共服務 62.1.5 適配器 62.2 部署方案 72.2.1 管理監(jiān)控部分部署方案 72.2.2 硬件選型建議 82.2.3 邏輯分區(qū)部署方案 92.2.4 硬件配置建議 92.2.5 服務接口規(guī)范 102.2.6 高性能、高可用性及擴展能力設計 102.2.7 完善的安全機制 112.3 整體解決方案 122.3

2、.1 接入控制 122.3.2 通信接入模塊 132.3.3 請求系統(tǒng)適配 142.4 集成服務功能 152.4.1 服務治理 152.4.2 提供對出錯服務的及時檢測和隔離功能 152.4.3 協(xié)議轉換 152.4.4 消息格式轉換 162.4.5 服務路由 162.4.6 監(jiān)控和運維 162.4.7 服務等級 172.5 系統(tǒng)非功能需求 172.5.1 可用性 172.5.2 可擴展性 172.5.3 可維護性 182.5.4 安全性 182.5.5 性能需求 182.6 公用服務 182.6.1 流量控制 182.6.2 故障隔離 192.6.3 統(tǒng)一流水號 192.6.4 日志記錄 1

3、92.7 管理監(jiān)控 192.7.1 系統(tǒng)平臺級監(jiān)控 192.7.2 應用級監(jiān)控 192.7.3 統(tǒng)計分析 192.7.4 異常報警 202.7.5 統(tǒng)一的運維管理 203 技術支持與服務方案 203.1 技術支持與售后服務體系 203.2 服務管理模式 213.3 服務響應 213.3.1 問題優(yōu)先級（或問題嚴重程度）級定義 213.3.2 服務響應時間 223.3.3 問題解決時間 233.3.4 服務文檔 243.4 維護支持服務流程 243.4.1 服務消息創(chuàng)建流程 243.4.2 問題處理流程 243.4.3 服務確認流程 263.4.4 投訴及問題升級流程 271 需求綜述1.1 主

4、數(shù)據(jù)平臺接口系統(tǒng)建立與SAP相同的基礎數(shù)據(jù)管理庫，通過數(shù)據(jù)總線接口同步能源集團 MDM中傳輸 過來的編碼或數(shù)據(jù)，以滿足電子采購平臺基礎數(shù)據(jù)管理的需求?；A數(shù)據(jù)信息包括： 物料編碼、計量單位、供應商、客戶等。1.2 業(yè)務數(shù)據(jù)接口系統(tǒng)業(yè)務數(shù)據(jù)通過數(shù)據(jù)總線接口同 SAP OA EC等系統(tǒng)進行數(shù)據(jù)交互。系統(tǒng)必須確保通過數(shù)據(jù)總線接口訪問 SAP OA EC等系統(tǒng)數(shù)據(jù)與電子采購平臺數(shù)據(jù)傳 輸及時準確 數(shù)據(jù)完整統(tǒng)一；<=><=><=>數(shù) 據(jù) 總 線 系 統(tǒng)數(shù) 據(jù) 中 心電商平臺1.3 0A系統(tǒng)接口：支持將電子采購平臺中的待辦事項發(fā)送到 0A辦公系統(tǒng)進行審批，并讀取審批流。

5、1.4國家法定信息發(fā)布媒體：按照國家相關要求，選擇相關媒體建立統(tǒng)一接口，支持招標公告、變更公告、結果公 示等的自動發(fā)布。如國家無強行規(guī)定，可以不做接口。2 系統(tǒng)解決方案2.1系統(tǒng)技術架構苜浬甜至服務系旅;舌配器服務磊洗適配器誦旳顓洋閏涉廿就 喑曲比代石牌jgffgL同涉局出ft'唔珈化”代菇轉換非乜詣宰進當嫌一購盲苗rw范、箱一逹沖燒一常辟、忙卻用琵站問業(yè)雖方云話，無無專ffi-l&ffin.純一苣理.俊一益捋一供*IE務面51:筒莖刊性磊孑 高一30三量予 菖吞珀彷違告卑舗彙總 宸用護也低旳0t業(yè)匝冏宴拜直張竺妄耳-懸詩桶入應鹽崗KU適求祭筋2.1.1 運行平臺運行平臺內部按

6、照集成應用的特點分為多個集成“通路”，目前考慮分為四類通路：1、關鍵服務通路關鍵業(yè)務、實時性要求高。2、非關鍵通路 非關鍵業(yè)務，查詢等。3、服務代理通路從目標架構過渡過程中，與集成目標無關的可以采取“穿透”的方式，減少實施工作 量和實施成本。另外，復用價值較低的服務請求也適合采用“代理模式”。4、低成本通路對于實時性要求不高，且信息量大的服務，可采取批量處理模式，降低集成實施成 本。實際部署環(huán)境中，每一類通路都可以有多個物理部署，用來保證系統(tǒng)的可靠性，同時 也支持橫向的擴展和減少不同系統(tǒng)之間的相互影響。2.1.2 開發(fā)平臺基于ESB系統(tǒng)標準的服務接口定義、內部統(tǒng)一的元數(shù)據(jù)管理、數(shù)據(jù)結構和服務接

7、口定 義、路由規(guī)則等，實現(xiàn)多個技術通路的統(tǒng)一配置開發(fā)。開發(fā)平臺的是對各個技術通路實際實現(xiàn)方法的抽象封裝。提供服務邏輯的開發(fā)框架和 組件庫，用于轉換適配邏輯、公共服務邏輯等的標準化開發(fā)、組件重用和統(tǒng)一管理。2.1.3 監(jiān)控平臺ESB應用系統(tǒng)要建立統(tǒng)一的日志規(guī)范、流水記錄規(guī)范、錯誤碼規(guī)范、系統(tǒng)運行狀態(tài)檢 測規(guī)范、系統(tǒng)運行狀態(tài)控制標準，實現(xiàn)對 ESB系統(tǒng)整體統(tǒng)一的監(jiān)視和控制。是 ESB系統(tǒng)的集成“控制面板”。主要功能包括：異常監(jiān)視、通知提醒、運行控制、實時查詢、統(tǒng)計分析、服務的配置 和發(fā)布、服務管理、統(tǒng)一維護和版本部署等。由于ESB系統(tǒng)是整個企業(yè)的服務訪問樞紐，ESB可以集中監(jiān)控企業(yè)內所有的服務訪問

8、，能夠提供各個系統(tǒng)的服務質量和狀態(tài)的統(tǒng)計數(shù)據(jù)，例如：成功率、服務響應時 間、服務訪問量、服務狀態(tài)異常等。2.1.4 公共服務提供統(tǒng)一的流量控制服務、日志記錄、接入?yún)?shù)控制等公共服務。從而實現(xiàn)多技術平 臺、多物理部署運行環(huán)境的公共服務支持。2.1.5 適配器適配器是ESB系統(tǒng)解決與外部系統(tǒng)之間各類差異的總稱。ESB#外部系統(tǒng)分為請求系統(tǒng)和服務系統(tǒng)兩類。 服務系統(tǒng)適配器對于服務系統(tǒng)，尤其是遺留服務系統(tǒng)，基本集成策略是由 ESB項目組開發(fā)適配器進行 集成。但是服務系統(tǒng)適配器，并不能解決所有的服務適配問題，例如：ESBK務接口規(guī)范與服務系統(tǒng)規(guī)范的復雜對應和匹配工作，尤其是涉及到多個服務系

9、統(tǒng)接口的復雜流程調用部分，如果由ESB組合這類服務流程組合，解決相關的交易完整性、一致性 問題，代價太大而且無法保證。因此，實際集成實施過程中，不可避免的要涉及到對服務系統(tǒng)的改造工作。 請求系統(tǒng)適配器對于請求系統(tǒng)，ESB的基本原則是要求請求系統(tǒng)符合 ESB的技術規(guī)范和服務接口規(guī) 范。目的是減少不必要的轉換適配層次，提高系統(tǒng)的集成服務效率，降低資源消耗。 ESB系統(tǒng)可為請求系統(tǒng)提供 API，對請求系統(tǒng)屏蔽通訊適配、報文組包等技術細節(jié)。 請求系統(tǒng)只需要理解業(yè)務層面的接口規(guī)范，從而大大簡化請求系統(tǒng)的集成工作，同時 還可以加強對請求系統(tǒng)的監(jiān)控管理，同時為接口技術實現(xiàn)的升級改造提供輔助支持

10、。 ESB也可以開發(fā)適配器，實現(xiàn)請求系統(tǒng)的集成。主要針對那些無法改造或改造成本過 高的請求系統(tǒng)。2.2 部署方案2.2.1 管理監(jiān)控部分部署方案ESB系統(tǒng)的部署方案必須符合企業(yè)基礎架構的要求。1） Webserver和Application Server必須分離，分別部署在 Web2區(qū)和APP區(qū)?；蛘遅eb2區(qū)的應用通過生產(chǎn)區(qū)域的 APP訪問DB2） 用戶管理要符合集團的規(guī)范。用戶權限控制統(tǒng)一通過UMUM決定用戶是否有權限操作ESB的管理監(jiān)控平臺。UM權限通控制通過以后，由ESB管理監(jiān)控應用來進行詳細的角色權限管理。3）考慮到費用問題，可以采用 Apache和Tomcat。2.2.2 硬件選型

11、建議ESB系統(tǒng)目標架構硬件選型主要考慮從以下因素：1）成本因素ESB系統(tǒng)基于Java技術實現(xiàn)，具有跨平臺的技術優(yōu)勢，因此可將成本是考慮硬件選 型的首要指標，未來隨著ESB應用規(guī)模的不斷增長，硬件成本在項目投入所占比重將 會增加，因此選擇性價比高的硬件平臺是提高效費比的有效途徑。2）硬件擴容周期ESB作為企業(yè)內部信息化最為關鍵的服務樞紐，必須能夠快速響應應用規(guī)模的增長， 其中包括硬件的采購周期、系統(tǒng)擴容部署速度。3）資源調配的簡便性、靈活性ESB系統(tǒng)應能夠針對業(yè)務量的周期性變化，靈活的增減系統(tǒng)資源配置，資源的調整不 應對集成服務持續(xù)性造成影響。基于上述考慮，ESB系統(tǒng)的硬件推薦采用刀片服務器。刀

12、片服務器還具有以下優(yōu)點：1）硬件成本相對低廉，配套的系統(tǒng)軟件和中間件價格也相對較低。2）虛擬化的集中資源管理，可有效提高資源的利用率。3）在集群中插入新的刀片，就可以提高整體性能。4）支持熱插拔，硬件資源可以輕松地進行替換，并且將維護時間減少到最小。5）節(jié)約空間、便于集中管理、易于擴展和提供不間斷的服務。2.2.3 邏輯分區(qū)部署方案2.2.4 硬件配置建議其對應分配如下:名稱功能分布配置計算單兀數(shù)量適配器/公共服務適配器公共服務2cpu（8 核）32GB memory1*2集成核心WebMethodsMessage Broker2cpu（8 核）32GB memory1*2數(shù)據(jù)庫服務器Orac

13、le2cpu（8 核）132GB memory歸檔數(shù)據(jù)庫服務器Oracle2cpu（8 核）32GB memory1備份資源池作為公共備份2cpu（8 核）32GBmemory1總計72.2.5 服務接口規(guī)范ESB系統(tǒng)負責解決實施服務接口規(guī)范與服務系統(tǒng)接口的差異，可將主要的實施工作控 制在ESB項目范圍內，大大降低周邊系統(tǒng)的改造工作量，配合一些系統(tǒng)的瘦身計劃的 分階段順利實施。2.2.6 高性能、高可用性及擴展能力設計高處理能力保證措施控制信息+XML應用報文，中間層次不必解析 XML應用報文，使系統(tǒng)不僅具備完善的 管理控制能力，同時還減少了報文解析開銷，提高了效率。非阻塞的異步模式、流水線式

14、的作業(yè)處理，提高吞吐能力。異步記錄流水日志，保證信息的完整記錄，同時不影響系統(tǒng)的處理性能。系統(tǒng)處理能力可隨硬件資源的擴展線性的增長。系統(tǒng)所有配置規(guī)則均加載到Cache中，運行過程中不存在對數(shù)據(jù)庫配置信息的讀寫操 作，保證系統(tǒng)高效運行。持續(xù)穩(wěn)定運行保障措施所有應用模塊均為群集部署，系統(tǒng)不存在單點故障隱患，某個模塊的故障不影響正常 運行。系統(tǒng)應用版本的升級可按模塊分別進行，不影響業(yè)務的正常運行。采用數(shù)據(jù)庫分區(qū)技術，實現(xiàn)海量數(shù)據(jù)記錄的清理和分區(qū)切換過程15秒鐘內完成，無需采用與應用相關的數(shù)據(jù)庫分表方式，實現(xiàn)批量數(shù)據(jù)處理對總線應用透明。系統(tǒng)提供完備的動態(tài)安全刷新手段，配置信息可運行時在線刷新。可擴展性

15、系統(tǒng)可以在CPU內存等資源增加及擴容的情況下自我線性擴展處理能力；每個邏輯 模塊可以采用橫向擴展的多物理模塊部署。中間用隊列進行通訊。可維護性系統(tǒng)具有較為完善的用戶管理界面，提供對系統(tǒng)所有功能的維護與參數(shù)配置管理的功 能；系統(tǒng)采用統(tǒng)一的服務模式和開發(fā)框架，從開發(fā)商增加可維護性，系統(tǒng)部署上采用 多邏輯單元分離部署，減少系統(tǒng)內部的耦合度，增加整個系統(tǒng)的可維護性。2.2.7 完善的安全機制企業(yè)應用集成技術使復雜的業(yè)務流程、大量的信息和數(shù)據(jù)在各IT應用系統(tǒng)和業(yè)務部門之間高效的流轉和共享，實現(xiàn)業(yè)務流程標準化和自動化，促進業(yè)務流程優(yōu)化，提高 建行運營效率。任何不安全因素都會造成不可估量的損失，故所有數(shù)據(jù)的

16、傳輸、處 理、交換都必須在良好的安全環(huán)境下進行，因此，必須建立一套完整的安全機制，以 確保整個通信系統(tǒng)的安全運行。方案主要為 ESB系統(tǒng)提供如下幾個方面的安全服務：1. 密鑰管理提供安全有效的密鑰管理方案，實現(xiàn)應用系統(tǒng)和ESB系統(tǒng)的密鑰產(chǎn)生、密鑰分發(fā)、密鑰更新、密鑰注銷等。提供密鑰的自動更新機制，保證密鑰的安全性，提供高效的對 稱密碼算法，確保應用系統(tǒng)具有可用性和易用性。2. 身份認證保證接入ESB系統(tǒng)的合法性，提供應用系統(tǒng)和 ESB系統(tǒng)之間的雙向身份認證，采用基 于證書的認證模式，系統(tǒng)使用的數(shù)字證書由第三方 CA或者采用自運行維護的CA提 供。CA證書采用離線下發(fā)的方式，以 PKCS#12t

17、件的格式安裝到ESB系統(tǒng)和應用接 入系統(tǒng)。身份認證完成后，雙方得到一個 64個字節(jié)的隨機數(shù)，通訊雙方使用的對稱密鑰都是 基于這一組隨機數(shù)產(chǎn)生，對稱密鑰的選取規(guī)則雙方使用相同的策略。對稱密鑰和對方 的公鑰信息存放在系統(tǒng)主機的共享內存，方便應用系統(tǒng)加密使用3. 通訊加密ESB系統(tǒng)的安全性是保障IT應用系統(tǒng)安全可靠運行的重要環(huán)節(jié)，使用PKI技術實現(xiàn)系統(tǒng)的密鑰管理和通訊加密是目前解決此類問題的最有效途徑，應用系統(tǒng)和ESB系統(tǒng)之間通訊的報文使用對稱算法加密保護其機密性。為了提高密碼運算的處理速度，這 里推薦使用AES算法，密鑰的長度為128bit。通訊雙方在身份認證完成后，在共享內存中保存對稱密鑰?？蛻?/p>

18、端和服務器端的加密 流程如下：客戶端加/解密流程：1）查詢共享內存中的對稱密鑰和算法ID，根據(jù)加密要求選取對稱密鑰，如果共享內 存中沒有對稱密鑰，加/解密失敗。2）使用查詢得到的對稱加密密鑰，對報文進行加 /解密處理。 服務器端加/解密流程：1）根據(jù)客戶端的系統(tǒng)代碼，查詢共享內存的加密密鑰和算法ID，如果共享內存中沒有 對稱密鑰，加/解密失敗。2）使用查詢得到的對稱密鑰，對報文進行加 /解密處理。4. 關鍵字段MAC2.3整體解決方案ESB集成技術架構方案劃分為四個層面：渠道通迅接入、數(shù)據(jù)交換層、平臺服 務調度層、服務適配層。系統(tǒng)的每個層次都可進行橫向擴展，實際應用中系統(tǒng)處理能 力可以線性增長

19、。對于渠道服務請求的接入，ESB提供標準的通迅協(xié)議（支持TCP/IP、HTTPSNA FTP、MQSeries、JMS等協(xié)議和中間件）和MESD標準接口規(guī)范，同時還為請求系統(tǒng)提供服務請求的 API，屏蔽通訊協(xié)議和報文格式的技術細節(jié)，能夠提高請求系統(tǒng)的集成開發(fā)效率、減少轉換適配環(huán)節(jié)，同時還大大加強了總線系統(tǒng)對接入的控制和管理，促進了集成應用的快速推廣和可靠運行。對于改造成本過高的存量系統(tǒng)，通過集成開發(fā)在數(shù)據(jù)交換層實現(xiàn)分類路由、同步異步轉換、消息格式轉換、代碼 轉換等功能。平臺服務調度支持四種模式：（一）>MB通道，用于高時效性、高一致性、高吞吐能力的服務；（二）、WEEME通道，用于時效性

20、和一致性要求不高的服務；（三）、服務代理通道，目標架構過渡過程中，與當期集成目標無關，可以采取“穿 透”的方式，減少實施工作量和實施成本。另外，復用價值較低的服務請求也適合采 用“代理模式”；（四）、低成本通道，對于實時性要求不高，且信息量大的服務，可采取批量處理模 式，降低集成實施成本及節(jié)省系統(tǒng)資源。所有適配器需要在對存量系統(tǒng)分析后集成開發(fā)，ESB集成方案中集成產(chǎn)品的相互訪問統(tǒng)一使用MQ隊列方式。2.3.1 接入控制需要完成以下功能：1. 對渠道提供不同協(xié)議的接入功能，包括MQ webmethods, http等協(xié)議的接入。2. 對不同的渠道提供不同的接入點，實現(xiàn)系統(tǒng)負載均衡和最大限度的故障

21、隔離，提供 高容量，高可靠性的服務。3. 參數(shù)服務為渠道提供統(tǒng)一服務接口模式，伺服渠道下載需要的通道接入信息。4. 渠道通過輪詢請求方式主動下載版本變化信息，初始化變化的連接池。5. 服務端進行主動控制，實時控制渠道的接入通路。6. 當某一接入點故障時，通過主動控制渠道接入點，自動切換到可以的接入點，實現(xiàn) 故障的完全隔離。7. 對壓力較大的接入點，通過主動控制，把部分數(shù)據(jù)切換到壓力較小的通路，實現(xiàn)實 現(xiàn)負載控制。8. 服務端為渠道維護相應標識信息和其所有當前版本和歷史版本信息。9. 通過維護歷史版本信息，實現(xiàn)版本回退功能。實現(xiàn)方案：1.整體架構圖請求方2.3.2 通信接入模塊負責和外部系統(tǒng)進行

22、通訊，進行原始報文數(shù)據(jù)的傳輸。通信接入層實現(xiàn)以下功能:1 利用系統(tǒng)層通訊協(xié)議和請求系統(tǒng)進行通訊，包括TCP/IP、HTTP SNA FTPMQSeries、JMS 2外部系統(tǒng)約定的通訊方式的實現(xiàn)，包括如何進行通訊連接，如何進行通訊應答， 如何進行數(shù)據(jù)傳輸，如何約定通訊報文的大小，如何確定數(shù)據(jù)傳輸是否完畢，如何處 理通訊錯誤，如何關閉通訊連接，如何處理通訊層數(shù)據(jù)完整性校驗等。3 識別外部系統(tǒng)類型。4多通訊連接的并發(fā)處理。以下的功能不需要由通訊接口層完成：1. 非通訊層面的數(shù)據(jù)報文的加解密。2. 非通訊層面的數(shù)據(jù)報文的壓縮，解壓縮處理。通訊接入層屏蔽了所有的通訊細節(jié)，數(shù)據(jù)交換層只知道從某個外部系統(tǒng)

23、獲得了或者發(fā) 送了一個數(shù)據(jù)報文，至于該數(shù)據(jù)報文是如何獲得或者發(fā)送的，和數(shù)據(jù)交換層本身無 關。2.3.3 請求系統(tǒng)適配完成從服務端返回數(shù)據(jù)到標準輸出之間的轉換或從一個渠道端請求接口數(shù)據(jù)到MBSD服務標準請求數(shù)據(jù)之間的轉換。具體功能包括：1. 應用層面的數(shù)據(jù)報文的加解密。2. 應用層面的數(shù)據(jù)報文的壓縮，解壓縮處理。3. 數(shù)據(jù)報文類型的識別。4. 數(shù)據(jù)報文的打包拆包，根據(jù)報文類型以及相關配置將數(shù)據(jù)報文拆分成統(tǒng)一的數(shù)據(jù)接 口或者相反。5. 數(shù)據(jù)接口之間的轉換，根據(jù)定義的規(guī)則從一個數(shù)據(jù)接口轉換成服務數(shù)據(jù)接口或者相 反。接入適配層屏蔽了數(shù)據(jù)的具體物理表示和組織，平臺服務調度層只知道收到了一個服 務請求要求

24、處理，至于該服務請求是從哪個系統(tǒng)發(fā)起的，原始的請求數(shù)據(jù)是什么，和 服務整合層沒有關系，只和數(shù)據(jù)交換層有關。接入適配框架提供可配置的定長、變長報文轉換適配器，以及可擴展的接口可以適應 各種不同格式的報文轉換。同時接入框架提供了 MBSD元數(shù)據(jù)管理功能，能夠方便的 定義報文的元數(shù)據(jù)，為報文的轉換以及應用的開發(fā)提供便利。2.4集成服務功能2.4.1 服務治理提供服務標準定義、服務封裝、注冊與發(fā)布等功能 ，提供位置透明性的服務路由和定 位服務ESB的服務接口規(guī)范應該基于對業(yè)務流程的理解，經(jīng)過抽象、歸納形成，服務 接口規(guī)范獨立與現(xiàn)有系統(tǒng)的具體實現(xiàn)，接口規(guī)范具有較強的獨立性、穩(wěn)定性。從而真 正消除請求系統(tǒng)

25、與服務系統(tǒng)之間的關聯(lián)關系，實現(xiàn)服務的位置以及服務的具體實現(xiàn)與 服務的訪問過程無關。我們提供MBS規(guī)范落地實施的工具：元數(shù)據(jù)管理，服務接口定義配置，導入導出工 具（可以通過web頁面形式和導出文件形式對外公布），服務規(guī)范適配的開發(fā)框架。我們提供MBS規(guī)范落地實施的工具：元數(shù)據(jù)管理，服務接口定義配置，導入導出工 具（可以通過web頁面形式和導出文件形式對外公布），服務規(guī)范適配的開發(fā)框架。2提供對出錯服務的及時檢測和隔離功能ESB系統(tǒng)實時檢測服務系統(tǒng)的服務狀態(tài)，當服務出現(xiàn)異常時，能夠及時發(fā)現(xiàn)，通過監(jiān) 控平臺發(fā)出報警，通過人工手段或預先設定的規(guī)則，對狀態(tài)異常的服務或服務系統(tǒng)進 行迅速隔離，避免因故障導

26、致服務阻塞，保證請求系統(tǒng)對其他服務的正常訪問。243協(xié)議轉換支持外部系統(tǒng)通過 TCP/IP、HTTP SNA FTP MQSeries、JMS等協(xié)議和中間件與 ESB 平臺通訊。一般情況下，請求系統(tǒng)使用 ESB系統(tǒng)提供的API，按照ESB系統(tǒng)的技術標準和服務規(guī) 范進行服務訪問，從而避免不必要的協(xié)議轉換開銷。但是對于請求系統(tǒng)無法改造或改造成本過高的情況下，ESB系統(tǒng)應提供接入?yún)f(xié)議適配的功能，支持外部系統(tǒng)通過不同的通訊協(xié)議與 ESB平臺通訊。但是應注意，ESB更多的情況下是為了適應服務系統(tǒng)的技術差異，才進行通訊的適 配，從系統(tǒng)的規(guī)范化和易維護性角度考慮，不推薦被動的對請求系統(tǒng)進行通訊協(xié)議適 配。接

27、入框架提供了對各種通訊協(xié)議的轉換適配器，可以滿足上述協(xié)議轉換要求。MQI身作為消息中間件為JMSffl訊協(xié)議提供底層的通訊服務。但 ESB作為企業(yè)服務總線需 要有大吞吐量，而同步服務并發(fā)有限，容易造成資源的阻塞，以異步的方式進行訪 問，而MQ乍為消息中間件，是最好的異步通訊方式。2.4.4消息格式轉換支持通過元數(shù)據(jù)管理消息格式定義；支持任意類型報文之間的轉換。消息格式轉換是集成類系統(tǒng)應具備的基本功能，ESB 系統(tǒng)對于消息格式的轉換是基于配置實現(xiàn)的，因此消息報文的的數(shù)據(jù)域需要在配置中進行定義。ESB的服務接口規(guī)范標準中包括規(guī)范中使用的數(shù)據(jù)域。在ESB系統(tǒng)內部數(shù)據(jù)域分為不同的類型、長度、精度等表示

28、形式，ESB系統(tǒng)引用預先定義的、規(guī)范化的元數(shù)據(jù)對服 務接口規(guī)范進行描述，使用元數(shù)據(jù)可以是規(guī)范定義工作更加規(guī)范化、減少冗余、便于 管理和統(tǒng)一維護。元數(shù)據(jù)可根據(jù)應用范圍劃分成不同的“域”，可以更加方便的進行方便維護和管理。 ESB系統(tǒng)一般通過配置方式實現(xiàn)標準與非標準的報文轉換，包括：格式轉換和數(shù)據(jù)映 射，對于復雜的映射規(guī)則可以通過增加映射功能函數(shù)（服務組件）的形式實現(xiàn)MBSD接入框架提供了可配置的定長、變長報文轉換組件，以及可擴展的接口可以適 應各種不同格式的報文轉換。同時接入框架提供了MBSDt數(shù)據(jù)管理功能，能夠方便的定義報文的元數(shù)據(jù)，為報文的轉換以及應用的開發(fā)提供了便利。目前已經(jīng)支持 XML定

29、長等多種報文格式。2.4.5 服務路由基于服務ID、內容、結果等方式路由；交易流程能使用智能路由組合多個子交易。 我們采用兩個層次的路由：前端API進行的服務通路路由。前端API根據(jù)ESB平臺提供的接入?yún)?shù)信息決定采用哪條通路（MB/WEBMETHOD進行服務訪問。核心的交易路由。由MB/WEBMTHOD心進行路由，根據(jù)交易碼決定哪個后臺服務 系統(tǒng)進行服務訪問。路由方式：服務ID路由。也就是交易碼進行路由判斷。數(shù)據(jù)依賴路由。動態(tài)的根據(jù)報文中的數(shù)據(jù)和配置業(yè)務規(guī)則進行路由選擇。復雜流程路由。在復雜組合交易中根據(jù)每一步的響應結果和配置的復雜交易流程 來進行路由選擇。此路由在 ESB平臺的流程配置來實

30、現(xiàn)。2.4.6 監(jiān)控和運維提供服務調用的記錄、測量和監(jiān)控數(shù)據(jù)；提供事件檢測、觸發(fā)和發(fā)布功能；支持產(chǎn)品 版本升級后對現(xiàn)有組件的兼容性。ESB系統(tǒng)應記錄每一次服務訪問的流水信息，用于統(tǒng)計和分析。記錄過程應該是高效 的，應避免流水的記錄影響服務的執(zhí)行效率。流水記錄一般只記錄服務過程的摘要信 息。需要時，可以通過開關控制打開或關閉詳細的報文信息。系統(tǒng)還應及時捕獲服務處理過程中的各種異常信息，通過統(tǒng)一的控制臺發(fā)出報警，警 示信息應劃分異常的類別和級別，對于重要的異常還可以通過短信等手段及時通知運 維人員及時處理。監(jiān)控管理的接口定義應是可擴展的，例如異常種類、異常級別、流水信息數(shù)據(jù)項等, 做到信息的獲取與

31、后續(xù)的處理動作無關，從而保證接口的兼容性、穩(wěn)定性。247服務等級可定義不同的服務等級并實現(xiàn)具體內容?？梢詮亩喾N維度來定義服務的屬性，包括服務的級別。服務的級別可以關聯(lián)到不同的 處理動作。服務級別與處理的關聯(lián)關系可以通過規(guī)則進行定義，實現(xiàn)功能的靈活定義與擴展。關 聯(lián)的動作可以是：處理的優(yōu)先級，異常提醒方式等。2.5系統(tǒng)非功能需求2.5.1 可用性系統(tǒng)能提供功能方面的各種需求的實現(xiàn)，在運行環(huán)境下提供 7*24小時NONE-STO服 務；ESB是服務訪問的樞紐，不允許由于系統(tǒng)的故障和恢復過程中斷系統(tǒng)服務，ESB應采用群集模式保證系統(tǒng)的高可用性，群集模式還可以使系統(tǒng)資源得到充分利用。對于數(shù)據(jù)庫服務器、

32、通訊接入服務起等模塊的高可用性需求，為降低實現(xiàn)方案的復雜 度和實施成本，可采用設備之間相互熱備的方式。例如數(shù)據(jù)庫服務器可以和歸檔數(shù)據(jù) 庫服務器采用熱備的方式保證高可用性。系統(tǒng)自身的批量處理，如：數(shù)據(jù)歸檔清理，日志歸檔等工作，不能影響系統(tǒng)的正常運 行，保證系統(tǒng)7*24小時連續(xù)運行。需要定期進行的系統(tǒng)資源累積效應消除動作，如：定期重啟Java虛擬機消除長期運行后的堆棧碎片，應保證在其他群集模塊正常運行的情況依次進行，保證系統(tǒng)服務不 間斷。系統(tǒng)的配置更新應采用動態(tài)刷新的機制聯(lián)機進行，避免配置更新對系統(tǒng)的處理 能力造成影響。2.5.2 可擴展性 系統(tǒng)可以在CPU內存等資源增加及擴容的情況下自我線性擴展

33、處理能力；系統(tǒng)的架 構設計要保證系統(tǒng)的各個層次均可按照負載情況，單獨進行橫向的擴展，以提高處理 能力。應保證處理能力隨硬件資源的擴展呈線性增長。2.5.3 可維護性統(tǒng)具有較為完善的用戶管理界面，提供對系統(tǒng)所有功能的維護與參數(shù)配置管理的功 能；系統(tǒng)涉及到多種平臺產(chǎn)品和技術、采用多物理分區(qū)的部署方式，單獨對每個分區(qū)進行 監(jiān)控和維護是不現(xiàn)實的，必須提供統(tǒng)一的管理監(jiān)控界面，實現(xiàn)系統(tǒng)的集中統(tǒng)一管理、 監(jiān)控和維護。2.5.4 安全性提供認證和授權、不可否認和機密性、安全標準的支持等。ESB系統(tǒng)作為服務訪問的中間層，除了發(fā)布標準的安全規(guī)范以外，還要滿足各類集成應用的安全需求，要實現(xiàn)與存量服務系統(tǒng)的安全協(xié)議支

34、配，因此ESB需要支持通訊層面，應用層面的安全技術標準。例如：對標準安全協(xié)議的支持，通訊過程加解密，MAC校驗，PKI，特定場景的數(shù)字簽名等。2.5.5 性能需求統(tǒng)能通過招標人的壓力測試。性能指標：日均1000萬筆數(shù)據(jù)，ESB對于關鍵數(shù)據(jù)的處理時間1秒，對于非關鍵數(shù) 據(jù)ESB的處理時間2秒。達到系統(tǒng)性能指標峰值要求時，系統(tǒng)處理能力應留有足夠的余量，CPU內存等系統(tǒng)資源的使用率應低于80%達到平均值要求時，系統(tǒng)資源使用率應低于 50%保證系 統(tǒng)在設計指標壓力情況下的長期穩(wěn)定運行2.6公用服務2.6.1 流量控制當服務訪問量超過預設的流量值時，總線系統(tǒng)快速擋回對該服務的訪問請求，根據(jù)服 務系統(tǒng)的服

35、務響應時間和返回狀態(tài)，判斷服務狀態(tài)是否異常，當服務系統(tǒng)發(fā)生異常達 到設定的條件時，自動降低對該服務系統(tǒng)的訪問流量限制，避免服務系統(tǒng)的故障影響 范圍擴大。通過交易閥值的統(tǒng)計來完成實時的后臺系統(tǒng)服務質量統(tǒng)計。從而達到對前端系統(tǒng)訪問 的指示。在后臺服務質量不好的情況下，把針對此后臺的數(shù)據(jù)在接入層直接擋回，避 免交易在ESB中占用過多處理資源。由于系統(tǒng)超時時間一般設置的比較長，防止公用通路被單一后臺服務通道堵塞，需要 知道后臺系統(tǒng)的運行狀況，當出現(xiàn)問題后，及時隔離，不影響主通路運行。262 故障隔離服務系統(tǒng)發(fā)生異常達到設定的條件時，自動降低對該服務系統(tǒng)的訪問流量限制，避免 服務系統(tǒng)的故障影響范圍擴大。

36、保留少量的探測服務對故障系統(tǒng)進行探測，服務系統(tǒng) 故障排除恢復正常后，總線系統(tǒng)可自動恢復其正常的流量。2.6.3 統(tǒng)一流水號實現(xiàn)ESB平臺內統(tǒng)一標準平臺流水號的分配功能，唯一標識請求系統(tǒng)的發(fā)往ESB平臺單次服務調用。2.6.4 日志記錄應用日志作為服務系統(tǒng)的又一 I/O點，也可以采用異步模式。將一個服務線程在完成 一次報文處理過程中的所有日志集中一次性異步輸入到指定文件是必要的。一方面減 少業(yè)務處理線程的I/O操作，另一方面講一次業(yè)務處理的日志集中輸出相比傳統(tǒng)的多 線程分離輸出方便問題查找，大大增加了日志的可讀性。2.7 管理監(jiān)控由于實際部署的系統(tǒng)隨著需求的增加，部署會經(jīng)常發(fā)生變化，對于隨著出現(xiàn)

37、的多監(jiān)控 源，我們需要建立統(tǒng)一集中的管理和操作平臺。需要做到以下幾方面：2.7.1 系統(tǒng)平臺級監(jiān)控包括cpu，內存，文件系統(tǒng)，各隊列深度，應用日志，應用core文件等。2.7.2 應用級監(jiān)控包括各部署模塊的內部運行狀態(tài)2.7.3 統(tǒng)計分析既定的匯報機制、匯報內容和匯報格式。有些匯報的內容是通過手工統(tǒng)計匯總的，能 盡量將這些匯報物交由報表系統(tǒng)自動生成。ESB乍為全行的運行基礎平臺，需要能向IT部分提供全面的IT資源運行情況，為全行的IT資源分配提供依據(jù)。2.7.4 異常報警對平臺運行的問題進行報警，需要有統(tǒng)一的報警規(guī)范來支持未來報警類型的擴展，需 要提供多種報警模式，例如聲音，短信，微信等。2.

38、7.5 統(tǒng)一的運維管理提供應用日志，流水日志的統(tǒng)一處理，防止多點，多平臺部署情況下維護混亂的情 況。3 技術支持與服務方案公司在大力開拓市場的同時，高度重視售后服務及技術支持工作，始終恪守“客 戶滿意第一”的原則，以全力滿足用戶的一切需要為己任，向用戶提供“及時、專 業(yè)、真誠”的技術服務。公司不僅為用戶提供一流的產(chǎn)品，而且為用戶提供一流的服 務，在第一時間對用戶的服務要求做出響應。公司將盡心盡力與用戶緊密合作，為用戶單位提供及時、全面的技術支持和服 務，保障系統(tǒng)的正常運行。3.1技術支持與售后服務體系為滿足客戶系統(tǒng)7X24小時不間斷、高可靠地運行，公司按照國際質量標準，形 成了一套完備嚴謹?shù)馁|

39、量管理體系，實現(xiàn)了從產(chǎn)品、服務到公司運營全過程、全方位 的質量管理2000通過系統(tǒng)集咸一級賢炭趴；止2002通過二5級認證 蛭克:T獲羌禹二DA認證200?瀰垃踐027001值 烹宣全認證2013諫逗特一零蠶垢 事成資質認證1399£ E認證2001通二廣2 U近 認證2004應 0誦訶TIVIM巧級認證iSHPCMMS UUE 磁苴飯我C阪尸W網(wǎng)3.2服務管理模式公司將按如下模式進行技術支持與服務管理:1）公司服務代表是對客戶服務需求的接口，并定位服務內容，指定服務技術人 員,咨詢顧問。2）公司服務團隊負責提供維護支持服務。3）公司全體技術人員，咨詢顧問都可以作為后臺資源，為服務技

40、術人員，咨詢顧問 提供支持，滿足客戶的服務需求。在必要時還可以要求合作伙伴提供技術支持，為客戶提供滿意的服務。4）客戶的服務需求將按級別優(yōu)先級響應，并提供相應的服務。電価網(wǎng)訪.pl腫務曲吐單墀人袴氓豈-收甲1T叼嚴嗚價售戶需玳J僱憧.吐箝輸認單*刊機沆斗戸 記奉溝通制喪卵i.*電誦區(qū)村HU m ft)3.3 服務響應3.3.1 問題優(yōu)先級（或問題嚴重程度）級定義優(yōu)先級定義：優(yōu)先級判定標準1系統(tǒng)崩潰，無法啟動或拒絕連接等原因導致客戶無法獲得任何 系統(tǒng)服務，并對客戶業(yè)務的正常運行造成重大影響。2系統(tǒng)主要功能不能正常工作，并對客戶業(yè)務的正常運行造成較 大影響；生產(chǎn)系統(tǒng)不穩(wěn)定，并有周期性的中斷。3系統(tǒng)

41、有故障，但仍可全面運行，對客戶業(yè)務系統(tǒng)的正常運行有 一定的或輕微的影響4優(yōu)先級1、2和3之外的問題和需求，例如產(chǎn)品性能增強請求； 產(chǎn)品功能、安裝或配置方面需要信息或支持，對客戶的業(yè)務運 作幾乎無影響；非生產(chǎn)系統(tǒng)故障。嚴重程度定義:嚴重程度1:問題導致客戶的業(yè)務系統(tǒng)完全喪失服務功能，對業(yè)務至關重要的工 作無法繼續(xù)進行，情況緊急。具有如下特點：數(shù)據(jù)丟失、關鍵功能喪失、系統(tǒng)不正常刮起、系統(tǒng)崩潰，并在啟動后重復崩潰。嚴重程度2:問題導致客戶的業(yè)務系統(tǒng)喪失部分重要的服務功能，沒有可以接受 的替代解決方案，但業(yè)務系統(tǒng)可以有限的繼續(xù)運行。嚴重程度3:問題導致客戶的業(yè)務系統(tǒng)喪失較少的服務功能。對業(yè)務系統(tǒng)影響較

42、 小，需要提供解決方案以恢復功能。嚴重程度4:問題導致客戶的業(yè)務系統(tǒng)沒有喪失服務功能。一般是較小的錯誤信 息、不正確的結果或文檔錯誤，對業(yè)務系統(tǒng)運行沒有影響。3.3.2 服務響應時間在接到客戶方通過電話、信函、傳真、電子郵件等方式提出的服務請求后，我方 將在規(guī)定的響應時間內盡快做出響應，并根據(jù)問題的優(yōu)先級采取相應的措施。服務響應時間:優(yōu)先級響應時間1< 1小時2< 1工作日3< 2工作日4< 5工作日對優(yōu)先級為1的問題：公司將不分晝夜和節(jié)假日，立即安排相關人員與客戶溝 通，查找、分析問題原因，提供解決方案及處理意見，并采用遠程和現(xiàn)場服務的方 式，務求在最短的時間內解決客

43、戶的問題。對優(yōu)先級為2的問題：公司將不分節(jié)假日，在接到客戶服務請求的當天內，安排 相關人員與客戶溝通，查找、分析問題原因，提供解決方案及處理意見。在遠程登錄 無法解決問題時，最遲在48小時之內安排相關人員到達現(xiàn)場提供服務。對優(yōu)先級為3的問題：公司將在法定工作時間內安排相關人員與客戶聯(lián)系，盡可 能通過遠程服務方式為客戶處理問題。對優(yōu)先級為4的問題：公司將在法定工作時間內安排相關人員與客戶聯(lián)系，客戶 應與公司協(xié)商，確定采用遠程或現(xiàn)場服務方式及提供服務的時間注： 工作時間：周一至周五 9： 00- 18： 003.3.3 問題解決時間此項僅作為內部考核參考用，不作為對客戶的承諾。服務技術人員，咨詢顧

44、問在接到服務請求后，應該在規(guī)定的時間內給出解決方 案，并根據(jù)問題的優(yōu)先級采取相應的措施。解決時間:優(yōu)先級解決時間1< 0.5工作日2< 1工作日3< 2工作日4< 5工作日對優(yōu)先級為1的問題：維護技術人員，咨詢顧問應該在半個工作日內確認問題原 因，給出解決方案，或者至少給出解決問題的方向（例如：硬件問題：找硬件廠商 等）。對優(yōu)先級為2的問題：維護技術人員，咨詢顧問應該在一個工作日內確認問題原 因，給出解決方案，或者給出解決問題的方向（例如：數(shù)據(jù)問題，給出切換方案）， 并和客戶確認實施的時間點。對優(yōu)先級為3的問題：維護技術人員，咨詢顧問應該在兩個工作日內確認問題原 因，給出解決方案，或者給出解決問題的方向，并確認后續(xù)實施的方式（例如：流程 問題，重新設計流程、配置及測試）。對優(yōu)先級為4的問題：維護技術人員，咨詢顧問應該在兩個工作日內確認問題原 因，給出解決方案，或者給出解決問題的方向（例如：開