微服務(wù)管控平臺(tái)

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