【導讀】日期版本變更說明作者。2021年11月18日創(chuàng)建王杰

　　

【正文】 時發(fā)現(xiàn)，通過監(jiān)控平臺發(fā)出報警，通過人工手段或預先設定的規(guī)則，對狀態(tài)異常的服務或服務系統(tǒng)進行迅速隔離，避免因故障導致服務阻塞，保證請求系 統(tǒng)對其他服務的正常訪問。 . 協(xié)議轉(zhuǎn)換 支持外部系統(tǒng)通過 TCP/IP、 HTTP、 SNA、 FTP、 MQSeries、 JMS 等協(xié)議和中間件與ESB 平臺通訊 。 一般情況下，請求系統(tǒng)使用 ESB 系統(tǒng)提供的 API，按照 ESB 系統(tǒng)的技術(shù)標準和服務規(guī)范進行服務訪問，從而避免不必要的協(xié)議轉(zhuǎn)換開銷。 但是對于請求系統(tǒng)無法改造或改造成本過高的情況下， ESB 系統(tǒng)應提供接入?yún)f(xié)議適配的功能，支持外部系統(tǒng)通過不同的通訊協(xié)議與 ESB 平臺通訊。 但是應注意， ESB 更多的情況下是為了適應服務系統(tǒng)的技術(shù)差異，才進行通訊的適配，從系統(tǒng)的規(guī)范化和易維護 性角度考慮，不推薦被動的對請求系統(tǒng)進行通訊協(xié)議適配。 接入框架提供了對各種通訊協(xié)議的轉(zhuǎn)換適配器，可以滿足上述協(xié)議轉(zhuǎn)換要求。 MQ 自身作為消息中間件為 JMS 通訊協(xié)議提供底層的通訊服務。但 ESB 作為企業(yè)服務總線需要有大吞吐量，而同步服務并發(fā)有限，容易造成資源的阻塞，以異步的方式進行訪問，而 MQ 作為消息中間件，是最好的異步通訊方式。 . 消息格式轉(zhuǎn)換 支持通過元數(shù)據(jù)管理消息格式定義；支持任意類型報文之間的轉(zhuǎn)換。 消息格式轉(zhuǎn)換是集成類系統(tǒng)應具備的基本功能， ESB 系統(tǒng)對于消息格式的轉(zhuǎn)換是基于配置實現(xiàn)的，因此消息報文的的數(shù)據(jù) 域需要在配置中進行定義。 ESB 的服務接口規(guī)范標準中包括規(guī)范中使用的數(shù)據(jù)域。在 ESB 系統(tǒng)內(nèi)部數(shù)據(jù)域分為不同的類型、長度、精度等表示形式， ESB 系統(tǒng)引用預先定義的、規(guī)范化的元數(shù)據(jù)對服務接口規(guī)范進行描述，使用元數(shù)據(jù)可以是規(guī)范定義工作更加規(guī)范化、減少冗余、便于管理和統(tǒng)一維護。 元數(shù)據(jù)可根據(jù)應用范圍劃分成不同的“域”，可以更加方便的進行方便維護和管理。 ESB 系統(tǒng)一般通過配置方式實現(xiàn)標準與非標準的報文轉(zhuǎn)換，包括：格式轉(zhuǎn)換和數(shù)據(jù)映射，對于復雜的映射規(guī)則可以通過增加映射功能函數(shù)（服務組件）的形式實現(xiàn) MBSD 接入框架提 供了可配置的定長、變長報文轉(zhuǎn)換組件，以及可擴展的接口可以適應各種不同格式的報文轉(zhuǎn)換。同時接入框架提供了 MBSD 元數(shù)據(jù)管理功能，能夠方便的定義報文的元數(shù)據(jù)，為報文的轉(zhuǎn)換以及應用的開發(fā)提供了便利。 目前已經(jīng)支持 XML，定長等多種報文格式。 . 服務路由 基于服務 ID、內(nèi)容、結(jié)果等方式路由；交易流程能使用智能路由組合多個 子交易。 我們采用兩個層次的路由： ? 前端 API 進行的服務通路路由。 前端 API 根據(jù) ESB 平臺提供的接入?yún)?shù)信息決定采用哪條通路（ MB/WEBMETHODS）進行服務訪問（詳見 API 參數(shù)下載說明）。 ? 核 心的交易路由。由 MB/WEBMTHODS 核心進行路由，根據(jù)交易碼決定哪個后臺服務系統(tǒng)進行服務訪問。 路由方式： ? 服務 ID 路由。也就是交易碼進行路由判斷。 ? 數(shù)據(jù)依賴路由。動態(tài)的根據(jù)報文中的數(shù)據(jù)和配置業(yè)務規(guī)則進行路由選擇。 ? 復雜流程路由。在復雜組合交易中根據(jù)每一步的響應結(jié)果和配置的復雜交易流程來進行路由選擇。此路由在 ESB 平臺的流程配置來實現(xiàn)。 . 監(jiān)控和運維 提供服務調(diào)用的記錄、測量和監(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ù)項等，做到信息的獲取與后續(xù)的處理動作無關，從而保證接口的兼容性、穩(wěn)定性。 . 服務等級 可定義不同的服務等級并實現(xiàn)具體內(nèi)容。 可以從多種維度來定義服務的屬性，包括服務的級別。服務的級別可以關聯(lián)到不同的處理動作。 服務級別與處理的關聯(lián)關系可以通過規(guī)則進行定義，實現(xiàn)功能的靈活定義與擴展。關聯(lián)的動作可以是：處理的優(yōu)先級，異常提醒方式等。 5. 系統(tǒng)非功能需求 . 可用性 系統(tǒng)能提供功能方面的各種需求的實現(xiàn)，在運行環(huán)境下提供 7*24 小時 NONESTOP 服務； ESB 是服務訪問的樞紐，不允許由于系統(tǒng)的故障和恢復過程中斷系統(tǒng)服務， ESB 應采用群集模式保證系統(tǒng)的高可用性，群集模式還可以使系統(tǒng)資源得到充分利用。 對于數(shù)據(jù)庫服務器、通訊接入服務起等模塊的 高可用性需求，為降低實現(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)的處理能力造成影響。 . 可擴展性 系統(tǒng) 可以在 CPU、內(nèi)存等資源增加及擴容的情況下自我線性擴展處理能力； 系統(tǒng)的架構(gòu)設計要保證系統(tǒng)的各個層次均可按照負載情況，單獨進行橫向的擴展，以提高處理能力。應保證處理能力隨硬件資源的擴展呈線性增長。 . 可維護性 統(tǒng)具有較為完善的用戶管理界面，提供對系統(tǒng)所有功能的維護與參數(shù)配置管理的功能； 系統(tǒng)涉及到多種平臺產(chǎn)品和技術(shù)、采用多物理分區(qū)的部署方式，單獨對每個分區(qū)進行監(jiān)控和維護是不現(xiàn)實的，必須提供統(tǒng)一的管理監(jiān)控界面，實現(xiàn)系統(tǒng)的集中統(tǒng)一管理、監(jiān)控和維護。 . 安全性 提供認證和授權(quán)、不可否認和機密性、安全標準的支持等。 ESB 系統(tǒng)作為服務訪問的中間層，除了發(fā)布標準的安全規(guī)范以外，還要滿足各類集成應用的安全需求，要實現(xiàn)與存量服務系統(tǒng)的安全協(xié)議支配，因此 ESB 需要支持通訊層面，應用層面的安全技術(shù)標準。例如：對標準安全協(xié)議的支持，通訊過程加解密， MAC 校驗， PKI，特定場景的數(shù)字簽名等。 . 性能需求 統(tǒng)能通過招標人的壓力測試。 性能指標：日均 1000 萬筆交易， ESB 對于關鍵交易的處理時間 1 秒，對于非關鍵交易 ESB的處理時間 2 秒。 達到系統(tǒng)性能指標峰值要求時，系統(tǒng)處理能力應留有足夠的余量， CPU，內(nèi)存等系統(tǒng)資源的使用率應低于 80%，達到平均值要求時，系統(tǒng)資源使用率應低于 50%。保證系統(tǒng)在設計指標壓力情況下的長期穩(wěn)定運行。 6. 公用服務 . 流量控制 當服務訪問量超過預設的流量值時，總線系統(tǒng)快速擋回對該服務的訪問請求，根據(jù)服務系統(tǒng)的服務響應時間和返回狀態(tài)，判斷服務狀態(tài)是否異常，當服務系統(tǒng)發(fā)生異常達到設定的條件時，自動降低對該服務系統(tǒng)的訪問流量限制，避免服務系統(tǒng)的故障影響范圍擴大。 通過交易閥值的統(tǒng)計來完成實時的后臺系統(tǒng)服務質(zhì)量統(tǒng)計。從而達到對前端渠道 /系統(tǒng)訪問的指示。在后臺服務質(zhì)量不好的情況下，把針對此后臺的交易在接入層直接擋回，避免交易在ESB 中占用過多處理資源。 由于系統(tǒng)超時時間一般設置的比較長，防止公用通路被單一后臺服務通道堵塞，需要知道后臺系統(tǒng)的運行狀況，當出現(xiàn)問題后，及時隔離，不影響主通路運行。 . 故障隔離 服務系統(tǒng)發(fā)生異常達到設定的條件時，自動降低對該服務系統(tǒng)的訪問流量限制，避免服務系統(tǒng)的故障影響范圍擴大。保留少量的探測服務對故障系統(tǒng)進行探測，服務系統(tǒng)故障排除恢復正常后，總線系統(tǒng)可自動恢復其正常的流量。 . 統(tǒng)一流水號 實現(xiàn) ESB 平臺內(nèi)統(tǒng)一標準平臺流水號的分配功能，唯一標識請求系統(tǒng)的發(fā)往 ESB 平臺單次服務調(diào)用。 . 日志記錄 應用日志作為服 務系統(tǒng)的又一 I/O 點，也可以采用異步模式。將一個服務線程在完成一次報文處理過程中的所有日志集中一次性異步輸入到指定文件是必要的。一方面減少業(yè)務處理線程的 I/O 操作，另一方面講一次業(yè)務處理的日志集中輸出相比傳統(tǒng)的多線程分離輸出方便問題查找，大大增加了日志的可讀性。 7. 管理監(jiān)控 由于實際部署的系統(tǒng)隨著需求的增加，部署會經(jīng)常發(fā)生變化，對于隨著出現(xiàn)的多監(jiān)控源，我們需要建立統(tǒng)一集中的管理和操作平臺。需要做到以下幾方面： 1. 系統(tǒng)平臺級監(jiān)控。包括 cpu，內(nèi)存，文件系統(tǒng)，各隊列深度，應用日志，應用 core 文件等。 2. 應用級監(jiān)控。 包括各部署模塊的內(nèi)部運行狀態(tài) . 3. 統(tǒng)計分析。既定的匯報機制、匯報內(nèi)容和匯報格式。有些匯報的內(nèi)容是通過手工統(tǒng)計匯總的，能盡量將這些匯報物交由報表系統(tǒng)自動生成。 ESB 作為全行的運行基礎平臺，需要能向 IT 部分提供全面的 IT 資源運行情況，為全行的 IT 資源分配提供依據(jù)。 4. 異常報警。對平臺運行的問題進行報警，需要有統(tǒng)一的報警規(guī)范來支持未來報警類型的擴展，需要提供多種報警模式，例如聲音，短信等。 5. 統(tǒng)一的運維管理。提供應用日志，流水日志的統(tǒng)一處理，防止多點，多平臺部署情況下維護混亂的情況。