在數(shù)字經(jīng)濟(jì)環(huán)境下，云計(jì)算、大數(shù)據(jù)、移動(dòng)社交、物聯(lián)網(wǎng)、人工智能等先進(jìn)技術(shù)的廣泛運(yùn)用，個(gè)人、企業(yè)乃至整個(gè)生產(chǎn)體系中的制造資源都實(shí)現(xiàn)了廣泛、實(shí)時(shí)的聯(lián)接，不僅改變了人們的生活方式，而且正在改變商業(yè)本質(zhì)。數(shù)字化轉(zhuǎn)型是所有企業(yè)的必然選擇，企業(yè)開展數(shù)字化轉(zhuǎn)型的目的就是要更好地為用戶創(chuàng)造價(jià)值，以實(shí)現(xiàn)最佳的客戶體驗(yàn)為目標(biāo)，顛覆性的改變企業(yè)產(chǎn)品實(shí)現(xiàn)和交付的生產(chǎn)活動(dòng)過程。通過對(duì)產(chǎn)品相關(guān)活動(dòng)中的用戶數(shù)據(jù)洞察，系統(tǒng)化進(jìn)行知識(shí)沉淀和傳承，改善產(chǎn)品的數(shù)字化設(shè)計(jì)能力及服務(wù)水平，優(yōu)化產(chǎn)品的交付機(jī)制，從而滿足客戶的個(gè)性化體驗(yàn)。而這一切的業(yè)務(wù)活動(dòng)中，在產(chǎn)品的需求產(chǎn)生直至產(chǎn)品實(shí)現(xiàn)交付的完整商業(yè)實(shí)現(xiàn)過程，數(shù)據(jù)實(shí)現(xiàn)有效、連續(xù)和閉環(huán)的傳遞，產(chǎn)品設(shè)計(jì)、制造乃至整個(gè)供應(yīng)鏈的資源實(shí)現(xiàn)密切的協(xié)同，工業(yè)互聯(lián)網(wǎng)平臺(tái)是面向制造業(yè)數(shù)字化、網(wǎng)絡(luò)化智能化需求，構(gòu)建基于海量數(shù)據(jù)的采集、匯聚分析和服務(wù)體系支撐制造資源泛在連接、彈性供給、高效配置的開放式工業(yè)互聯(lián)網(wǎng)平臺(tái)。

　　圖1 工業(yè)互聯(lián)網(wǎng)平臺(tái)

　　GE首席技術(shù)官Dave Bartlett認(rèn)為工業(yè)互聯(lián)網(wǎng)平臺(tái)本質(zhì)是一個(gè)工業(yè)操作系統(tǒng)其功能類似微軟的Windows、谷歌的安卓系統(tǒng)或者蘋果的iOS系統(tǒng)。就像以上所談到的電腦或手機(jī)操作系統(tǒng)一樣，工業(yè)操作系統(tǒng)層實(shí)現(xiàn)了工業(yè)現(xiàn)場各種復(fù)雜設(shè)備或控制邏輯的抽象，標(biāo)準(zhǔn)化了不同廠商產(chǎn)品的接口差異，實(shí)現(xiàn)了不同的協(xié)議轉(zhuǎn)換，以底層API的形式給架構(gòu)其中的PaaS平臺(tái)層進(jìn)行調(diào)用，以微服務(wù)的形式提供預(yù)制化的構(gòu)件，從而在應(yīng)用層快速地利用構(gòu)件進(jìn)行服務(wù)編排，實(shí)現(xiàn)復(fù)雜的用戶應(yīng)用需求。

　　微服務(wù)（Microservices）架構(gòu)

　　過去的企業(yè)軟件多是按管理域劃分的大軟件，如ERP、PLM、SCM等等，這些軟件往往模塊眾多，功能復(fù)雜，強(qiáng)調(diào)以自身管理視角的產(chǎn)品全生命周期協(xié)同工作。但在數(shù)字化轉(zhuǎn)型的背景驅(qū)動(dòng)下，面對(duì)批量較小的產(chǎn)品訂單，更加個(gè)性化、人性化的產(chǎn)品特性組合，工作業(yè)務(wù)流程從長流程變成短流程，鼠標(biāo)點(diǎn)擊變成手指觸屏，線性協(xié)作變成點(diǎn)狀聚合，大軟件系統(tǒng)不得不適應(yīng)而被拆解為更小功能服務(wù)的小軟件服務(wù)?；ヂ?lián)網(wǎng)需求的長尾效應(yīng)推動(dòng)軟件碎片化，讓工作無時(shí)無處都可以被處理，而越來越多的碎片化的需求又進(jìn)一步反身強(qiáng)化更多智能設(shè)備的推廣使用。應(yīng)用交付的速度永遠(yuǎn)跟不上業(yè)務(wù)需求的變化，業(yè)務(wù)部署與運(yùn)維復(fù)雜度提高導(dǎo)致應(yīng)用的可用性下降，多元化業(yè)務(wù)和復(fù)雜體系架構(gòu)導(dǎo)致IT治理的困難，技術(shù)人員不斷的重復(fù) “開發(fā)—測(cè)試—上線”的輪回。

