前言隨著大數(shù)據(jù)和云計算的飛速發(fā)展，單體式應(yīng)用越來越不合用于復(fù)雜的業(yè)務(wù)需求。微服務(wù)架構(gòu)的出現(xiàn)則將規(guī)模龐大的應(yīng)用分解為小的、互相連接的服務(wù)，成功地解決了單體應(yīng)用所存在的問題。另外，由微服務(wù)構(gòu)成的服務(wù)集群在傳統(tǒng)虛擬機或物理機方式下搭建環(huán)節(jié)繁多，搭建邏輯復(fù)雜，集群的安裝和布署都有一定的局限性，如配備文獻之多、配備節(jié)點數(shù)量之大，布署過程涉及計算機網(wǎng)絡(luò)、Ｌｉｎｕｘ操作系統(tǒng)、ＳＳＨ無密碼登錄、ｊｄｋ環(huán)境配置、Ｓｈｅｌｌ腳本等一系列紛繁復(fù)雜的操作，動輒分布式集群的布署以失敗告終，且無從下手找出故障本源，這就在一定程度上拖慢了開發(fā)進度。而隨著大數(shù)據(jù)與云計算的飛速發(fā)展，服務(wù)集群的需求度也明顯上升，如何快速搭建服務(wù)集群也成了業(yè)內(nèi)人士研究的重點。微服務(wù)管控平臺3.1微服務(wù)管控平臺網(wǎng)管微服務(wù)管控平臺重要實現(xiàn)微服務(wù)布署、API開放的管控，通過集中配備、集中日志、集中監(jiān)控實現(xiàn)對微服務(wù)的運維支撐。提供多租戶管理機制，允許租戶申請自己空間、進行微服務(wù)布署、服務(wù)API開放以及對空間、API調(diào)用的管控機制。下圖介紹了微服務(wù)管控平臺總體架構(gòu)。平臺架構(gòu)包含3個部分：API開放管控、微服務(wù)調(diào)度和公共服務(wù)。（1）API開放管控：通過注冊中心和API網(wǎng)關(guān)實現(xiàn)服務(wù)發(fā)現(xiàn)和開放管控。（2）微服務(wù)調(diào)度：通過混合資源調(diào)度實現(xiàn)微服務(wù)布署、升級和擴容等管理。（3）公共服務(wù)：涉及管理門戶、運維監(jiān)控、集中配備以及安全中心。微服務(wù)管控平臺選用SpringCoudl架構(gòu)，其中注冊中心和配備中心選擇Consul，API網(wǎng)關(guān)為Zuul，客戶端框架為Ribbon，服務(wù)容錯為Hystrix。集中日志選擇ELK(ElasticsearchLogstashKibana)。各模塊間調(diào)用關(guān)系以下圖所示。3.2微服務(wù)運行微服務(wù)開發(fā)完成后，根據(jù)微服務(wù)開發(fā)語言選擇一種適宜的Docker鏡像，鏡像中包含微服務(wù)運行環(huán)境。通過Docker命令把微服務(wù)打包稱為Docker鏡像，再通過Kubernetes(K8S)對Docker鏡像進行布署運行。3.3微服務(wù)梳理通過對目的業(yè)務(wù)系統(tǒng)進行微服務(wù)梳理，現(xiàn)在該系統(tǒng)從業(yè)務(wù)功效上分為管理中心模塊、運行管理模塊、集成開發(fā)模塊、數(shù)據(jù)質(zhì)量監(jiān)控模塊、系統(tǒng)自監(jiān)控、元數(shù)據(jù)管理、執(zhí)行控制以及執(zhí)行容器模塊等。首先每個模塊進行容器化布署，平臺本身的管理中心模塊含有上傳其它功效模塊的功效，待上傳成功后自動實現(xiàn)解壓、安裝、布署、啟動和管理，同時提供原則化的開放管理接口，以實現(xiàn)對擴展功效模塊的管理功效。每一種執(zhí)行容器按采集網(wǎng)元類型進行劃分，其中單個網(wǎng)元類型執(zhí)行容器微服務(wù)接受平臺下發(fā)的執(zhí)行命令，獲取預(yù)先編排好的流程執(zhí)行，執(zhí)行完畢后返回告知服務(wù)，該服務(wù)含有微服務(wù)單一職責，獨立布署等特點。業(yè)務(wù)系統(tǒng)的功效框架以下圖所示。微服務(wù)梳理是各系統(tǒng)微服務(wù)化改造的核心點，通過這個項目我們總結(jié)了Matrix辦法論，對業(yè)務(wù)流程、功效服務(wù)和數(shù)據(jù)信息3個層面并行梳理分析，通過這個辦法論能夠快速、精確梳理出微服務(wù)，通過對網(wǎng)管系統(tǒng)微服務(wù)的梳理，抽取出公共微服務(wù)，實現(xiàn)服務(wù)共享，形成公共服務(wù)層。3.4微服務(wù)編排3.4.1流程畫布與元件功效微服務(wù)編排涉及流程畫布和執(zhí)行元件等功效模塊。流程畫布含有增加目錄、增加元任務(wù)、保存、編輯元任務(wù)、刪除任務(wù)、復(fù)制活動、粘貼活動、查看、元任務(wù)復(fù)制等功效，以下圖所示。作為一種常見的微服務(wù)編排業(yè)務(wù)流程：首先通過HttpMicroServiceHttp-1、HttpMicroServiceHttp-2元件獲取數(shù)據(jù)后，發(fā)給Join-1元件。Join-1元件根據(jù)核心字進行Join運算后將數(shù)據(jù)發(fā)送給Join-2元件。HttpMicroServiceHttp-3元件獲取數(shù)據(jù)發(fā)給JsonTrans元件進行格式轉(zhuǎn)化發(fā)給Join-2元件。Join-2元件根據(jù)關(guān)鍵字進行Join運算后發(fā)送給Join-3元件。HttpMicroServiceHttp-4元件獲取數(shù)據(jù)發(fā)送給Join-3元件。Join-3元件獲取HttpMicroServiceHttp-4和Join-2數(shù)據(jù)后，根據(jù)核心字進行Join運算后數(shù)據(jù)給服務(wù)調(diào)用方。元件功效（1）流程首節(jié)點：此元件標記流程開始，在設(shè)計流程圖中如果存在多個首節(jié)點，以編號最小的默認為首節(jié)點，如圖所示。（2）微服務(wù)節(jié)點：通過該元件能夠連接微服務(wù)，發(fā)送指令獲取返回報文，下列是指令平臺服務(wù)調(diào)用為例闡明元件參數(shù)及配備。（3）自定義解析節(jié)點：此元件完畢對上一種元件（指向本元件的來源節(jié)點）所生成報文解析操作。（4）消息合并元件：此元件用于將多個來源元件輸出的文獻合并為一種返回消息的操作。3.4.2流程微服務(wù)化通過畫布與元件實現(xiàn)了業(yè)務(wù)場景流程的組合編排，如何讓編排的流程構(gòu)成微服務(wù)呢？這就要借助微服務(wù)管控平臺。微服務(wù)模版首先設(shè)計一種微服務(wù)模版，模版包含服務(wù)注冊、服務(wù)配備和服務(wù)心跳這些微服務(wù)的基本能力。（1）服務(wù)注冊：通過服務(wù)自動注冊、發(fā)現(xiàn)，實現(xiàn)服務(wù)動態(tài)自動發(fā)現(xiàn)和接入，減少手工維護工作量，避免手工維護和微服務(wù)實際狀況不一致。（2）服務(wù)配備：可覺得每個微服務(wù)定制集中配備參數(shù),方便微服務(wù)運行期動態(tài)調(diào)節(jié)。（3）服務(wù)心跳：被監(jiān)控的元件定時發(fā)送心跳信息給監(jiān)控進程（或者由監(jiān)控進程輪詢被監(jiān)控元件），如果一定時間間隔內(nèi)收不到心跳信息就被認為失效了。微服務(wù)生成編排好的流程引擎打包在一起，生成一種流程程序，微服務(wù)的注入過程和生成過程以下圖所示。微服務(wù)化從Docker注冊的公共鏡像倉庫下載一種鏡像，不同的操作系統(tǒng)安裝Docker鏡像會有些許不同，新版的Redhat和Centos7自帶有Docker包，直接安裝即可。然后從該鏡像中創(chuàng)立一種容器，啟動后即可配備運行自己的微服務(wù)，同時也能夠根據(jù)需求對Docker鏡像進行修改。例如創(chuàng)立Docker顧客組，調(diào)節(jié)內(nèi)存和交換空間，啟用防火墻的端口轉(zhuǎn)發(fā)和為Docker配備DNS服務(wù)。編寫安裝JDK的Dockerfile，安裝語言包，設(shè)立微服務(wù)環(huán)境變量，設(shè)立語言環(huán)境變量，運行命令DockerBuild-t定義名稱及途徑，即可生成一種容器鏡像，然后通過命令啟動微服務(wù)。3.4.3執(zhí)行跟蹤隨著微服務(wù)設(shè)計理念在系統(tǒng)中的應(yīng)用，業(yè)務(wù)的調(diào)用鏈越來越復(fù)雜，一種請求可能會涉及到幾十個服務(wù)的協(xié)同操作，需要進行跟蹤分析。通過調(diào)用鏈，把一次請求調(diào)用過程完整的串聯(lián)起來，實現(xiàn)了對請求調(diào)用途徑的監(jiān)控，便于故障快速定位。如各個調(diào)用環(huán)節(jié)的性能分析（如各個API使用時間和使用堆棧狀況）、還原調(diào)用鏈各個環(huán)節(jié)依賴關(guān)系、SQL語句打印、IP顯示等。整個跟蹤過程需要關(guān)注兩個ID，首先微服務(wù)收到請求后生成一種全局TraceID，通過TraceID能夠串聯(lián)起整個調(diào)用鏈，一種TraceID代表一次請求。除了TraceID外，還需要SpanID用于統(tǒng)計調(diào)用父子關(guān)系，每個元件會統(tǒng)計下SpanID，通過他們能夠組織一次完整調(diào)用鏈的父子關(guān)系。通過跟蹤實時關(guān)注各個調(diào)用的性能指標，根據(jù)TraceID能夠查出全部調(diào)用統(tǒng)計，通過SpanID能夠組織起整個調(diào)用父子關(guān)系，實現(xiàn)問題跟蹤，例如響應(yīng)時間和錯誤統(tǒng)計等。3.4.4微服務(wù)的監(jiān)控支持按照閾值進行微服務(wù)監(jiān)控配備，例如觸發(fā)訪問次數(shù)閾值、去除訪問次數(shù)閾值、觸發(fā)訪問失敗率告警閾值、去除訪問失敗率告警閾值、觸發(fā)時延告警閾值、去除時延告警閾值等。設(shè)立完畢后，系統(tǒng)自動讀取服務(wù)告警閾值信息，基于判斷及時觸發(fā)告警，微服務(wù)有關(guān)的告警涉及告警正文、告警時間、活動狀態(tài)等告警信息。電信運行商組件化和微服務(wù)化與現(xiàn)有多數(shù)網(wǎng)元功效復(fù)雜不同，功效組件是將電信網(wǎng)絡(luò)以功效為單位進行分解，每個功效組件往往對應(yīng)一種相對單一的功效，且互相間的耦合度也比較低。這樣每個功效組件的開發(fā)比較簡樸且能夠“微服務(wù)”的方式獨立加載/升級。但由于一種組件/微服務(wù)所實現(xiàn)的功效普通比較小且單一，無法獨立對外提供較大的電信服務(wù)，這就需要將有關(guān)組件/微服務(wù)按照一定的關(guān)聯(lián)關(guān)系進行組合以對外提供一種完整的電信服務(wù)，該過程稱之為服務(wù)編排。由于不同客戶和應(yīng)用場景所需的組件可能不同，我們能夠進行針對性的服務(wù)編排，為不同客戶和場景構(gòu)建不同的編排實例，每個編排實例稱之為一種網(wǎng)絡(luò)切片。組件被開發(fā)出來后通過組件倉庫的方式進行統(tǒng)一管理，當需要使用某些組件構(gòu)建服務(wù)時，由服務(wù)生命周期管理系統(tǒng)以服務(wù)切片模板方式進行組件的組織并完畢實例化。為不同的顧客/應(yīng)用場景構(gòu)建的網(wǎng)絡(luò)服務(wù)形成系統(tǒng)中一種個服務(wù)切片，由系統(tǒng)根據(jù)接入顧客的特性進行靈活地服務(wù)切片選擇。由于服務(wù)切片中的組件都是一種個獨立的“微服務(wù)”，因此能夠?qū)ζ溥M行獨立升級和縮擴容而對其它功效組件沒有影響。組件化和微服務(wù)的引入徹底打破了電信網(wǎng)絡(luò)僵化的現(xiàn)狀，不僅能夠提高網(wǎng)絡(luò)的強健性，加速新業(yè)務(wù)開發(fā)與布署，同時還提供了更靈活商業(yè)模式創(chuàng)新。但組件化和微服務(wù)同時也造成了電信功效的“顆粒化“，對管理規(guī)定大大提高，這就需要一套更強大的管理和支撐體系作為保障。支撐體系由服務(wù)開發(fā)框架、集成框架和運行框架幾部分構(gòu)成，開發(fā)框架提供了支持多個不同技術(shù)和開發(fā)語言的開發(fā)和測試環(huán)境，集成框架能夠提供完善的電信級組件服務(wù)倉庫和服務(wù)集成機制，方便多個不同形式的服務(wù)集成能力。而運行框架則實現(xiàn)了網(wǎng)絡(luò)服務(wù)全生命周期的管理，并提供對不同虛擬化資源技術(shù)的適配。同時，該支撐體系能夠通過強大的portal實現(xiàn)與廣大應(yīng)用開發(fā)者和客戶的互動，使整個體系成為一種全方位開放的系統(tǒng)。通過該支撐體系，電信服務(wù)的開發(fā)、布署、管理和開放都變得異常輕松，運行商也能夠像OTT們同樣，構(gòu)建生態(tài)圈，快速創(chuàng)新，持續(xù)發(fā)展。微服務(wù)的服務(wù)編排在微服務(wù)架構(gòu)下，服務(wù)會拆分成諸多新的微服務(wù)，原有的業(yè)務(wù)將借助服務(wù)編排工具，方便地實現(xiàn)微服務(wù)之間的協(xié)作，進而快速、靈活組裝成各類業(yè)務(wù)場景。采用基于微服務(wù)架構(gòu)的服務(wù)編排技術(shù)，能有效提高軟件模塊的復(fù)用度，減少應(yīng)用實現(xiàn)復(fù)雜度，打造多廠家協(xié)同的開放生態(tài)，實現(xiàn)從業(yè)務(wù)場景編碼到業(yè)務(wù)場景編排的提高。在開發(fā)業(yè)務(wù)場景時，單個服務(wù)往往無法完畢全部需求，必須依靠一組服務(wù)互相之間的協(xié)作才干達成目的。通過服務(wù)編排能夠?qū)⒍鄠€分布、獨立、自治的微服務(wù)根據(jù)業(yè)務(wù)語義及邏輯關(guān)系進行靈活集成，通過實現(xiàn)各服務(wù)之間的協(xié)作，進而構(gòu)成一種完整的業(yè)務(wù)流程/業(yè)務(wù)場景。因此，服務(wù)編排是實現(xiàn)復(fù)雜系統(tǒng)場景實現(xiàn)的重要技術(shù)手段。服務(wù)編排通過可視化的界面直觀地編輯和展示流程，不需要修改程序就能夠根據(jù)需求動態(tài)變化流程，提供了服務(wù)化下動態(tài)變化流程的條件。正是有了現(xiàn)在微服務(wù)的概念以及對功效進行服務(wù)化改造，才使得原有的靜態(tài)功效編排，提高到了動態(tài)的服務(wù)編排，使得業(yè)務(wù)人員能夠根據(jù)業(yè)務(wù)需要靈活動態(tài)地編排服務(wù)，滿足業(yè)務(wù)多樣性的需要。服務(wù)編排流程服務(wù)編排通過和諧的編排界面，根據(jù)業(yè)務(wù)場景對基本功效服務(wù)進行組合，形成一種可執(zhí)行的業(yè)務(wù)流程，協(xié)同各有關(guān)服務(wù)功效的交互，最后完畢顧客定義的業(yè)務(wù)場景。服務(wù)編排涉及編排(choreography)和編制(orchestration)2個部分。編排是以合同的形式從全局視角定義組員服務(wù)之間必須恪守的通信契約和交互行為。編制則是從組合服務(wù)的視角描述服務(wù)內(nèi)部的業(yè)務(wù)流程及其執(zhí)行細節(jié)。編排形成的是服務(wù)之間的拓撲關(guān)系，不含有可執(zhí)行性，因此需要轉(zhuǎn)變?yōu)橐子趫?zhí)行的編制模型。服務(wù)編排的總體架構(gòu)以下圖所示，涉及編排過程、編譯過程和執(zhí)行過程。1)在編排過程中，服務(wù)編排界面從服務(wù)注冊中心獲取服務(wù)描述，應(yīng)用開發(fā)人員使用服務(wù)編排界面，將已有服務(wù)按照業(yè)務(wù)的功效流程進行組合，形成格式化的編排流程文獻。2)在映射過程中，映射程序通過映射規(guī)則將描述服務(wù)拓撲關(guān)系的編排流程文獻通過流程編譯，形成描述組合服務(wù)內(nèi)部服務(wù)調(diào)用過程的編制執(zhí)行文獻。3)在執(zhí)行過程中，編制執(zhí)行引擎加載編制執(zhí)行文獻形成組合服務(wù)，組合服務(wù)消費者調(diào)用組合服務(wù)，編制執(zhí)行引擎將根據(jù)編制執(zhí)行文獻中定義的流程，進行流程執(zhí)行和組件調(diào)用，最后將執(zhí)行成果返回給組合服務(wù)消費者。服務(wù)編排后，其形態(tài)是一種組合服務(wù)，集成后形成的組合服務(wù)有完整的服務(wù)接口和服務(wù)描述文獻，在服務(wù)注冊和使用時和基本服務(wù)沒有區(qū)別，區(qū)別僅在于這個組合服務(wù)是通過服務(wù)編排來實現(xiàn)出來的，而不需要通過程序開發(fā)代碼編碼的方式來實現(xiàn)。服務(wù)編排的輸入是已注冊到服務(wù)管理中心中的服務(wù)，這些已注冊的服務(wù)經(jīng)由應(yīng)用開發(fā)人員進行編排組合后，產(chǎn)生一種新的組合服務(wù)，并將該服務(wù)注冊到服務(wù)管理中心。編排后的服務(wù)和普通服務(wù)同樣，能夠編排進其它服務(wù)中。服務(wù)編排核心技術(shù)2服務(wù)編排核心技術(shù)2．1服務(wù)描述調(diào)度控制系統(tǒng)不同于互聯(lián)網(wǎng)系統(tǒng)，開放性及原則化程度相對較低，因此在新一代調(diào)控系統(tǒng)設(shè)計時就規(guī)定“原則統(tǒng)一、繼承開放”。新一代調(diào)控系統(tǒng)通過Protobuf規(guī)范服務(wù)接口參數(shù)格式，通過服務(wù)總線統(tǒng)一通信方式，通過服務(wù)管理規(guī)范服務(wù)注冊流程。服務(wù)編排中服務(wù)是核心對象，其構(gòu)造內(nèi)容在服務(wù)編排的每個環(huán)節(jié)都會使用，關(guān)系到服務(wù)編排的編排力度和后續(xù)的功效實現(xiàn)。例如在服務(wù)描述中包含服務(wù)啟動命令，則在服務(wù)執(zhí)行時該服務(wù)尚未啟動，服務(wù)編制執(zhí)行引擎能夠通過任務(wù)調(diào)度功效自動啟動服務(wù)，完畢服務(wù)編排的執(zhí)行流程。在服務(wù)編排中需要規(guī)范服務(wù)描述，從服務(wù)管理中獲取服務(wù)有關(guān)信息。對于服務(wù)參數(shù)的表達是服務(wù)描述的核心內(nèi)容。在服務(wù)編排的過程中，上一種服務(wù)的輸出往往不能完全匹配下一種服務(wù)的輸入，可能需要從之前的多個服務(wù)輸出中拆分出有關(guān)內(nèi)容，再進行重新合并，才干形成新服務(wù)的輸入數(shù)據(jù)，而拆分的最小構(gòu)造就是參數(shù)。因此服務(wù)描述中需要對服務(wù)的參數(shù)名稱、類型和屬性進行具體定義。現(xiàn)有的簡樸服務(wù)接口規(guī)范已對基本的服務(wù)信息進行了描述，但是缺少服務(wù)參數(shù)、服務(wù)啟動命令等服務(wù)編排所需要的核心信息。因此服務(wù)編排的服務(wù)描述將在簡樸服務(wù)接口規(guī)范的基礎(chǔ)上，采用XML格式補充參數(shù)、啟動命令、場景等信息的描述，并形成編制規(guī)范。服務(wù)描述的具體格式為：〈Service(type1:param1，type2:param2，…)prompt/〉〈param1modetype1/〉〈!--參數(shù)1--〉〈param2modetype2/〉〈!--參數(shù)2--〉…〈cmdvalue/〉〈!--命令--〉〈scenariovalue/〉〈!--場景--〉其中第1行為服務(wù)定義的描述，與簡樸服務(wù)接口的服務(wù)定義格式一致，Service，type和param分別表達服務(wù)名、參數(shù)類型和參數(shù)名，用英文標記，prompt為提示符，是對服務(wù)功效的闡明，能夠使用中文進行描述。從第2行開始為參數(shù)列表，是對參數(shù)的補充闡明，mode可覺得in，out或in/out，分別表達輸入?yún)?shù)、輸出參數(shù)或輸入輸出參數(shù)。最后的cmd和scenario標簽定義了服務(wù)的啟動命令和場景信息。2．2流程編譯技術(shù)流程編譯技術(shù)與程序的編譯類似，都是將高級語言變成計算機能夠識別的二進制語言。流程編譯中的高級語言是基于可視化圖形產(chǎn)生的描述服務(wù)執(zhí)行流程的編排流程文獻，轉(zhuǎn)化成的二進制語言為程序可理解執(zhí)行的編制執(zhí)行文獻。通過顧客操作圖形界面形成的編排流程文獻描述了業(yè)務(wù)流程中參數(shù)、組件，以及它們之間的對應(yīng)關(guān)系，但是編排流程文獻還不能直接執(zhí)行，需要編譯成可高效動態(tài)解析的描述內(nèi)部組件調(diào)用關(guān)系的編制執(zhí)行文獻，供編制執(zhí)行引擎使用。流程編譯如圖3所示，包含詞法分析、語法分析、檢查優(yōu)化和流程映射4個過程。詞法分析從圖形產(chǎn)生的編排流程文獻中識別出各個基本單元，如參數(shù)、組件以及參數(shù)和組件之間的對應(yīng)關(guān)系。語法分析在詞法分析的基礎(chǔ)上進一步進行語義層面的解析，擬定各個組件的輸入?yún)?shù)和輸出參數(shù)，獲取組件之間的調(diào)用關(guān)系以及在每一次調(diào)用中組件的輸入?yún)?shù)所對應(yīng)的其它組件的輸出參數(shù)。檢查優(yōu)化過程用于確保流程的對的和高效，需要檢查參數(shù)類型，確保組件調(diào)用時客戶端和服務(wù)端對應(yīng)的參數(shù)類型匹配;檢查服務(wù)流程，確保流程不存在死循環(huán)和孤島，含有最后輸出;優(yōu)化并發(fā)過程，根據(jù)各個組件的輸入?yún)?shù)值可獲取的先后次序，將同一時間可獲取全部輸入?yún)?shù)值(即可調(diào)用)的組件進行并發(fā)執(zhí)行。詞法分析、語法分析和檢查優(yōu)化過程后形成一種保存在內(nèi)存中的流程編譯的中間構(gòu)造，該構(gòu)造按照編制執(zhí)行模板的規(guī)范規(guī)定統(tǒng)計參數(shù)、組件和互有關(guān)系。根據(jù)編制執(zhí)行文獻高效動態(tài)解析的需求，采用支持運行時高效動態(tài)解析的Protobuf編碼格式作為編制執(zhí)行文獻的模板格式，這樣映射過程就轉(zhuǎn)變?yōu)榘凑站幹茍?zhí)行模板進行動態(tài)編碼的過程，編制執(zhí)行引擎加載編制執(zhí)行文獻后解析的過程，就轉(zhuǎn)變?yōu)榘凑站幹茍?zhí)行模板進行動態(tài)解碼的過程。2．3流程執(zhí)行技術(shù)流程執(zhí)行技術(shù)提供解決對多個編排流程的表達和解決的辦法。其核心是解決串行、并行、分支和循環(huán)等多個流程的表達和執(zhí)行方式，以及嵌套流程的解決過程。一種基本的串行流程由一組組件及其對應(yīng)參數(shù)構(gòu)成，編制執(zhí)行引擎次序執(zhí)行每個組件，直到最后一種組件解決完畢。并行流程與串行流程類似，只是流程內(nèi)的各個組件采用多線程方式同時執(zhí)行。分支和循環(huán)流程由前置組件、判斷參數(shù)和后續(xù)流程構(gòu)成，前置組件是在進行條件或循環(huán)判斷時需要預(yù)先執(zhí)行的組件，普通用于產(chǎn)生條件判斷的參數(shù)值;判斷參數(shù)用于決定與否進入分支或循環(huán);后續(xù)流程是分支或循環(huán)真正的執(zhí)行內(nèi)容。串行、并行、分支和循環(huán)之間支持互相嵌套使用，流程中的組件能夠替代成另一種流程，實現(xiàn)流程嵌套。2．4組件調(diào)用技術(shù)服務(wù)編排重要是解決服務(wù)調(diào)用，但是為了提高組合服務(wù)的執(zhí)行效率，還需要提供基于函數(shù)和動態(tài)庫方式的調(diào)用形式。服務(wù)、函數(shù)和動態(tài)庫在服務(wù)編排中通稱為組件，是服務(wù)編排中一種最小的執(zhí)行單元，根據(jù)執(zhí)行效率從高到低，分為函數(shù)組件、動態(tài)庫組件和服務(wù)組件。函數(shù)組件是集成在服務(wù)編排系統(tǒng)中的簡樸的函數(shù)調(diào)用，即使運行速度最快，但只能實現(xiàn)固定的幾個最基本的功效，如取最大值、最小值等;動態(tài)庫組件是通過動態(tài)庫接口調(diào)用的方式實現(xiàn)業(yè)務(wù)邏輯的模塊，運行時需要加載額外的動態(tài)庫性能中檔，同時限制了運行的功效只能和組合服務(wù)在一臺機器上;服務(wù)組件為以服務(wù)的方式提供功效的模塊，涉及網(wǎng)絡(luò)通信性能相對前2種較低，但限制也最少，功效執(zhí)行能夠和組合服務(wù)在不同的機器上。組件的執(zhí)行分成2個部分:一是對組件的輸入輸出參數(shù)進行編解碼，二是根據(jù)組件類型調(diào)用組件。服務(wù)編排過程中的編解碼有2個部分:一是組合服務(wù)本身輸入、輸出參數(shù)的編解碼，二是組合服務(wù)內(nèi)部各個組員函數(shù)輸入、輸出參數(shù)的編解碼。基于Protobuf的動態(tài)解析特性，編制執(zhí)行引擎使用Protobuf進行編解碼，同時也支持M語言編碼。在編制執(zhí)行引擎接受到數(shù)據(jù)之后，通過獲取類型文獻，根據(jù)Protobuf的反射功效，自動創(chuàng)立具體類型的反射對象，完畢編解碼功效。解碼后產(chǎn)生一種或多個參數(shù)值，這些參數(shù)值被保存在內(nèi)存中對應(yīng)參數(shù)位置，供后續(xù)組件使用。組件執(zhí)行時會選擇需要的參數(shù)，獲取參數(shù)值，函數(shù)和動態(tài)庫組件直接使用，服務(wù)組件需要將多個參數(shù)重新編碼后再使用。編制執(zhí)行引擎根據(jù)組件的類型采用不同的執(zhí)行辦法。對于函數(shù)組件，編制執(zhí)行引擎直接調(diào)用對應(yīng)的函數(shù)接口;對于動態(tài)庫組件，編制執(zhí)行引擎將根據(jù)動態(tài)庫名稱打開該動態(tài)庫，并把它裝入內(nèi)存，然后根據(jù)函數(shù)名稱查找函數(shù)在內(nèi)存中的地址，最后調(diào)用動態(tài)庫中的對應(yīng)函數(shù);對于服務(wù)組件，編制執(zhí)行引擎首先根據(jù)場景、子場景等信息定位服務(wù)位置，然后通過服務(wù)總線調(diào)用對應(yīng)的服務(wù)，最后獲取服務(wù)返回成果進行解碼，完畢組件執(zhí)行過程。其它服務(wù)編排方略和規(guī)范現(xiàn)在服務(wù)編排的方略重要分為基于工作流的服務(wù)編排方略、基于構(gòu)件的服務(wù)編排方略和基于人工智能（ArtificialIntelligence，AI）的服務(wù)編排方略三類。其中，基于構(gòu)件的服務(wù)編排方略是通過對服務(wù)構(gòu)件進行定義來提供服務(wù)編排的內(nèi)部實現(xiàn)腳本。在基于構(gòu)件的服務(wù)編排方略中，服務(wù)流模型定義了服務(wù)構(gòu)件行為，因此修改服務(wù)流時意味著要對每個構(gòu)件的設(shè)計進行變更。考慮到綜合資源管理的資源范疇和能力，可采用基于構(gòu)件的服務(wù)編排方略進行重構(gòu)，將面對業(yè)務(wù)的服務(wù)接口按照資源管理最小粒度進行重新編排，并根據(jù)服務(wù)建模的元數(shù)據(jù)來動態(tài)生成輕量化和可復(fù)用的服務(wù)組件。微服務(wù)規(guī)范化為確保規(guī)范性，統(tǒng)一微服務(wù)在與外部系統(tǒng)交互的過程中還應(yīng)當遵照下列接口方式：（1）代表性狀態(tài)傳輸（REST）服務(wù)：①綜合資源系統(tǒng)和外部系統(tǒng)提供的數(shù)據(jù)解決的接口數(shù)據(jù)集，重要提供一次操作10條以內(nèi)的數(shù)據(jù)增刪改查的接口服務(wù)，接口數(shù)據(jù)傳輸采用對象標記（JSON）字符串，采用Unicode的可變長度字符編碼（UTF-8）；②外系統(tǒng)與綜合資源系統(tǒng)之間的接口采用代表性狀態(tài)傳輸服務(wù)形式來進行業(yè)務(wù)數(shù)據(jù)的交互；③為了確保接口升級不影響以前的功效，代表性狀態(tài)傳輸服務(wù)中都必須要帶版本號，如http://IP:PORT/api/v1/PON/getONUbyAccount/{account}；④在每次調(diào)用完畢應(yīng)用程序編程接口后，外部系統(tǒng)都會得到一種狀態(tài)碼、錯誤碼和錯誤因素描述，便于外部系統(tǒng)告知顧客定位問題并做出適宜的解決；⑤為了排除接口服務(wù)被攻擊、惡意調(diào)用以及非法調(diào)用等，全部應(yīng)用程序編程接口在客戶端調(diào)用服務(wù)端的時候必須通過身份驗證。分布式遠程過程調(diào)用（XRPC）服務(wù)：服務(wù)調(diào)用以下圖所示：①綜合資源系統(tǒng)內(nèi)部采用分布式遠程過程調(diào)用服務(wù)形式來進行業(yè)務(wù)數(shù)據(jù)的交互，或者大批數(shù)據(jù)解決提供的接口方式，減少了REST服務(wù)中的數(shù)據(jù)限制和效率問題；②分布式遠程過程調(diào)用數(shù)據(jù)都采用綜合資源內(nèi)部程序語言（JAVA）數(shù)據(jù)對象進行傳遞；③分布式遠程過程調(diào)用服務(wù)最后調(diào)用的是統(tǒng)一微服務(wù)接口其它服務(wù)編制和服務(wù)編排微服務(wù)架構(gòu)繼承了面對服務(wù)架構(gòu)的整體思路，強調(diào)將單體型應(yīng)用或服務(wù)拆分為由具體、微小、獨立的服務(wù)應(yīng)用，服務(wù)是最核心的抽象手段，業(yè)務(wù)被劃分(組件化)為一系列粗粒度的業(yè)務(wù)服務(wù)和業(yè)務(wù)流程。服務(wù)通過基于原則、精擬定義的接口進行通信，通信可能涉及簡樸數(shù)據(jù)傳遞、兩個或更多在一種活動中協(xié)作的服務(wù)。微服務(wù)架構(gòu)能有效減少系統(tǒng)的耦合性，增強靈活性。采用WebService實現(xiàn)微服務(wù)架構(gòu)應(yīng)用最廣泛。單個服務(wù)功效有限，難以滿足應(yīng)用需求，把單個服務(wù)按一定的業(yè)務(wù)流程邏輯組合起來，從而提供更強大、更完整的業(yè)務(wù)功效。在基于微服務(wù)架構(gòu)的應(yīng)用系統(tǒng)中，全部功效均是被精擬定義的、可調(diào)用的、獨立的服務(wù)，能夠被靈活有序組合而構(gòu)建不同的業(yè)務(wù)流程,最后達成敏捷的、不受限制的服務(wù)集成目的，從而使IT能夠隨著業(yè)務(wù)需求的變化而自由調(diào)節(jié)，達成所謂的“隨需而變”的最高境界。服務(wù)組合方式涉及服務(wù)編制和服務(wù)編排。現(xiàn)在，基于編制的Web服務(wù)組合描述規(guī)范重要是WS-BPEL，基于編排的Web服務(wù)組合描述規(guī)范重要是WS-CDL。(1)服務(wù)編制服務(wù)編制描述一種參加者使用一種中心流程來協(xié)調(diào)不同的服務(wù)操作，其成果能夠看作一種新的服務(wù)，能夠執(zhí)行，只是執(zhí)行的過程需要調(diào)用別的服務(wù)。(2)服務(wù)編排服務(wù)編排描述多個參加者為實現(xiàn)多組織業(yè)務(wù)功效而進行的交互，也就是說編排重要描述的是不同流程之間的交互狀況，其成果能夠看作一種業(yè)務(wù)流程，也能夠執(zhí)行。3微服務(wù)組合設(shè)計3.1服務(wù)編制設(shè)計MUSIC的接口以WebService發(fā)布，每個MUSIC接口就是一種WebService服務(wù)，配備接口的關(guān)系，關(guān)注點為接口功效整合，最后以一種新接口對外公布，顧客能夠運用MUSIC提供的接口使用工具調(diào)用該接口。接口的關(guān)系涉及次序、分支和循環(huán)(下圖）。3.2服務(wù)編排設(shè)計與服務(wù)編制類擬，將MUSIC接口視為服務(wù)，根據(jù)業(yè)務(wù)流程配備接口，關(guān)注點為業(yè)務(wù)邏輯，最后以解決成果提交給顧客。接口的關(guān)系涉及次序、分支和循環(huán)（下圖）。進而將業(yè)務(wù)流程組合形成業(yè)務(wù)場景。在業(yè)務(wù)場景中，每個業(yè)務(wù)流程的地位平等。允許顧客訂閱業(yè)務(wù)流程和業(yè)務(wù)場景執(zhí)行成果（下圖）。微服務(wù)架構(gòu)和容器作為服務(wù)CaaS微服務(wù)架構(gòu)是面對服務(wù)架構(gòu)（Service-orientedArchitecture，SOA）之上發(fā)展而來的新興的軟件體系架構(gòu)，它將傳統(tǒng)的單一、大型的應(yīng)用程序（MonolithicApplication）構(gòu)建為一系列細粒度、獨立布署、松散耦合的服務(wù)。每個服務(wù)圍繞具體業(yè)務(wù)進行構(gòu)建，運行在其獨立的進程中，提高隔離性和模塊化，實現(xiàn)持續(xù)交付和布署。服務(wù)與服務(wù)間采用輕量級的通信機制互相協(xié)作（普通是基于HTTP合同的RESTfulAPI）。微服務(wù)架構(gòu)帶來諸多好處，涉及單個服務(wù)含有更簡樸的代碼庫，同時含有隔離更新和獨立擴展的能力，使用不同編程語言編寫服務(wù)，并運用不同的中間件或者不同服務(wù)的數(shù)據(jù)層。微服務(wù)架構(gòu)啟動了應(yīng)用程序開發(fā)的新趨勢，通過使用微服務(wù)去大幅度減少系統(tǒng)的復(fù)雜性并提高彈性和可擴展性，更加容易地進行伸縮、移除和布署系統(tǒng)的組件，并且提高使用不同框架和工具的靈活性。ASP通過微服務(wù)架構(gòu)將大型工作流應(yīng)用，劃分成大量細粒度、低耦合的微服務(wù)任務(wù)。這些微服務(wù)是輕量級的，并且執(zhí)行獨立于彼此的不同任務(wù)，因此根據(jù)顧客需求的不同而快速、獨立地調(diào)度和布署，從而提高了工作流應(yīng)用的靈活性和敏捷性。普通ASP將顧客提交的大量工作流應(yīng)用布署和調(diào)度到現(xiàn)有云計算服務(wù)提供商（CloudServiceProvider，CSP）提供IaaS的虛擬機上，例如亞馬遜提供的AmazonElasticComputeCloud（AmazonEC2）。但是由于微服務(wù)架構(gòu)將工作流應(yīng)用劃分成大量細粒度、松耦合的協(xié)同工作的微服務(wù)任務(wù)，每個微服務(wù)任務(wù)對計算資源的需求普通比較（普通是單個vCPU和MB級別的RAM），遠遠不大于IaaS上的虛擬機規(guī)格（多個vCPU和GB級別RAM）。并且微服務(wù)強調(diào)工作流任務(wù)之間松耦合，對任務(wù)隔離性有一定的規(guī)定，并且規(guī)定任務(wù)之間進行輕量級通信協(xié)作。若是采用傳統(tǒng)CSP提供的IaaS，租賃大量的虛擬機來對微服務(wù)工作流提供計算資源和資源隔離，會造成大量的計算資源浪費。于是，在現(xiàn)有云計算平臺下對微服務(wù)工作流的進行布署和調(diào)度成為了一種棘手的問題。而隨著輕量級虛擬化技術(shù)——Linux容器（Linuxcontainer，LXC）和Docker容器（Dockercontainer）的出現(xiàn)解決了大規(guī)模微服務(wù)的布署和調(diào)度的問題。云計算的核心是虛擬化（Virtualization）。虛擬化帶來了從物理機（PhysicalMa-chine，PM）分離計算資源的好處。采用系統(tǒng)級虛擬化技術(shù)（Hypervisor）的虛擬機包含完整的客戶機操作系統(tǒng)（GuestOS）和特定軟件，另外虛擬機的運行環(huán)境和配備能夠封裝成鏡像并任意拷貝。這種機制普通用于在云計算中運行的應(yīng)用程序。虛擬機解決了調(diào)度、鏡像封裝和計算資源存取的問題。但是由于虛擬機包含有完整的GuestOS，造成了虛擬機實例需要額外的CPU、RAM和磁盤存儲資源，并且其啟動緩慢（普通需要幾分鐘）。而采用輕量級虛擬技術(shù)（LightweightVirtualization）的容器，使用了系統(tǒng)級別的機制——基于Linux內(nèi)核提供的兩個機制：Cgroups（實現(xiàn)計算資源按需分派）和Namespace（實現(xiàn)任務(wù)隔離）。多個容器共享一種宿主機操作系統(tǒng)（HostOS）內(nèi)核，容器中包含需要布署的應(yīng)用和它依賴的系統(tǒng)環(huán)境，容器大小普通只有幾十到幾百MB。容器沒有了虛擬機的GuestOS，實現(xiàn)了更輕量級的虛擬化，資源的額外開銷更小，啟動快速（普通達成秒級啟動）。因此容器被作為了更為靈活的封裝、交付和編排軟件服務(wù)與應(yīng)用程序的工具。隨著Docker及其生態(tài)系統(tǒng)的出現(xiàn)，帶來了持續(xù)布署與測試、跨云平臺支持、環(huán)境原則化與版本控制、高資源運用率與隔離、容器跨平臺性與鏡像、易于理解且易用和應(yīng)用鏡像倉庫等好處，使得容器技術(shù)更加易于使用。由于微服務(wù)架構(gòu)里面強調(diào)單個組件是在獨立的進程里面運行，各個組件之間在布署時必須有進程級別的隔離。一臺服務(wù)器需要初始化幾十個甚至更多的進程進行應(yīng)用組件的布署。為了保持進程間的隔離性，能夠使用虛擬機，但是幾十個進程都完全使用獨立的虛擬機是不現(xiàn)實的，而這個問題可使用輕量級的Docker容器來解決，Docker容器能夠十分便捷地搭建微服務(wù)。Docker容器技術(shù)使用Cgroups和Namespace的Linux內(nèi)核接口，允許不同容器共享相似的內(nèi)核，同時容器之間進行完全的隔離。Docker執(zhí)行環(huán)境使用libcontainer的模塊并原則化其接口。Docker同樣為容器鏡像提供類GitHub的資源庫DockerHub，讓容器的共享和公布非常簡樸，也正是這種相似主機上的容器隔離簡化了不同編程語言開發(fā)的微服務(wù)代碼布署。使用Docker，通過創(chuàng)立一種Dockerfile來描述全部需要的編程語言、軟件框架和應(yīng)用服務(wù)之間的依賴庫。每個Docker容器是獨立的容器，完全做到進程級別的隔離，資源占用率小，這些特點滿足微服務(wù)架構(gòu)的開發(fā)測試和自動化布署。虛擬機技術(shù)與Docker容器技術(shù)的比較以下圖所示。如今多數(shù)主流的云服務(wù)提供商，例如AmazonWebService、MicrosoftAzure、谷歌Cloud和阿里云等，都推出了容器即服務(wù)（ContainerasaService，CaaS），涉及AmazonElasticContainerService（AmazonECS）、谷歌KubernetesEngine（GKE）、MicrosoftAzureContainerService（AKS）和AlibabaCloudContainerService等。相比較傳統(tǒng)的基于虛擬機技術(shù)的云計算平臺，CaaS以容器為資源分割和調(diào)度的基本單位，封裝整個軟件運行時環(huán)境，為開發(fā)者和系統(tǒng)管理員提供用于構(gòu)建、公布和運行分布式應(yīng)用的平臺。CaaS位于IaaS和PaaS之間，即使IaaS提供虛擬化計算資源，PaaS提供特定于應(yīng)用程序的運行時服務(wù)，但CaaS通過為布署的應(yīng)用程序（或應(yīng)用程序的不同模塊）提供隔離的環(huán)境將IaaS和PaaS粘合在一起。當容器云專注于資源共享與隔離、容器編排與布署時，它更靠近傳統(tǒng)的IaaS；當容器云滲入到應(yīng)用支撐與運行時環(huán)境時，它更靠近傳統(tǒng)的PaaS，以下圖所示：普通，能夠在私有物理機上直接使用Docker容器來布署、運行微服務(wù)任務(wù)。但是在公有云平臺（如AmazonWebService、谷歌Cloud、MicrosoftAzure和阿里云等）上，考慮到Docker容器需要依賴于HostOS，普通將微服務(wù)運行在Docker容器中，普通一種微服務(wù)布署在一種類型的容器實例之中，再將Docker容器布署在虛擬機實例上，虛擬機實例只有操作系統(tǒng)而不包含其它的應(yīng)用軟件。微服務(wù)布署與傳統(tǒng)應(yīng)用布署的比較以下圖所示：業(yè)務(wù)流程建模業(yè)務(wù)流程建模業(yè)務(wù)流程是對組織內(nèi)外多個管理邏輯的抽象與視圖的刻畫。流程管理理論隨著信息時代的到來而日漸豐富，信息技術(shù)逐步成為流程管理的重要支持手段。業(yè)務(wù)流程管理是從工作流管理拓展而成的一種新的研宄領(lǐng)域，其目的是通過使用若干新辦法、技術(shù)與工作流軟件來對涉及人、組織、公司應(yīng)用、業(yè)務(wù)對象與其它信息資源的公司實際運作流程的設(shè)計、執(zhí)行、控制、分析等諸多環(huán)節(jié)進行全方面的支持與管理。業(yè)務(wù)流程管理的本質(zhì)是構(gòu)造卓越的業(yè)務(wù)流程，因此業(yè)務(wù)流程是其核心。為了描述、分析與執(zhí)行業(yè)務(wù)流程，必須首先對它進行建模。業(yè)務(wù)流程建模的重要目的是以模型元素及規(guī)范的形式，對復(fù)雜的流程構(gòu)造與關(guān)系予以抽象體現(xiàn)，并通過模型使流程參加者對業(yè)務(wù)流程邏輯達成一致的理解。服務(wù)編排如今的業(yè)務(wù)流程協(xié)作模型重要分為兩大類：中心化與分布化。傳統(tǒng)的中心化編排模型稱為編配（Orechestration），描述復(fù)雜計算機系統(tǒng)、中間件與業(yè)務(wù)的自動化的安排、協(xié)調(diào)與管理，是典型的中心化的模型。新興的分布式的編排模型稱為編排（Choreography），對應(yīng)著分布式的模型。中心化的優(yōu)點是容易獲取全局狀態(tài)，缺點是控制中心脆弱，容易形成瓶頸，分布化則剛好相反。為了實現(xiàn)分布式系統(tǒng)環(huán)境中的協(xié)作，業(yè)界傾向使用分布化的模式，因此需要協(xié)調(diào)各個參加者之間的合作，一起完畢業(yè)務(wù)目的。隨著服務(wù)的運行環(huán)境越來越去中心化，微服務(wù)編排也由傳統(tǒng)的中心化編排模型發(fā)展到了分布式的編排模型。傳統(tǒng)的中心化編配無法較好地描述如今復(fù)雜的業(yè)務(wù)流程，也無法快速響應(yīng)業(yè)務(wù)流程的快速變化，故需要采用分布式編排方式。ＷＳ－ＣＤＬ（WebServiceChoreographyDescriptionLanguage，網(wǎng)絡(luò)服務(wù)編排描述語言）即Choreography模型的一種實例。通過對主流的服務(wù)編排辦法進行分析，能夠發(fā)現(xiàn)它們都存在某些程度上的局限性。具體體現(xiàn)在下列幾個方面：第一缺少能夠運行的系統(tǒng)。第二模型比較復(fù)雜或者含糊，未明確分辨或定義服務(wù)注冊、服務(wù)編排、服務(wù)執(zhí)行等核心構(gòu)成部分。第三服務(wù)的執(zhí)行并沒有充足運用分布式自治場景。如今電子商務(wù)平臺皆為大規(guī)模的分布式系統(tǒng)，并且逐步采用微服務(wù)架構(gòu)來構(gòu)建。其中很難實現(xiàn)一種“上帝視角”的控制中心，故實踐“聲明式”思想時可使用Choreography。提高分布式環(huán)境中服務(wù)編排的效率，增加系統(tǒng)自動化的性能，對于電子商務(wù)公司減少成本有非常重要的意義。本系統(tǒng)重要針對分布式環(huán)境中的微服務(wù)進行編排，是典型的去中心化協(xié)作模式。在現(xiàn)在的跨界服務(wù)中，例如新零售業(yè)，這幾個差別與問題日益突出，特別是當服務(wù)從單中心簡樸流程轉(zhuǎn)變?yōu)槎嘀行膹?fù)雜流程時，分布式環(huán)境中的服務(wù)有產(chǎn)生了服務(wù)編排的問題。如何盡量地運用現(xiàn)有的數(shù)據(jù)實體與服務(wù)流程、重用己有資源來完畢新的服務(wù)建設(shè)，已成為服務(wù)開發(fā)的重要問題。因此，新的業(yè)務(wù)流程建模辦法需要完畢以下任務(wù)。＊有效管理數(shù)據(jù)。與以活動為中心與傳統(tǒng)的以實體為中心的流程建模辦法不同，該業(yè)務(wù)流程建模辦法應(yīng)能在有大量實體的服務(wù)中有效地管理數(shù)據(jù)。同時數(shù)據(jù)之間的互相依賴關(guān)系也能夠由該模型描述體現(xiàn)。需求與開發(fā)人員的分離。當新的服務(wù)需求提出時，業(yè)務(wù)人員能夠通過現(xiàn)有資源快速定位與設(shè)計，而無需開發(fā)人員的參加。開發(fā)人員應(yīng)專注于開發(fā)新的能力，他們不需要理解甚至不理解客戶的服務(wù)需求。代碼可被高效管理與重用。全部的函數(shù)與代碼模塊都應(yīng)與流程分離，這些代碼在本模型中被抽象為能力。本模型應(yīng)輕松高效地管理與應(yīng)用這些能力。分布式環(huán)境中的服務(wù)編排。傳統(tǒng)單中心簡樸流程己經(jīng)無法滿足大型公司的業(yè)務(wù)需求，隨著越來越多公司使用多中心復(fù)雜流程，中心化編排模型己經(jīng)無法滿足需求，必須使用分布式服務(wù)編排。服務(wù)編排路由算法在進行服務(wù)編排的時候，需要考慮某個服務(wù)的具體提供者，此時涉及到服務(wù)選擇算法。本系統(tǒng)將服務(wù)的選擇抽象為路由問題，從而可使用路由算法來進行尋路。傳統(tǒng)的靜態(tài)路由算法有其應(yīng)用場景與問題，無法較好的合用于此處所述的分布式運行環(huán)境，對此本系統(tǒng)使用的是動態(tài)路由算法結(jié)合靜態(tài)路由算法來進行服務(wù)服務(wù)選擇。１靜態(tài)路由算法靜態(tài)路由算法也稱非自適應(yīng)算法，該算法不會根據(jù)運行時的輸出來變化選擇方略。相反，其使用選定的方略來進行選擇。靜態(tài)意味著在服務(wù)選擇之前己經(jīng)建立了模式，并且己經(jīng)建立的服務(wù)社群關(guān)系不應(yīng)當被變化。當系統(tǒng)已經(jīng)擬定下來一條服務(wù)組合途徑，服務(wù)啟動器首先需要選擇第一種服務(wù)提供商的服務(wù)。泛洪算法泛洪算法是靜態(tài)路由的暴力算法，該算法比較簡樸粗暴。服務(wù)社群從鄰居社群獲取消息，然后將消息發(fā)送給除了原始輸入社群以外的其它鄰居社群。很顯然，該方式能夠協(xié)助找到最短途徑，但其產(chǎn)生大量的重復(fù)消息，非常耗時故不適合于實際的工作環(huán)境應(yīng)當改善這種算法來減少交換的消息數(shù)量。服務(wù)社群統(tǒng)計自己已經(jīng)泛洪的信息，當再次泛洪該信息時，該社群能夠取消發(fā)送從而減少重復(fù)消息的發(fā)送。泛洪算法是一種構(gòu)建全部的服務(wù)組合的簡樸算法。該算法可產(chǎn)生最佳途徑，但消耗大量時間與空間。其全部可能性是每一種服務(wù)社群總數(shù)量的乘積，當單個服務(wù)的數(shù)量增加時，服務(wù)組合的總量將急劇增加。因此該辦法不適合在大型網(wǎng)絡(luò)環(huán)境中進行服務(wù)選擇。Dijkstra算法另一種靜態(tài)算法是Dijkstra算法。在該算法過程中，社群中的每個服務(wù)節(jié)點都有標記信息，標記信息中最少包含兩種信息，一種是表達從源頭結(jié)點達成該節(jié)點的權(quán)重，另一種信息是該節(jié)點本身的狀態(tài)。節(jié)點普通有兩種狀態(tài)，暫定態(tài)與穩(wěn)定態(tài)。在算法剛開始的時候，全部的節(jié)點權(quán)重都是最大值，狀態(tài)都是暫定態(tài)，隨著源頭結(jié)點慢慢從鄰居那里搜索整個圖查找最短途徑，每個節(jié)點的權(quán)重與狀態(tài)漸漸穩(wěn)定下來，直到找到結(jié)束節(jié)點。本系統(tǒng)使用Dijkstra算法作為靜態(tài)路由算法，為服務(wù)的最短途徑查找提供算法理論與編碼實現(xiàn)的支持。２動態(tài)路由算法在實際的服務(wù)環(huán)境下，只有靜態(tài)路由算法是遠遠不夠的，還需要結(jié)合動態(tài)路由算法來進行服務(wù)選擇。組合互聯(lián)網(wǎng)上的服務(wù)需要應(yīng)對高度動態(tài)性的環(huán)境，服務(wù)選擇算法必須能夠進行動態(tài)的路由，這樣才能夠應(yīng)對新服務(wù)的不停涌現(xiàn)與舊服務(wù)的偶然消亡。Bellman-Ford算法Bellman-Ford算法又稱距離向量算法。在該算法中，每個服務(wù)社群都維護一張路由表，其中統(tǒng)計了每個鄰居的權(quán)重信息。每個服務(wù)社群通過接受鄰居社群發(fā)來的向量信息來更新自己的路由表，從而維護整個系統(tǒng)的信息。距離向量算法很簡樸但卻有某些缺點。在靜態(tài)系統(tǒng)中，該算法傳輸路由表到每一種服務(wù)社群，但是在動態(tài)的系統(tǒng)中，其穩(wěn)定性不夠好。當服務(wù)社群被變化之后，例如建立了新的聯(lián)系，有關(guān)信息的傳輸會很慢，這意味著某些服務(wù)社群會保有錯誤的選擇信息而不自知。鏈略狀態(tài)算法為了改善距離向量算法，出現(xiàn)了新的動態(tài)的算法：鏈路狀態(tài)算法。鏈路狀態(tài)算法又稱為最短途徑優(yōu)先算法，該算法的環(huán)節(jié)以下：１．發(fā)現(xiàn)鄰居節(jié)點，獲取其網(wǎng)絡(luò)地址。２．計算每個鄰居節(jié)點之間的成本或延遲。３．構(gòu)建一種接受新消息的數(shù)據(jù)包，鏈路狀態(tài)數(shù)據(jù)包。４．將此數(shù)據(jù)包發(fā)送給另一種鄰居。５．計算到其它鄰居的最短途徑。系統(tǒng)通過該算法能夠快速收斂，從而維護整個系統(tǒng)中服務(wù)信息。本系統(tǒng)采用鏈路狀態(tài)算法作為動態(tài)路由算法的實現(xiàn)方案。業(yè)務(wù)流程模型本系統(tǒng)采用了業(yè)務(wù)流程模型用于描述、設(shè)計、驗證與管理系統(tǒng)中的服務(wù)。在該模型中構(gòu)建了解決數(shù)據(jù)的實體特性模塊、解決功效與接口的能力特性模塊，和在此兩者基礎(chǔ)上用分層方式管理服務(wù)流程的流程模塊。這三個子模塊中的每一種模塊能夠獨立完畢服務(wù)的部分建模工作，它們共同構(gòu)成了流程模型整體。為了實現(xiàn)前復(fù)雜場景中業(yè)務(wù)流程模型需要實現(xiàn)的任務(wù)，本流程模型所使用的的實體特性模塊、能力特性模塊、精化流程模塊三個子模塊重要功效以下：實體特性模塊可用于描述與定義服務(wù)中使用的數(shù)據(jù)實體以及數(shù)據(jù)之間的互相依賴性，以實現(xiàn)有效管理數(shù)據(jù)。能力特性模塊用于管理在服務(wù)開發(fā)期間生成的能力，以實當代碼管理與重用。此處的能力重要指的是服務(wù)中涉及到的功效與接口。精化流程模塊是一種層次化模塊，能夠通過狀態(tài)、活動的約束來描述服務(wù)流程與數(shù)據(jù)，以實現(xiàn)需求與開發(fā)人員分離。簡而言之，精化流程模塊從能力特性模塊調(diào)用能力，能力特性模塊解決實體特性模塊中實體的數(shù)據(jù)，精化流程模塊描述實體特性模塊中實體的生命周期。這三個模塊一起構(gòu)建了本次的流程模型。實體特性模塊實體特性模塊用于為含有大量數(shù)據(jù)的實體進行建模，并可表達實體數(shù)據(jù)之間的互相依賴性。本模型通過使用特性建模辦法提出一種四層實體構(gòu)造辦法，將實體構(gòu)造為四層的樹，以訂單實體為例，第一層是實體層。在新零售中，第一層能夠是客戶、商品、訂單或其它數(shù)據(jù)實體。第二層是通過實體關(guān)聯(lián)關(guān)系分類的特性。例如在訂單的實體中，顧客能夠是第二層的節(jié)點，因數(shù)據(jù)從顧客（買家與賣家）獲得并保存在訂單中。第三層包含同時讀取、寫入與顯示的小數(shù)據(jù)集，第四層是屬性。能力特性模塊能力特性模塊旨在將功效代碼與流程解耦，從而以有效的方式管理它們，并避免濫用功效。能力特性模塊能夠通過特性建模辦法來建模，能力之間的約束也可通過此方式來體現(xiàn)。其中，葉子節(jié)點是元能力，其它節(jié)點代表復(fù)合能力，父子節(jié)點之間的關(guān)系擬定調(diào)用方式。通過構(gòu)建能力特性模塊，可在系統(tǒng)中管理服務(wù)所用到的功效與接口。通過對能力的調(diào)用，實體可完畢服務(wù)流程并實現(xiàn)狀態(tài)的轉(zhuǎn)移。能力特性模塊也采用與實體樹類似的樹狀圖來表達能力，但不限制層級數(shù)。精化流程模塊精化流程模塊旨在通過三個約束來體現(xiàn)實體的生命周期（服務(wù)流程）：狀態(tài)、活動與數(shù)據(jù)。該模塊能夠通過此約束分層地解析與管理復(fù)雜的流程，其本質(zhì)上是—個以數(shù)據(jù)為中心的模型。擬定重要實體后，下一步構(gòu)建其生命周期。例如當系統(tǒng)需要交易服務(wù)時，訂單是其重要實體。在狀態(tài)約束層，系統(tǒng)需驗證訂單可能出現(xiàn)的狀態(tài)。然后在活動約束層中，系統(tǒng)在狀態(tài)之間添加活動與網(wǎng)關(guān)，并使用能力來填充活動。最后在數(shù)據(jù)約束層中，系統(tǒng)通過將參加者綁定到活動，配備能力的輸入與輸出以及確認條件來擬定服務(wù)流程。精化流程模塊通過這三個約束來逐步精細化服務(wù)流程，該模塊是分層逐級精細化的。精化流程模塊一共分為五層，每層都有明確的目的，有助于業(yè)務(wù)需求的分解，也有助于業(yè)務(wù)流程的復(fù)用。流程模型的應(yīng)用新零售作為一種新的零售模式，它運用大數(shù)據(jù)與人工智能的先進技術(shù)來更新商品的生產(chǎn)、流通與分派流程。新零售是商業(yè)生態(tài)構(gòu)造的翻新，集成了在線服務(wù)，線下體驗與當代物流。使用本業(yè)務(wù)流程模型構(gòu)建新零售業(yè)務(wù)流程的環(huán)節(jié)以下：第一需要構(gòu)建并確認實體。當需要構(gòu)建新服務(wù)時，應(yīng)首先確認參加此服務(wù)的實體。這些實體由實體特性模塊構(gòu)建。實體特性模塊能夠協(xié)助檢查實體中屬性之間的約束。服務(wù)涉及的全部實體中，應(yīng)有一種重要實體。服務(wù)流程圍繞著重要實體展開，只有重要實體擁有能綁定到該服務(wù)的里程碑狀態(tài)。其它實體使用固定狀態(tài)，該狀態(tài)是一種名為“參加者”的保存核心字另外，參加者實體的屬性能夠被當作服務(wù)中的資源來使用。對于新零售，重要實體是訂單，參加者涉及客戶、賣方、銀行與電商平臺。此時訂單是一種重要實體，它包含商品、客戶、賣家與其它信息。第二擬定重要實體可能出現(xiàn)的狀態(tài)。由于上文已經(jīng)確認新零售服務(wù)的重要實體是訂單，下一步是建立狀態(tài)約束流程。狀態(tài)約束流程的里程碑與重要實體的狀態(tài)綁定，在本例中重要實體為訂單，故綁定的狀態(tài)約束流程涉及待支付、待發(fā)貨、待收貨、待打款、