ESB提供事件驅(qū)動(dòng)和文檔導(dǎo)向的處理模式.docx

ESB提供事件驅(qū)動(dòng)和文檔導(dǎo)向的處理模式，以及分布式的運(yùn)行管理機(jī)制，支持基于內(nèi)容的路由和過濾，具備了復(fù)雜數(shù)據(jù)的傳輸能力，并可以提供一系列的標(biāo)準(zhǔn)接口。ESB是中間件技術(shù)實(shí)現(xiàn)并且支持SOA的一組基礎(chǔ)架構(gòu)，支持異構(gòu)環(huán)境中的服務(wù)、消息以及基于事件的交互，并且具有適當(dāng)?shù)姆?wù)級(jí)別和可管理性。ESB是SOA中的消息框架，即消息相互交換和通信的方式，是業(yè)界標(biāo)準(zhǔn)與客戶消息框架的整合。分布式部署和集中控制。ESB服務(wù)器在物理上可能相隔很遠(yuǎn)，但是通過集中管理，這些服務(wù)器組成一個(gè)ESB網(wǎng)絡(luò)，在邏輯上形成完整的企業(yè)服務(wù)總線。服務(wù)注冊(cè)、發(fā)布和編排。在Apusic ESB的服務(wù)倉(cāng)庫(kù)中，任何符合標(biāo)準(zhǔn)的服務(wù)都可以在其中注冊(cè)，從而被其他服務(wù)調(diào)用。而消費(fèi)服務(wù)也無需知道被調(diào)用服務(wù)的具體特征，只需要發(fā)送相應(yīng)地請(qǐng)求即可找到相應(yīng)的服務(wù)，并進(jìn)。行綁定和數(shù)據(jù)的傳輸。同時(shí)為了滿足具體的業(yè)務(wù)需求，不同的服務(wù)需要被組裝在一起形成新的應(yīng)用系統(tǒng)。Apusic ESB引入了工作流流程的概念，引入自主實(shí)現(xiàn)且基于業(yè)界標(biāo)準(zhǔn)的，具有條件分支和合并并行流轉(zhuǎn)功能的BPEL4WS流程引擎，從而實(shí)現(xiàn)綜合的、復(fù)雜的業(yè)務(wù)邏輯編排。這個(gè)流程引擎支持子流程、條件腳本、路由節(jié)點(diǎn)等功能。通過靈活的流程定義，按照即時(shí)的業(yè)務(wù)需求，將單個(gè)離散服務(wù)有機(jī)的組合起來，達(dá)到服務(wù)重組的目的，完成集成的業(yè)務(wù)需求。 此外，Apusic ESB在引擎級(jí)別將BPEL規(guī)范的細(xì)節(jié)進(jìn)行了包裝，對(duì)用戶來說，只需要關(guān)心流程中的一個(gè)服務(wù)即可，無須再去關(guān)心BPEL的具體技術(shù)細(xì)節(jié)。 最后，所有的調(diào)用、轉(zhuǎn)換都必須有一個(gè)良好的管理工具來幫助實(shí)施，并進(jìn)行監(jiān)控。Apusic ESB則提供了一體化的管理工具，通過這些工具，您可以非常方便的對(duì)ApusicESB進(jìn)行集中式管理、可視化的流程設(shè)計(jì)，以及運(yùn)行期的實(shí)時(shí)監(jiān)控等功能。SOA項(xiàng)目不應(yīng)從ESB開始,因?yàn)镋SB只是技術(shù)手段，而SOA的目標(biāo)則是業(yè)務(wù)價(jià)值。對(duì)技術(shù)手段的過分重視往往使人們忽略了SOA的最終目標(biāo)，陷入在技術(shù)的泥潭當(dāng)中不能自拔。 以ESB來啟動(dòng)一個(gè)SOA項(xiàng)目是有害的，它將陷入技術(shù)的怪圈中，而無法產(chǎn)生最大的業(yè)務(wù)價(jià)值。業(yè)務(wù)才應(yīng)該是SOA開始的起點(diǎn)和最終的目標(biāo)。你首先要在業(yè)務(wù)上進(jìn)行服務(wù)的分解，然后才把他們映射到技術(shù)實(shí)現(xiàn)中。 SOA項(xiàng)目的實(shí)施必須從業(yè)務(wù)需求的分析開始，而不是從構(gòu)建ESB來開始。SOA框架體系下的軟件開發(fā)，應(yīng)該是從業(yè)務(wù)流程分析開始的，用一些組件化的業(yè)務(wù)建模方法，對(duì)實(shí)際的業(yè)務(wù)場(chǎng)景進(jìn)行分析。在這個(gè)基礎(chǔ)上建立業(yè)務(wù)用例，并根據(jù)這些業(yè)務(wù)用例構(gòu)造業(yè)務(wù)流程模型。ESB不過工具和技術(shù)而已，關(guān)鍵上集成業(yè)務(wù)如何做?業(yè)務(wù)邏輯如何編制?如何實(shí)施? ESB項(xiàng)目需求分析和方案設(shè)計(jì)淺談2010-1-6如同其它IT項(xiàng)目一樣，企業(yè)服務(wù)總線類項(xiàng)目的實(shí)施也要經(jīng)歷需求分析、方案設(shè)計(jì)、編碼和測(cè)試、上線部署等階段。下面我們將針對(duì)ESB項(xiàng)目的設(shè)計(jì)和實(shí)施過程中各個(gè)階段要完成的主要工作內(nèi)容和一些最佳實(shí)踐跟大家作一些討論，進(jìn)而希望大家在企業(yè)ESB項(xiàng)目實(shí)施過程中借鑒科學(xué)的方法論的指導(dǎo)來保證其成功。 TT SOA編輯推薦：企業(yè)服務(wù)總線ESB（更新版）ESB的需求分析需求分析階段是梳理項(xiàng)目中相關(guān)功能需求和非功能需求的重要步驟，它是整個(gè)項(xiàng)目成敗的關(guān)鍵。在這個(gè)階段我們將從企業(yè)業(yè)務(wù)需求出發(fā)，梳理端到端的跨系統(tǒng)業(yè)務(wù)流程；基于業(yè)務(wù)流程，依據(jù)科學(xué)的方法論進(jìn)行服務(wù)鑒別；由服務(wù)列表出發(fā)，梳理服務(wù)的消費(fèi)和提供關(guān)系；然后根據(jù)SOA的最佳實(shí)踐，定義服務(wù)的接口，包括服務(wù)的Schema描述，字段的類型，編碼的規(guī)則；依據(jù)服務(wù)的消費(fèi)提供關(guān)系，梳理ESB中的服務(wù)映射和轉(zhuǎn)換規(guī)則和策略。概括而言，我們需要從功能性和非功能性兩個(gè)方面來進(jìn)行ESB的需求分析。針對(duì)ESB的功能性需求，我們要側(cè)重了解以下方面的問題：1. 梳理出要被集成的系統(tǒng)的名稱，個(gè)數(shù)。2. 針對(duì)每個(gè)系統(tǒng)而言，要了解：該系統(tǒng)的對(duì)外接口是向外調(diào)用，被別人調(diào)用，還是二者都有； 接口的實(shí)時(shí)性要求，是實(shí)時(shí)的還是批量的，還是二者皆有？ 接口的調(diào)用方式，是同步的還是異步的，還是二者皆有？ 應(yīng)用系統(tǒng)所運(yùn)行的操作系統(tǒng)平臺(tái)。 應(yīng)用系統(tǒng)本身的編程語言？C/C+, Java. 這些系統(tǒng)現(xiàn)有接口的情況，是否已經(jīng)可以提供對(duì)外接口，接口的方式是什么，包括接口的通訊協(xié)議是什么，HTTP/MQ/Socket/ 其它？接口的數(shù)據(jù)格式是什么，XML/ 自定義格式 / 其他行業(yè)標(biāo)準(zhǔn)格式？接口的編程語言是什么，Java/C/C+？如果本身不能提供接口，那么要做接口開發(fā)時(shí)有什么要求或限制條件？ 這些應(yīng)用后臺(tái)數(shù)據(jù)庫(kù)的情況，數(shù)據(jù)庫(kù)能否直接訪問？ 每個(gè)應(yīng)用跟其他應(yīng)用交換數(shù)據(jù)時(shí)，源數(shù)據(jù)格式和目的數(shù)據(jù)格式，比如從文本格式轉(zhuǎn)換為 XML 格式？ 交易特征：哪些處理要采用兩階段提交；是否需要多個(gè)消息組成一個(gè)交易；是否要保證消息之間的處理順序； 適配器的情況：對(duì)于一些特殊系統(tǒng)，是否已經(jīng)具備現(xiàn)成的適配器；適配器是單向的還是雙向的； 消息通信的模式：是Send and Forget、Request/Reply還是Pub/Sub? 針對(duì)ESB的非功能性需求，我們要確認(rèn)：1. ESB平臺(tái)的擴(kuò)展性和高可用性需求，包括HA和集群等；2. ESB平臺(tái)的性能需求，主要包括系統(tǒng)間數(shù)據(jù)交換的頻率，要交換的數(shù)據(jù)的大小 ( 消息大小將直接對(duì)效率造成影響 )；峰值時(shí)候?qū)SB數(shù)據(jù)吞吐量、響應(yīng)時(shí)間的要求等；3. 哪些交易要保證數(shù)據(jù)傳輸?shù)母呖煽啃裕?. ESB平臺(tái)的可管理性需求，如服務(wù)的生命周期管理，ESB 平臺(tái)的維護(hù)和管理；如果企業(yè)已經(jīng)設(shè)立了SOA管控方面的規(guī)范，那么要遵從規(guī)范的制約，比如要考慮是否有規(guī)定的命名規(guī)則，企業(yè)是否有企業(yè)級(jí)的數(shù)據(jù)規(guī)范和底層通訊協(xié)議的規(guī)范等；5. 安全性方面的要求：是否采用SSL傳輸加密，是否對(duì)消息進(jìn)行加密/解密處理等；6. 錯(cuò)誤處理和日志以及平臺(tái)本身的運(yùn)行監(jiān)控等方面的要求等。ESB的方案設(shè)計(jì)方案設(shè)計(jì)的主要內(nèi)容包括：ESB涉及IT應(yīng)用環(huán)境分析，定義ESB與相關(guān)應(yīng)用的接口模式； ESB架構(gòu)概要設(shè)計(jì)，并定義架構(gòu)原則； ESB相關(guān)產(chǎn)品選擇，包括與外圍系統(tǒng)的適配器選擇和ESB產(chǎn)品選擇； ESB組件模型設(shè)計(jì)，分解ESB的相關(guān)模塊，滿足SOA的分離關(guān)注點(diǎn)等架構(gòu)原則； ESB運(yùn)作模型設(shè)計(jì)，滿足平臺(tái)的非功能性需求； ESB平臺(tái)的服務(wù)流設(shè)計(jì)，涉及路由、轉(zhuǎn)換和映射等； ESB的同步、異步或者發(fā)布/訂閱模式設(shè)計(jì)； ESB平臺(tái)的接入渠道和數(shù)據(jù)接口設(shè)計(jì)，包括XML/JMS、SOAP/HTTP、EDI/MQ 等； ESB相關(guān)的適配器設(shè)計(jì)，包括技術(shù)適配器或者自開發(fā)的適配器； ESB平臺(tái)的容錯(cuò)和重試機(jī)制設(shè)計(jì)，包括日志等的統(tǒng)一管理等； 圖 1 是一個(gè)采用ESB整合的高層架構(gòu)設(shè)計(jì)舉例：圖 1. ESB參考架構(gòu) 如圖 1 所示，ESB架構(gòu)設(shè)計(jì)時(shí)主要要考慮通訊協(xié)議接入和轉(zhuǎn)換、數(shù)據(jù)接入和轉(zhuǎn)換、數(shù)據(jù)處理流程以及服務(wù)的注冊(cè)和管理等方面的內(nèi)容。其中通訊協(xié)議接入和轉(zhuǎn)換是指對(duì)各種被集成的應(yīng)用系統(tǒng)的通訊協(xié)議的支持和轉(zhuǎn)換能力，例如HTTP、JMS、Socket、FTP等；數(shù)據(jù)接入和轉(zhuǎn)換是指對(duì)各種被集成的應(yīng)用系統(tǒng)提供的數(shù)據(jù)格式的支持和轉(zhuǎn)換能力，例如XML、SOAP、自定義格式以及符合某些行業(yè)標(biāo)準(zhǔn)的專有格式（SWIFT、EDI、HL7 等）；數(shù)據(jù)處理流程是指路由、格式轉(zhuǎn)換、數(shù)據(jù)庫(kù)讀寫等對(duì)數(shù)據(jù)的各種處理；統(tǒng)一服務(wù)注冊(cè)存儲(chǔ)管理是指對(duì)服務(wù)的注冊(cè)、發(fā)布、查詢，以及對(duì)運(yùn)營(yíng)時(shí)服務(wù)的管控，并且提供服務(wù)運(yùn)營(yíng)狀態(tài)的統(tǒng)計(jì)分析數(shù)據(jù)。ESB的組件模型圖 2. ESB組件模型 圖 2 給出了一個(gè)ESB組件模型的示例，其中包含的各主要組件及其功能如下：1. Message Broker Runtime組件提供消息路由、格式轉(zhuǎn)換、消息日志等操作的運(yùn)行時(shí)環(huán)境。該運(yùn)行環(huán)境由IBM Message Broker提供；2. Messaging Broker Instance組件是處理基于MQ消息業(yè)務(wù)請(qǐng)求的容器。它是作為一個(gè)Broker實(shí)例運(yùn)行在Message Broker Runtime上的。該實(shí)例提供了MQ消息的業(yè)務(wù)請(qǐng)求處理器、服務(wù)日志、服務(wù)定位等功能的運(yùn)行容器；3. Web Service Broker Instance組件是處理基于Web Service的業(yè)務(wù)請(qǐng)求的容器，它是作為一個(gè)Broker實(shí)例運(yùn)行在Message Broker Runtime上的。該實(shí)例提供了Web Service的業(yè)務(wù)請(qǐng)求處理、服務(wù)日志、以及服務(wù)定位等功能。4. Event Broker Instance組件是平臺(tái)內(nèi)部處理Pub/Sub事件的容器。它是作為一個(gè)Broker實(shí)例運(yùn)行在Message Broker Runtime上的。該容器提供了Event Handler組件的運(yùn)行環(huán)境，將基于MQ/JMS的事件分發(fā)到不同平臺(tái)組件的目標(biāo)隊(duì)列上。5. Message Handler組件是處理基于MQ消息的業(yè)務(wù)請(qǐng)求，包括消息解析、格式轉(zhuǎn)換，服務(wù)鑒權(quán)與認(rèn)證、服務(wù)路由、服務(wù)日志等功能。Message Handler組件處理MQ消息的典型流程如下：首先對(duì)MQ消息進(jìn)行解析，對(duì)解析后的業(yè)務(wù)請(qǐng)求進(jìn)行分析，之后通過Authentication 與 Authorization組件判斷該請(qǐng)求者的業(yè)務(wù)請(qǐng)求是否可以進(jìn)行后續(xù)處理； 通過Service Locating組件對(duì)該業(yè)務(wù)請(qǐng)求進(jìn)行服務(wù)定位與路由；將基于MQ的業(yè)務(wù)請(qǐng)求消息轉(zhuǎn)換成Web Service的業(yè)務(wù)請(qǐng)求消息； 通過Service Logging組件對(duì)整個(gè)業(yè)務(wù)請(qǐng)求進(jìn)行日志記錄； 返回業(yè)務(wù)請(qǐng)求處理結(jié)果給業(yè)務(wù)發(fā)起者，如果失敗，返回錯(cuò)誤消息。 6. Web Service Handler組件是處理基于Web Service的業(yè)務(wù)請(qǐng)求，與Message Handler組件功能類似，也包括消息解析、格式轉(zhuǎn)換，服務(wù)鑒權(quán)與認(rèn)證、服務(wù)路由、服務(wù)日志等功能。Web ServiceHandler組件處理Web Service請(qǐng)求的典型流程如下：首先對(duì)Web Service請(qǐng)求消息進(jìn)行解析，對(duì)解析后的業(yè)務(wù)請(qǐng)求進(jìn)行分析，之后通過Authentication與Authorization組件判斷該請(qǐng)求者的業(yè)務(wù)請(qǐng)求是否可以進(jìn)行后續(xù)處理； 通過Service Locating組件對(duì)該業(yè)務(wù)請(qǐng)求進(jìn)行服務(wù)定位與路由； 通過 Service Logging 組件對(duì)整個(gè)業(yè)務(wù)請(qǐng)求進(jìn)行日志記錄； 返回業(yè)務(wù)請(qǐng)求處理結(jié)果給業(yè)務(wù)發(fā)起者，如果失敗，返回錯(cuò)誤消息。 7. Event Handler組件實(shí)現(xiàn)對(duì)Pub/Sub的處理。8. Service Locating組件負(fù)責(zé)根據(jù)業(yè)務(wù)請(qǐng)求定位具體的服務(wù)提供者。Service Locating通過對(duì)服務(wù)目錄的查詢選擇適合的服務(wù)進(jìn)行后續(xù)的調(diào)用，該查詢工作可以通過實(shí)時(shí)的服務(wù)目錄查詢獲得結(jié)果。9. Service Logging組件負(fù)責(zé)記錄整個(gè)業(yè)務(wù)請(qǐng)求處理過程中的情況，該組件的實(shí)現(xiàn)可以通過文件或者數(shù)據(jù)庫(kù)的方式。10. Authentication組件負(fù)責(zé)對(duì)業(yè)務(wù)請(qǐng)求者進(jìn)行鑒權(quán)，判斷該業(yè)務(wù)請(qǐng)求者是否可以訪問平臺(tái)服務(wù)，該鑒權(quán)的工作在企業(yè)服務(wù)總線的外部進(jìn)行，Authentication組件只是調(diào)用外部功能完成。11. Authorization組件判斷業(yè)務(wù)請(qǐng)求者是否具備訪問某特定服務(wù)的權(quán)限，該驗(yàn)證權(quán)限的工作在企業(yè)服務(wù)總線的外部進(jìn)行，Authorization 組件只是調(diào)用外部功能完成。以處理基于MQ消息輸入為例，ESB的組件交互圖如圖 3 所示：圖 3. ESB組件交互圖 ESB方案設(shè)計(jì)時(shí)的最佳實(shí)踐根據(jù)我們以往項(xiàng)目設(shè)計(jì)和開發(fā)時(shí)的一些經(jīng)驗(yàn)，我們建議進(jìn)行ESB的方案設(shè)計(jì)時(shí)要遵循下述最佳實(shí)踐：確定標(biāo)準(zhǔn)的使用：使用與否、使用到什么程度； 確定在ESB上實(shí)現(xiàn)的業(yè)務(wù)邏輯：ESB是一個(gè)服務(wù)路由和轉(zhuǎn)換中心，而不是一個(gè)應(yīng)用服務(wù)器，因此它并不能取代應(yīng)有服務(wù)器。復(fù)雜的消息解析和轉(zhuǎn)換相比簡(jiǎn)單的路由操作所需消耗的成本要高的多，因此在ESB上應(yīng)該主要考慮路由、格式轉(zhuǎn)換、服務(wù)調(diào)用等問題，而對(duì)于數(shù)據(jù)本身的處理應(yīng)該交給相應(yīng)的應(yīng)用來完成； 確定消息格式：從標(biāo)準(zhǔn)化的角度而言，XML當(dāng)然是首選，但是從解析 / 處理性能、行業(yè)標(biāo)準(zhǔn)以及對(duì)現(xiàn)有應(yīng)用的最大兼容性的角度而言，可能會(huì)采用某些特定格式，例如EDI、SWITF、平文本或者自定義格式等； 區(qū)別消息頭和消息體：把數(shù)據(jù)的Meta-data，例如：安全相關(guān)的信息、日志的等級(jí)、請(qǐng)求端的標(biāo)識(shí)等放在消息頭中，而不要放在消息體中。這樣可以很容易地改變其內(nèi)容及其對(duì)其的處理邏輯。在ESB中只處理消息頭，避免對(duì)消息體的解析； 設(shè)計(jì)時(shí)參考ESB相關(guān)的成熟Patterns； 使用服務(wù)注冊(cè)庫(kù)：如需要服務(wù)Endpoint的查找：推薦從服務(wù)注冊(cè)中心進(jìn)行查找，這樣的好處在于：服務(wù)提供者可以容易地發(fā)布新的服務(wù)，服務(wù)提供者和ESB之間的耦合度可以更低，通過關(guān)于服務(wù)本身的Metadata來進(jìn)行服務(wù)的查找和路由； 注重性能和高可用性的考慮； 在必須的情況下考慮交易完整性； 適配器的采用：應(yīng)用系統(tǒng)通過適配器實(shí)現(xiàn)與 ESB 的雙向交互，適配器主要分為技術(shù)適配器、應(yīng)用適配器兩種，適配器的物理部署可以與EIS部署在一起、或者與ESB部署在一起，也可以單獨(dú)部署，在適配器設(shè)計(jì)時(shí)要考慮通信協(xié)議和消息格式兩個(gè)方面；多 ESB 的設(shè)計(jì)：ESB 也是一個(gè)邏輯的組件，在一個(gè)企業(yè)里可能需要多個(gè)ESB，例如：企業(yè)內(nèi)部ESB連接企業(yè)內(nèi)部各個(gè)系統(tǒng)，外部ESB實(shí)現(xiàn)企業(yè)與合作伙伴等的外部連接；再如：企業(yè)內(nèi)部可能存在若干個(gè)部門級(jí)ESB和一個(gè)全企業(yè)ESB； 確定服務(wù)版本控制策略； 確定端到端的QoS準(zhǔn)則； 注重安全性； 確定IT部門ESB平臺(tái)的負(fù)責(zé)主體，長(zhǎng)期的投入。 ESB的安全性考慮對(duì)于ESB的安全性考慮，主要有兩種方式，第一種方式是通過ESB內(nèi)部的Mediation節(jié)點(diǎn)來進(jìn)行服務(wù)請(qǐng)求者的認(rèn)證 / 授權(quán)；另一種是調(diào)用一個(gè)外部服務(wù)進(jìn)行服務(wù)請(qǐng)求者的認(rèn)證 / 授權(quán)，如圖4所示，圖中給出了這兩種方式的示意圖，具體實(shí)施時(shí)可以進(jìn)行選擇。圖 4. ESB的兩種安全實(shí)現(xiàn)方式 運(yùn)行在ESB平臺(tái)上的服務(wù)的管理和監(jiān)控當(dāng)一個(gè)企業(yè)開始它的SOA之旅時(shí)，開始階段通常會(huì)選取一個(gè)具體的項(xiàng)目進(jìn)行 SOA 的嘗試，然后便會(huì)逐步走向全企業(yè)采納，這時(shí)，大多數(shù)企業(yè)都會(huì)面臨一個(gè)問題，那就是服務(wù)越來越多，對(duì)這些服務(wù)目錄的管理出現(xiàn)了很多問題，例如：所有與服務(wù)相關(guān)的信息是如何被管理的，包括存儲(chǔ)、管理、維護(hù)、存取等？服務(wù)請(qǐng)求者如何決定使用哪個(gè)服務(wù)？服務(wù)請(qǐng)求者如何定位服務(wù)的 Endpoint？當(dāng)服務(wù)信息發(fā)生改變時(shí)如何得到通知？因此我們建議用戶在盡可能早的情況下考慮服務(wù)注冊(cè)中心的建設(shè)，所謂服務(wù)注冊(cè)中心是一個(gè)企業(yè)范圍內(nèi)的服務(wù)信息的存儲(chǔ)庫(kù)，該存儲(chǔ)庫(kù)存儲(chǔ)了企業(yè)中注冊(cè)的服務(wù)和服務(wù)相關(guān)的信息，它的主要功能包括：采用集中的方式來管理服務(wù)相關(guān)的信息，為服務(wù)元數(shù)據(jù)同時(shí)提供“注冊(cè)中心”功能，允許用戶存儲(chǔ)、管理和查詢包含服務(wù)描述的服務(wù)元數(shù)據(jù)構(gòu)件； 提供服務(wù)的治理功能，實(shí)現(xiàn)整個(gè)服務(wù)生命周期的管理； 提供服務(wù)間依賴、包容關(guān)系的管理； 提供分類和版本控制等功能； 提供服務(wù)發(fā)現(xiàn)和通知等能力等。 除了服務(wù)注冊(cè)中心的考慮之外，我們還要考慮對(duì)服務(wù)的管理。服務(wù)不僅具有特定的功能，還應(yīng)該滿足一些諸如性能、可用性、安全性等QoS指標(biāo)。服務(wù)響應(yīng)的快慢、什么時(shí)間可用、可以被誰調(diào)用、在某個(gè)時(shí)間段里能被調(diào)用多少次、哪些事件要記錄日志，這些都是服務(wù)管理要考慮的問題。通過服務(wù)注冊(cè)中心和服務(wù)監(jiān)控平臺(tái)的有機(jī)配合，我們可以根據(jù)服務(wù)的響應(yīng)時(shí)間、服務(wù)可用與否等策