　　圖2 傳統(tǒng)應(yīng)用架構(gòu) Vs 微服務(wù)架構(gòu)

　　ThoughtWorks首席科學(xué)家Martin Fowler在2014年提出了微服務(wù)的概念，把一個(gè)大型的應(yīng)用軟件按照功能和服務(wù)分類拆分為數(shù)十個(gè)微服務(wù)，每個(gè)服務(wù)運(yùn)用于自己的獨(dú)立進(jìn)程，通常是采用基于HTTP協(xié)議的RESTful API的輕量級(jí)通信機(jī)制，松耦合的服務(wù)能夠被獨(dú)立更新的部署，每一個(gè)微服務(wù)可滿足用戶的一個(gè)需求，用來提升企業(yè)的敏捷運(yùn)營與快速的業(yè)務(wù)拓展。這種架構(gòu)將原本大而復(fù)雜的單體架構(gòu)，重組為小而精美的獨(dú)立服務(wù)，讓工作變得更加高效、便捷、直擊重點(diǎn)。當(dāng)企業(yè)對(duì)某些微服務(wù)有特殊需要時(shí)，只需將針對(duì)這部分微服務(wù)的IT資源進(jìn)行升級(jí)，對(duì)這些微服務(wù)進(jìn)行更新。在系統(tǒng)出現(xiàn)故障時(shí)，微服務(wù)也可實(shí)現(xiàn)對(duì)故障部分單獨(dú)隔離，以免影響到整個(gè)系統(tǒng)的使用。開發(fā)人員也可更便捷地基于“云”進(jìn)行應(yīng)用系統(tǒng)開發(fā)。

　　容器（Container）技術(shù)

　　傳統(tǒng)軟件架構(gòu)特性是單體應(yīng)用，開發(fā)周期至少以月為單位進(jìn)行發(fā)布和升級(jí)，代碼一般使用一種語言開發(fā)，不同的組件緊耦合，經(jīng)常依賴于公共的庫，部署周期以月為單位，部署依賴人工操作，組件版本復(fù)雜，操作風(fēng)險(xiǎn)高，時(shí)間管理成本均居高不下。以JAVA應(yīng)用為代表的三層架構(gòu)的部署模式，即便是在虛擬機(jī)環(huán)境發(fā)布環(huán)境，也是需要建立相應(yīng)的操作系統(tǒng)和應(yīng)用服務(wù)器，以完全虛擬應(yīng)用的運(yùn)行環(huán)境。

　　圖3 虛擬機(jī)與容器化虛擬

　　容器的代表性產(chǎn)品Docker的出現(xiàn)是一個(gè)標(biāo)志性的節(jié)點(diǎn)，2013年首次提出了Build→Ship→Run的概念，使用鏡像方式能夠?qū)?yīng)用程序和它依賴的操作系統(tǒng)、類庫以及運(yùn)行時(shí)環(huán)境整體打包，統(tǒng)一交付，消除了對(duì)傳統(tǒng)應(yīng)用對(duì)操作系統(tǒng)、應(yīng)用服務(wù)器不同廠商及版本，甚至對(duì)于環(huán)境變量、基礎(chǔ)函數(shù)庫API調(diào)用的深度依賴，因此容器的本質(zhì)是一種操作系統(tǒng)級(jí)別的虛擬化，與底層所使用的平臺(tái)無關(guān)，容器可以在與主流的Windows、Linux等主流的操作系統(tǒng)上運(yùn)行，意味著應(yīng)用架構(gòu)一旦轉(zhuǎn)換為容器化并且遷移部署之后，就可以在任何云平臺(tái)之間無縫遷移。使用容器能夠利用鏡像快速部署運(yùn)行服務(wù)，能夠?qū)崿F(xiàn)業(yè)務(wù)的快速交付，縮短業(yè)務(wù)的上線周期，極大地方便運(yùn)維人員的上線部署工作。

　　容器較傳統(tǒng)虛擬化有更低資源使用粒度，在一臺(tái)物理機(jī)上可運(yùn)行上百個(gè)容器服務(wù)，從而提高服務(wù)器硬件資源的利用率。當(dāng)遇到高并發(fā)、高流量的大活動(dòng)，容器做到根據(jù)業(yè)務(wù)的負(fù)載進(jìn)行彈性擴(kuò)容，以提供更好的服務(wù)。當(dāng)訪問量降低后，容器平臺(tái)能夠自動(dòng)縮容，及時(shí)釋放空閑資源。

