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