微服務管控平臺

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