　　開發(fā)運(yùn)維平臺(tái)（DevOps）

　　圖4 基于容器化PaaS構(gòu)建的DevOps

　　DevOps概念早先始于2009年的歐洲，因傳統(tǒng)開發(fā)和運(yùn)維模式無法實(shí)現(xiàn)用戶應(yīng)用快速變化且生命周期較短的現(xiàn)實(shí)。DevOps一詞的來自于Development和Operations的組合，突出重視軟件開發(fā)人員和運(yùn)維人員的溝通合作，通過自動(dòng)化流程來使得軟件構(gòu)建、測(cè)試、發(fā)布更加快捷、頻繁和可靠。早期時(shí)，大家雖然意識(shí)到了這個(gè)問題的，但是苦于當(dāng)時(shí)沒有完善豐富的技術(shù)工具，是一種“理想很豐滿，現(xiàn)實(shí)很骨感”的情況。早期的PaaS平臺(tái)方案初步解決了很多客戶對(duì)于應(yīng)用彈性的需求，但是在容器技術(shù)之前，構(gòu)建一套PaaS平臺(tái)面臨著組件多、量級(jí)大、改造成本高等挑戰(zhàn)，而且對(duì)于運(yùn)行在不同 PaaS 平臺(tái)上的應(yīng)用，很難避免應(yīng)用對(duì)平臺(tái)的深度依賴。譬如，不同的PaaS平臺(tái)對(duì)彈性、高可用、性能、監(jiān)控、日志、版本更新等的實(shí)現(xiàn)方式不同，則對(duì)其上應(yīng)用的架構(gòu)要求也不同；另外，在編程語言和平臺(tái)層的API調(diào)用方面，也會(huì)導(dǎo)致應(yīng)用對(duì)平臺(tái)廠商的深度綁定。以Docker為代表的輕量級(jí)虛擬化容器技術(shù)的發(fā)展使得DevOps成為可能，工業(yè)互聯(lián)網(wǎng)的應(yīng)用直接構(gòu)建在以Cloud Foundry、Kubernetes等為代表的PaaS平臺(tái)之上。

　　工業(yè)APP的構(gòu)建是核心

　　工業(yè) APP 的構(gòu)建是在互聯(lián)網(wǎng)制造背景制造協(xié)作模式轉(zhuǎn)換的核心，其關(guān)注對(duì)工業(yè)技術(shù)知識(shí)的提煉與抽象，將數(shù)據(jù)模型、提煉與抽象的知識(shí)結(jié)果通過形式化封裝與固化形成 APP。封裝了工業(yè)知識(shí)的工業(yè) APP， 對(duì)人和機(jī)器快速高效賦能，突破了知識(shí)應(yīng)用對(duì)人腦和人體所在時(shí)空的限制，最終直接驅(qū)動(dòng)工業(yè)設(shè)備及工業(yè)業(yè)務(wù)。

　　圖 5 工業(yè)App的構(gòu)建處于核心位置

　　基于容器技術(shù)和微服務(wù)架構(gòu)的PaaS平臺(tái)，成功地實(shí)現(xiàn)了DevOps的開發(fā)運(yùn)維一體化的愿景，借助于工業(yè)互聯(lián)網(wǎng)平臺(tái)敏捷架構(gòu)，服務(wù)組件供應(yīng)商、工業(yè)制造商、終端用戶甚至個(gè)體團(tuán)隊(duì)的形成了完整的工業(yè)App開發(fā)、應(yīng)用生態(tài)，推動(dòng)以互聯(lián)網(wǎng)為協(xié)作載體的新一輪專業(yè)分工，將原來在企業(yè)各工程人員、專家頭腦中隱性、分散的工業(yè)技術(shù)知識(shí)、經(jīng)驗(yàn)技巧進(jìn)行模型化、軟件化和商品化，形成標(biāo)準(zhǔn)化的微服務(wù)組件。

　　無論工業(yè)APP團(tuán)隊(duì)的規(guī)?；?qū)嵙Φ拇笮?，都可以使用工業(yè)互聯(lián)平臺(tái)上提供的標(biāo)準(zhǔn)化的微服務(wù)組件，以即插即用的方式組裝成適合用戶特定工業(yè)環(huán)境需求的工業(yè)APP，從而促進(jìn)工業(yè)knowhow的知識(shí)沉淀，以商業(yè)化的方式實(shí)現(xiàn)跨行業(yè)、跨企業(yè)的專業(yè)化傳播與復(fù)用，從而實(shí)現(xiàn)全社會(huì)工業(yè)能力的整體提升。