江蘇公司第三代支撐系統(tǒng)CRM云化實踐經(jīng)驗.docx

江蘇公司第三代支撐系統(tǒng)CRM云化實踐經(jīng)驗構建組件庫，采用灰度割接策略，保障系統(tǒng)平滑過渡1. 項目背景4G時代，加速中國移動由語音業(yè)務向數(shù)據(jù)業(yè)務全面轉(zhuǎn)型，圍繞互聯(lián)網(wǎng)化業(yè)務模式的需求日益旺盛，在此大背景下，江蘇公司面臨全新的業(yè)務及技術挑戰(zhàn)。為應對移動互聯(lián)網(wǎng)蓬勃發(fā)展、4G時代流量經(jīng)營、云計算和大數(shù)據(jù)的轉(zhuǎn)型挑戰(zhàn)，江蘇公司第三代業(yè)務支撐系統(tǒng)圍繞系統(tǒng)X86云化改造、多中心解耦、軟件組件庫建設、技術架構全面升級，提升系統(tǒng)并發(fā)處理能力與快速響應市場能力，實現(xiàn)系統(tǒng)低成本高效率運行，保障江蘇移動在4G時代的業(yè)務、技術先進性與市場競爭力，支撐4G時代的業(yè)務創(chuàng)新與轉(zhuǎn)型、強化線上線下渠道融合能力、強化互聯(lián)網(wǎng)商業(yè)模式和互聯(lián)網(wǎng)營銷模式的支撐能力，提升客戶體驗與業(yè)務運營能力。江蘇公司作為集團公司首批試點省，于2014年初啟動第三代業(yè)務支撐系統(tǒng)項目的規(guī)劃、建設工作。根據(jù)公司總體要求，項目采取“技術和業(yè)務雙驅(qū)動、架構云化、多中心解耦、平滑過渡”的建設原則，逐步實現(xiàn)CRM系統(tǒng)向互聯(lián)網(wǎng)云化架構演進。2. 現(xiàn)狀分析江蘇公司雖然在2014年上半年前已完成CRM系統(tǒng)WEB層100%X86云化改造，但是應用層和數(shù)據(jù)庫仍然以小型機為主要基礎設施，擴容成本高，建設周期長，水平擴展困難。現(xiàn)有的傳統(tǒng)架構制約了公司互聯(lián)網(wǎng)轉(zhuǎn)型業(yè)務的發(fā)展，以江蘇公司世界杯期間搶紅包為例，瞬時業(yè)務并發(fā)量增長2000%，導致接口堵塞，業(yè)務訂購失敗。另外，我省雖然CRM和BOSS系統(tǒng)完全解耦，但是CRM系統(tǒng)內(nèi)部各模塊之間的耦合性仍然很高，無法支持按照模塊輕量改造發(fā)布上線。我省的架構，采用點對點集成為主，服務共享不足，接口復用性不足，支撐效率較低。為此，我省積極參與集團公司第三代CRM云化試點項目，進行系統(tǒng)X86云化架構改造，建立一套松耦合、高并發(fā)、低成本，快速響應市場需求的輕量化支撐系統(tǒng)。在CRM系統(tǒng)云化改造和割接過程中，項目團隊遇到諸多困難和挑戰(zhàn)。江蘇公司CRM系統(tǒng)經(jīng)過多年的建設和沉淀，系統(tǒng)非常龐大、復雜，業(yè)務規(guī)則、服務缺乏統(tǒng)一管理，服務和接口缺乏生命周期的管理機制，系統(tǒng)中存在大量冗余服務和接口，給系統(tǒng)平滑割接提出了新的挑戰(zhàn)。我省在第三代CRM項目試點過程中除了滿足集團公司規(guī)范和試點要求外，重點圍繞我省系統(tǒng)支撐面臨的困難，制定針對性的建設和割接方案。2.1、面臨的困難一：軟件組件服務缺乏統(tǒng)一管理，復用性不足，導致系統(tǒng)無序增長，梳理改造復雜原CRM系統(tǒng)中有成千上萬個服務、方法、接口、進程等軟件組件，這些軟件組件之間的關聯(lián)關系更是錯綜復雜，合理有效地繼承割接到第三代云化架構存在諸多問題。問題1：“核心能力”缺乏有效的掌控手段。軟件組件都是業(yè)務支撐系統(tǒng)核心能力，沒有顯性化的統(tǒng)一管理系統(tǒng)，開發(fā)商和移動方人員無法了解支撐系統(tǒng)的軟件組件全局視圖。在云化架構改造割接過程中，容易出現(xiàn)軟件組件改造遺漏或錯誤。問題2：軟件組件復用性不足。開發(fā)商在進行需求設計和開發(fā)過程中，明明已有現(xiàn)成的軟件組件，或者只需要對原有軟件組件稍作修改（例如：增加參數(shù)）就可以復用，但是往往為了規(guī)避風險或由于不熟悉系統(tǒng)的軟件組件，不能確定原有的軟件組件使用的場景，無法評估修改原有軟件組件會帶來什么風險，因此，為了保險起見，又新開發(fā)一個類似軟件組件。長此以往，導致支撐系統(tǒng)越來越龐大，越來越復雜，經(jīng)初步統(tǒng)計，原有CRM系統(tǒng)中僅后臺服務就有10824個。如果把原系統(tǒng)中冗余的軟件組件繼承到第三代CRM系統(tǒng)中，會造成云化架構系統(tǒng)負荷增加，項目建設周期增長，增加后續(xù)云化系統(tǒng)的維護難度，同時增加開發(fā)成本。 問題3：當系統(tǒng)出現(xiàn)故障時，維護人員即使定位出是某個軟件組件問題，但是如何進行修復，需要召集局方和開發(fā)商負責維護、開發(fā)、設計等多名人員進行修復方案和風險的評估，花費大量人力和時間。2.2、面臨的困難二：第三代CRM系統(tǒng)云化架構和模型與原系統(tǒng)發(fā)生根本性變更，而公司要求系統(tǒng)平滑過渡，給項目割接帶來重大挑戰(zhàn)挑戰(zhàn)1：江蘇公司的CRM系統(tǒng)是由華為公司建設，雖然第三代CRM系統(tǒng)的開發(fā)商仍然是華為公司，但是開發(fā)團隊不同，原有的系統(tǒng)是由華為山東團隊建設，第三代CRM系統(tǒng)是由華為南研團隊建設。第三代系統(tǒng)采用全新的開發(fā)框架、J2EE云化架構，數(shù)據(jù)模型也重新構建，本次項目基本上將CRM系統(tǒng)推翻重做。而公司要求本次項目系統(tǒng)割接保持平滑過渡，存在較大難度。挑戰(zhàn)2：第三代CRM系統(tǒng)引入了服務總線（ ESB）、流程引擎（ BPM ）、規(guī)則引擎（ BRM）、分布式服務框架（DSF）、分布式數(shù)據(jù)訪問服務（DDS）、搜素引擎（VSerch）等多項關鍵開源技術，這些新技術的性能、效果如何，與第三代整體架構是否能夠完好地匹配，都要驗證。挑戰(zhàn)3：現(xiàn)有產(chǎn)品達到16000多個，業(yè)務規(guī)則和系統(tǒng)處理邏輯都非常復雜，很多業(yè)務規(guī)則、業(yè)務之間的依賴和沖突關系是在程序代碼中實現(xiàn)，梳理起來很困難，難免出現(xiàn)個別梳理遺漏情況。3. 解決思路和方案3.1、構建軟件組件庫，實現(xiàn)組件服務顯性化管理 江蘇公司利用第三代CRM項目建設的契機，通過功能原子化，形成通用功能組件庫，建設一套軟件組件管理系統(tǒng)，將業(yè)務支撐系統(tǒng)使用的組件、服務、方法、進程等按類別、應用場景等統(tǒng)一納入系統(tǒng)管理，實現(xiàn)了圖形化全景展示。并結(jié)合日常開發(fā)管理辦法，制定一套標準化的管理規(guī)范，實現(xiàn)軟件組件的顯性化管理、核心能力的回收、問題快速定位和風險評估，提高軟件組件的復用度。CRM系統(tǒng)內(nèi)部，軟件組件可復用，降低CRM系統(tǒng)的開發(fā)工作量；對于CRM外部系統(tǒng)，通過軟件組件服務的標準化封裝，提供對外圍的服務能力，同時可支持對外部系統(tǒng)的軟件組件的統(tǒng)一維護，實現(xiàn)公司級的軟件組件統(tǒng)一管理。一期系統(tǒng)已梳理維護組件72個、服務726個、操作3022個，并相應梳理維護了它們之間的關聯(lián)關系，為系統(tǒng)的后續(xù)優(yōu)化和維護打下了基礎。3.1.1、構建軟件組件管理平臺，提升軟件組件的可維護性，實現(xiàn)軟件組件標準化管理。每個組件提供相應的屬性信息管理和維護功能，包含：組件的名稱、入?yún)?、出參、開放渠道、組件類型、能力應用說明、場景實例等。開發(fā)、設計、需求分析和維護人員可以根據(jù)組件名稱查詢組件的詳細信息，可以通過組件查詢歸屬模塊信息。 3.1.2、建立組件、服務、操作等之間的依賴關系，實現(xiàn)軟件組件圖形化展示。實現(xiàn)根據(jù)一個組件、服務或操作，圖形化、地圖化全景展示其涉及的影響信息，讓設計、開發(fā)人員能夠全面評估組件的影響范圍和改造風險，提升開發(fā)效率和開發(fā)質(zhì)量；維護人員能夠快速定位服務故障，快速制定解決方案。在“依賴關系查詢”界面，點擊組件、服務或者操作名稱，可以進入“依賴關系查詢XX明細日志頁面”，顯示詳細的明細日志。也可以查詢到此組件、服務或者操作的上下游關聯(lián)關系。這樣，在日常需求開發(fā)或者故障修復時，我們就可以根據(jù)該組件、服務或者操作的使用場景、關聯(lián)關系，評估、判斷該組件、服務或者操作是否可以復用和修改，修改的影響范圍和風險也可以快速完成評估。3.1.3、建立一套軟件組件管理規(guī)范，提升組件復用度。每次新需求的設計都由評審委員會對使用的軟件組件進行評審，避免重復開發(fā)相同的組件，實現(xiàn)組件和系統(tǒng)的解耦，提升開發(fā)效率，降低成本。經(jīng)梳理和整合，系統(tǒng)后臺服務由老系統(tǒng)的10824個簡化為3748個。 3.2、 引入灰度發(fā)布策略，實現(xiàn)系統(tǒng)分地市、分業(yè)務、分用戶平穩(wěn)割接上線3.2.1、 進行產(chǎn)商品的全面梳理和精簡，完成調(diào)用量較低的接口整合下線 江蘇公司NGCRM系統(tǒng)經(jīng)過5年多的運行，新增了大量的產(chǎn)品和接口，但是由于缺乏生命周期管理，產(chǎn)品和接口只增不減，導致系統(tǒng)中遺留很多無效、冗余的產(chǎn)品和接口。為了對第三代CRM系統(tǒng)瘦身，我省不能把原系統(tǒng)中所有的產(chǎn)品和接口全盤繼承到新系統(tǒng)中，因此，在系統(tǒng)改造割接前，先對系統(tǒng)中的產(chǎn)品和接口進行全面梳理和精簡。（1） 進行產(chǎn)商品的梳理和精簡產(chǎn)商品化涉及到組織、流程、業(yè)務模式的變革與優(yōu)化，組織保障是基礎，模板化是工具和手段。公司安排市場部牽頭，集團客戶部、數(shù)據(jù)部、數(shù)據(jù)業(yè)務運營中心、互聯(lián)網(wǎng)中心、地市公司等多個業(yè)務部門參與，組成業(yè)務產(chǎn)商品梳理小組，開展專題工作。梳理了全省超過16532個產(chǎn)品精簡到8212個，8320個無訂購量的產(chǎn)品在3個月內(nèi)分批下線，業(yè)務小組負責對這些業(yè)務功能進行整合，對訂購量少、效能差的業(yè)務功能進行精簡，對8320個3個月內(nèi)無訂購量的產(chǎn)品分在分批下線，最終精簡到8212個。同時對全省300個營銷活動配置精簡為15個營銷模板。（2） 接口整合下線項目接口小組牽頭，聯(lián)合業(yè)務部門、電子渠道對現(xiàn)網(wǎng)系統(tǒng)的接口進行全面梳理。共計梳理219個平臺，其中一級BOSS 56個，省內(nèi)平臺即增值業(yè)務平臺33個，外圍平臺131個。梳理落地發(fā)接口共8095個，有調(diào)用量3222個，最近半年調(diào)用量為0的4873個。優(yōu)先安排調(diào)用量為0的接口前后4個月分批下線，同時對涉及現(xiàn)網(wǎng)適配改造的1125個接口進行整合改造。3.2.2、 版本灰度發(fā)布，降低系統(tǒng)上線風險為實現(xiàn)關鍵業(yè)務或?qū)ｎ}先小規(guī)模試用，再批量上線，使用zookeeper、nginx構建灰度管理平臺，部署灰度發(fā)布環(huán)境，多維度實現(xiàn)灰度發(fā)布能力（用戶維度、地域維度、營業(yè)員維度）。同時，在管理上成立公司級的項目保障團隊，優(yōu)化割接上線流程，降低割接上線風險。3.2.2.1、總體割接思路（1） 高并發(fā)熱點業(yè)務、安全加固、數(shù)據(jù)分發(fā)中心、共享內(nèi)存、分布式緩存、讀寫分離等不涉及應用架構的專題直接在原系統(tǒng)上改造支撐，實施周期短。（2） 涉及應用架構在新架構中支撐，風險較大，利用系統(tǒng)的灰度發(fā)布能力，采用分業(yè)務/分用戶/分渠道/分地市上線策略。 分業(yè)務：查詢繳費業(yè)務-少量簡單業(yè)務-前臺業(yè)務-后臺管理 分用戶：友好用戶-2-3萬個人用戶-地市全量用戶 分渠道：實體渠道-電渠 分地市：小地市（鎮(zhèn)江）試點-大地市逐步推廣3.2.2.2、 在技術方面，引入灰度發(fā)布策略（1） 灰度發(fā)布方案 支持按用戶灰度發(fā)布灰度發(fā)布規(guī)則配置使用灰度版本的用戶白名單，可以是散號，也可以是號段。例如：灰度用戶號13800000009。電子渠道：那么屬于灰度用戶范圍的用戶路由到灰度環(huán)境。其他用戶路由到非灰度用戶。電子渠道一般是最終用戶發(fā)來的消息，所以建議按用戶灰度在電子渠道上使用。支持按地域灰度灰度地域，指用戶的歸屬地如：南京、蘇州為灰度區(qū)域電子渠道：未輸入號碼之前訪問的是非灰度版本，輸入號碼之后，根據(jù)該用戶號碼查詢其歸屬地信息，如果屬于南京或者蘇州，則發(fā)送到灰度環(huán)境，如果不屬于南京與蘇州，則發(fā)送到非灰度環(huán)境。此處的地域信息與現(xiàn)網(wǎng)數(shù)據(jù)庫保存的用戶歸屬地一致，比如查詢用戶歸屬地查到的是市級名稱，則灰度發(fā)布規(guī)則配置地域信息也要配置成市級名稱。支持按操作員灰度發(fā)布按操作員灰度id：0001，0002營業(yè)廳：營業(yè)員0001or0002登錄后路由到灰度環(huán)境，其他營業(yè)員登錄后則路由到非灰度環(huán)境。營業(yè)員0001or0002辦理的所有用戶均路由到灰度環(huán)境，其他營業(yè)員辦理的用戶則路由到非灰度環(huán)境。營業(yè)廳系統(tǒng)一般營業(yè)廳操作員登錄的時候就需要知道是灰度環(huán)境還是非灰度環(huán)境，建議使用操作員灰度方式在營業(yè)廳場景使用。配置灰度發(fā)布規(guī)則到zookeeper配置中心，該規(guī)則可后臺配置。nginx實時監(jiān)控zookeeper節(jié)點并緩存灰度發(fā)布規(guī)則，解析外部請求發(fā)過來的消息，并轉(zhuǎn)發(fā)到灰度版本webserver或者穩(wěn)定版本的web server 。MQ、DSF、eBus等相關組件遵循優(yōu)先分發(fā)原則，即邏輯Set里的服務調(diào)用和消息訂閱都優(yōu)先分發(fā)給邏輯Set里面的節(jié)點，形成邏輯上的Set切割?；诮K移動本次的項目范圍未包含前端nginx，主要從第三代CRM統(tǒng)一接口框架eBus中完成灰度請求識別及灰度標識的傳遞。在系統(tǒng)割接過程中，電子渠道通過能力開放平臺接入nginx，nginx實時監(jiān)控zookeeper節(jié)點并緩存灰度發(fā)布規(guī)則，根據(jù)發(fā)布規(guī)則判斷是否調(diào)用灰度版本。營業(yè)前臺已割接業(yè)務同樣通過nginx灰度發(fā)布規(guī)則，判斷是否調(diào)用灰度版本。未割接業(yè)務不走灰度版本。（2） 灰度發(fā)布總體流程n 創(chuàng)建灰度發(fā)布規(guī)則灰度發(fā)布規(guī)則即哪些用戶是灰度用戶，灰度發(fā)布規(guī)則創(chuàng)建時包括規(guī)則編號、關鍵字、規(guī)則名稱、規(guī)則對應的值。如下圖所示，點擊創(chuàng)建按鈕即可開始創(chuàng)建規(guī)則，并給出該規(guī)則所對應的值。如：whitelis13800000009n 創(chuàng)建灰度發(fā)布任務灰度發(fā)布任務代表了本次灰度升級，本次灰度發(fā)布任務包含哪些規(guī)則，一個灰度發(fā)布任務可以有多個灰度發(fā)布規(guī)則，灰度過程中，規(guī)則可根據(jù)具體情況進行修改。n 灰度環(huán)境部署對灰度任務中選中的灰度節(jié)點進行升級。n 業(yè)務流程驗證灰度發(fā)布過程中以及所有節(jié)點都灰度升級后均需要驗證相關業(yè)務是否正常處理。3.2.2.3、 在管理方面，省市聯(lián)動，優(yōu)化割接上線流程由于第三代CRM系統(tǒng)采用全新的技術架構、引入多個新的技術組件，同時數(shù)據(jù)模型也發(fā)生了變更，為了保證系統(tǒng)平滑過渡，我省在制定割接方案時，由公司領導掛帥，協(xié)調(diào)業(yè)務部門和地市公司充分參與，進行UAT測試、并行測試用例的制定和評審，并組織驗收測試，并對上線流程進行了優(yōu)化。（1） 項目組織保障：公司領導掛帥，成立跨部門、跨地市兩級項目組 u 成立公司副總經(jīng)理掛帥的重大聯(lián)合項目組（包括信息技術中心、規(guī)劃部、市場部、品管部、采購部、工程部、客服中心、集客部、數(shù)據(jù)部、財務部、各地市公司等部門），保障各部門的人力投入，共同推進第三代業(yè)務支撐系統(tǒng)建設。 u 第三代業(yè)務支撐系統(tǒng)的建設不僅僅是技術平臺的升級，同時涉及業(yè)務流程與產(chǎn)品的梳理、優(yōu)化、業(yè)務測試與驗證，因此業(yè)務部門的充分參與是保障項目成功的重要基礎。u 項目團隊建立多級溝通和預警機制，包括項目級別的會議制度、各執(zhí)行組的會議制度，并明確了不同類別的項目匯報形式。同時制定了項目組織普通預警、中度預警和緊急預警的三級預警機制，明確了風險預警通報標準、問題上升的流程，以及預警問題溝通會制度。（2） 測試環(huán)節(jié)引入UAT測試和并行測試為提高測試可靠性，江蘇公司采用預備上線的應用部署主機和容災數(shù)據(jù)庫構建并行環(huán)境，針對前臺受理業(yè)務，參與并行測試的營業(yè)廳通過撈取前一日生產(chǎn)業(yè)務受理流水，進行業(yè)務回歸并與生產(chǎn)庫比較并行測試結(jié)果；針對電子渠道采用測試號碼驗證，通過灰度管理平臺的白名單路由機制在并行環(huán)境完成測試號碼業(yè)務受理。組織市場部、集團客戶部、客戶服務中心等業(yè)務部門和地市公司營業(yè)員進行UAT客戶驗收測試，所有UAT測試用例都由業(yè)務部門和營業(yè)員編寫或評審。（3） 割接流程優(yōu)化，降低割接風險以往的CRM系統(tǒng)項目割接上線，一般采用開發(fā)版本研發(fā)測試后，版本發(fā)布到江蘇移動現(xiàn)場測試環(huán)境測試，測試通過后，版本發(fā)布到生產(chǎn)環(huán)境面向某個地市或者全省開放，同時進行數(shù)據(jù)割接。這樣存在較大的風險，沒有經(jīng)過生產(chǎn)環(huán)境的實際體驗和驗證，系統(tǒng)割接上線后存在問題的概率較大；一旦上線后發(fā)現(xiàn)系統(tǒng)BUG或者割接數(shù)據(jù)存在問題，影響面較廣。本次項目割接對原有的流程進行了優(yōu)化：（1） 在原有的流程基礎上，增加了并行環(huán)境灰度測試階段，版本發(fā)布到并行環(huán)境，由開發(fā)商、第三方測試人員針對測試號碼進行測試驗證。（2） 增加生產(chǎn)環(huán)境灰度體驗階段，在并行環(huán)境測試通過率達標后，版本發(fā)布到生產(chǎn)環(huán)境，割接部分真實的友好客戶到生產(chǎn)系統(tǒng)，利用灰度策略，面向部分工號開放權限，由開發(fā)商、第三方測試團隊、地市公司營業(yè)員共同進行驗證測試。（3） 生產(chǎn)環(huán)境灰度體驗通過后，再進行全量用戶數(shù)據(jù)的割接，面向某個地市或全省營業(yè)員開放權限。4. 實施效果4.1、 軟件組件庫建設后，問題定位、方案、風險評估效率大幅提升（1） 江蘇移動業(yè)務支撐技術人員可以實時掌握業(yè)務支撐系統(tǒng)的核心技術信息，部門的需求、設計、開發(fā)、維護人員提升掌控CRM支撐系統(tǒng)核心能力水平，局方自有人員獨立定位故障、評估風險的問題占比由10%提升到50%。（2） CRM業(yè)務支撐新需求的軟件組件復用率由20%提升到33%。（3） 開發(fā)工作量評審有依據(jù)，總體工作量局方評審有效核減率由9%提升到11%。（4） 問題定位時間由原來的平均30分鐘以上提升到10分鐘以內(nèi)，風險評估平均時間由原來的6小時，提升到目前30分鐘。4.2、 引入灰度發(fā)布技術后，實現(xiàn)系統(tǒng)平滑過渡（1） 系統(tǒng)割接平穩(wěn)，未引起地市波動，大面積故障率為0。分業(yè)務功能上線，大系統(tǒng)小做，降低項目改造和割接規(guī)模，降低項目改造和割接風險。目前已完成高并發(fā)熱點業(yè)務、安全加固、數(shù)據(jù)分發(fā)中心、共享內(nèi)存、分布式緩存、讀寫分離等6個不涉及應用架構的專題割接上線；完成查詢繳費云化全省割接上線，完成CRM交易中心、新系統(tǒng)框架3個版本在鎮(zhèn)江割接上線，上線過程和上線后，共計收到灰度用戶反饋的問題單142個，發(fā)生1次系統(tǒng)性能的嚴重問題。由于采用灰度發(fā)布策略，及時進行了修復，未引起批量投訴和系統(tǒng)預警。專題灰度用戶反饋問題單數(shù)量嚴重問題高并發(fā)熱點業(yè)務3無安全加固12無數(shù)據(jù)分發(fā)中心8無共享內(nèi)存0無分布式緩存28發(fā)現(xiàn)1個嚴重性能問題，系統(tǒng)上線后，系統(tǒng)性能不僅未提升，反而大幅下降，經(jīng)核查主要是Conherence參數(shù)設置錯誤，經(jīng)調(diào)優(yōu)后恢復正常。讀寫分離0級2無查詢繳費云化24無交易中心第一版本8無交易中心第二版本26無交易中心第三版本31無總計1421（2） 共計10個專題上線，未暫停前臺一次。相比較5年前鎮(zhèn)江NGBOSS割接，營業(yè)前臺暫停2天業(yè)務，本次割接上線基本未給公司造成任何波動。4.3、 產(chǎn)品、接口梳理和精簡，提升業(yè)務發(fā)布效率（1） 全省超過16532個產(chǎn)品精簡到8212個，8320個無訂購量的產(chǎn)品分在3個月內(nèi)分批下線。（2） 落地發(fā)接口由8095個精簡到3222個，完成4873個0調(diào)用量的接口下線。5. 后續(xù)思考5.1、 拓展軟件組件服務管理系統(tǒng)功能，提升系統(tǒng)透明管理能力在現(xiàn)有軟件組件服務管