(網(wǎng)經(jīng)社訊)DevOps就是開發(fā)Dev和運(yùn)維Ops集成在一起的平臺(tái)。隨著工業(yè)互聯(lián)網(wǎng)的崛起， DevOps和微服務(wù)恰逢其時(shí)。它重塑軟件開發(fā)的能力，正在引發(fā)廣泛的關(guān)注。
從六組數(shù)據(jù)說起
隨著工業(yè)APP的普及，企業(yè)應(yīng)用變成新的熱點(diǎn)。那么一個(gè)企業(yè)到底需要有多少個(gè)“應(yīng)用”？從六組案例說起。
第一個(gè)數(shù)據(jù)，某銀行有2萬多個(gè)應(yīng)用，其中有1萬個(gè)左右的應(yīng)用是基于J2EE，運(yùn)行在IBM的中間件軟件WAS系統(tǒng)（WebSphere Application Server）。
第二個(gè)就是某個(gè)電信行業(yè)的OEM廠商，其內(nèi)部IT管理應(yīng)用大約有2000個(gè)左右。
第三個(gè)是某鋼鐵集團(tuán)企業(yè)。它的應(yīng)用從研發(fā)到現(xiàn)場(chǎng)制造再到企業(yè)運(yùn)營(yíng)管理在內(nèi)，也包括工業(yè)互聯(lián)網(wǎng)，應(yīng)用有500個(gè)左右。
第四個(gè)是某車聯(lián)網(wǎng)平臺(tái)。該車聯(lián)網(wǎng)平臺(tái)已經(jīng)建設(shè)有17個(gè)應(yīng)用。但在2019年的新需求，則是按照功能點(diǎn)提出來的，加在一起有700多個(gè)新的功能點(diǎn)。這些需求撲面而來，根本無法來得及開發(fā)。而這700多個(gè)功能點(diǎn)，到底是多少個(gè)應(yīng)用?？蛻粢矡o法確定。
第五組數(shù)據(jù)，某制造企業(yè)SRM（供應(yīng)商關(guān)系管理系統(tǒng)），拆分成了四大功能模塊，這四大功能模塊給它分拆成了47個(gè)微服務(wù)。
第六組數(shù)據(jù)，某汽車零配件制造企業(yè)，第一代的車聯(lián)網(wǎng)有5個(gè)應(yīng)用，總共分拆成38個(gè)微服務(wù)。38個(gè)微服務(wù)所開發(fā)出來的程序，卻只能支撐3萬臺(tái)注冊(cè)的汽車。一般按照1:10的并發(fā)經(jīng)驗(yàn)值，意味著它無法實(shí)現(xiàn)3000臺(tái)汽車同時(shí)并發(fā)的需求。而現(xiàn)在國(guó)內(nèi)的大部分車企目標(biāo)，都是在幾百萬到一千萬臺(tái)車的注冊(cè)需求。這意味著，這個(gè)車聯(lián)網(wǎng)平臺(tái)，剛剛開發(fā)出來，就面臨全新的改造壓力。
有了上面六組數(shù)據(jù)，我們不禁要問：這里面的應(yīng)用，都是怎么數(shù)的。有的是2萬個(gè)，有的只有區(qū)區(qū)17個(gè)，差別如此之大？
這些數(shù)據(jù)背后的潛臺(tái)詞，都是跟軟件架構(gòu)有關(guān)系。如果把一個(gè)一個(gè)的微服務(wù)就叫一個(gè)應(yīng)用，那不能說錯(cuò)；要把一個(gè)大的一個(gè)應(yīng)用的集合叫一個(gè)應(yīng)用，也是可以的。像SAP的ERP這樣大的系統(tǒng)里面，包括了那么多的子模塊，叫一個(gè)應(yīng)用也可以。如果要把整個(gè)ERP把它拆成比如說財(cái)務(wù)管理、人事管理等應(yīng)用，甚至財(cái)務(wù)管理繼續(xù)拆下去到應(yīng)用子模塊，都可以。也許一個(gè)ERP可能會(huì)分拆成100個(gè)應(yīng)用，不是不可能的。
銀行是2萬多個(gè)，制造業(yè)好像才幾十、幾百，最多的一家也就數(shù)千個(gè)。為什么？因?yàn)殂y行的IT成熟度非常高，而制造業(yè)的應(yīng)用場(chǎng)景則非常復(fù)雜系。那么走向數(shù)字化的制造企業(yè)，到底應(yīng)該有多少個(gè)應(yīng)用？未來制造企業(yè)里面的IT到底需要什么樣的人員規(guī)模來支撐？
這些話題，都涉及到應(yīng)用架構(gòu)，以及工業(yè)軟件整個(gè)研發(fā)流程和研發(fā)體系問題。
大規(guī)模軟件開發(fā)的挑戰(zhàn)
軟件開發(fā)和流程制造的類比性非常大，它們都是一個(gè)流水線。而軟件開發(fā)，則與軟件技術(shù)架構(gòu)密切相關(guān)。
比較成熟的軟件開發(fā)，不管是哪個(gè)行業(yè)，大規(guī)模軟件開發(fā)的過程都會(huì)面臨許多許多的挑戰(zhàn)。例如，很多客戶提出自動(dòng)化測(cè)試的需求，但這就意味著好多運(yùn)維工具的使用。
灰度發(fā)布，也是一個(gè)重要的概念，尤其在當(dāng)今基于云技術(shù)軟件開發(fā)的一個(gè)重要需求。一個(gè)應(yīng)用開發(fā)的完整生命周期過程中，需要進(jìn)行功能測(cè)試和性能測(cè)試。在企業(yè)開發(fā)環(huán)境里測(cè)試，通常都是功能性測(cè)試；進(jìn)行壓力測(cè)試包括用戶體驗(yàn)測(cè)試，那就必須要有一些用戶真實(shí)的體驗(yàn)?；叶劝l(fā)布則是使得測(cè)試工作以分群的、分區(qū)域的、分功能的階梯式的開展，以便于迭代。
工業(yè)互聯(lián)網(wǎng)應(yīng)用開發(fā)，不能把所用功能一口氣一下子全部發(fā)布出去，否則會(huì)對(duì)企業(yè)沖擊會(huì)過大。通常在軟件開發(fā)過程之中，它會(huì)分階段，比如選特定一些客戶群，或者特定一些功能，在一些特定的時(shí)間點(diǎn)做一些發(fā)布。
另外一個(gè)重要的概念是多云管理。將來工業(yè)互聯(lián)網(wǎng)有可能會(huì)在后臺(tái)會(huì)有多個(gè)云，包括多個(gè)私有云、多個(gè)公有云，還有一些數(shù)據(jù)和應(yīng)用是傳統(tǒng)非云的環(huán)境里。在軟件開發(fā)過程中，這些問題都需要兼顧。許多場(chǎng)合下，各種應(yīng)用軟件以及中間件軟件有數(shù)百甚至上萬個(gè)，每一個(gè)軟件本身在編程過程之中都會(huì)有一個(gè)機(jī)制，這個(gè)機(jī)制會(huì)吐出一些信息來，這個(gè)信息就叫做日志（LOG）。如數(shù)據(jù)庫(kù)，IBM DB2與Oracel各自有不同的日志信息；就PLM而言，SAP和西門子的日志也不可能一樣。要對(duì)整個(gè)軟件的運(yùn)行狀況進(jìn)行分析，綜合了解它的狀態(tài)的時(shí)候，就必須對(duì)各個(gè)軟件的日志要很清楚。當(dāng)軟件數(shù)量大到一定的程度時(shí)，就不可能做到人工處理了，必須要有軟件，對(duì)這些日志信息自動(dòng)進(jìn)行分析，輔助運(yùn)維人員的運(yùn)維工作。
這些都是在軟件開發(fā)生命周期中遇到的諸多挑戰(zhàn)。如果將更多的包括人員、組織架構(gòu)等問題考慮進(jìn)去，則更為復(fù)雜。
以上都是大規(guī)模軟件開發(fā)的挑戰(zhàn)。
軟件技術(shù)架構(gòu)的三次大演進(jìn)
軟件技術(shù)架構(gòu)在不斷進(jìn)化。從單體應(yīng)用到SOA架構(gòu)，再到當(dāng)下的微服務(wù)架構(gòu)。
早年的軟件開發(fā)都是單體架構(gòu)monothetic+UI。這個(gè)架構(gòu)特點(diǎn)是后臺(tái)有一個(gè)Database，前面有一個(gè)用戶界面UI，把后臺(tái)的Database的一些數(shù)據(jù)通過UI以某種形式展現(xiàn)。此時(shí)，軟件架構(gòu)層次比較簡(jiǎn)單，它只有兩層。但單體架構(gòu)的缺點(diǎn)很顯然，它的復(fù)雜性逐步提高，部署的速度越來越慢，等等。一個(gè)單體應(yīng)用系統(tǒng)，從操作系統(tǒng)，到上面的數(shù)據(jù)庫(kù)、運(yùn)行時(shí)環(huán)境，再有一些配套的庫(kù)，再到應(yīng)用軟件，一般情況都得要兩三個(gè)月才能部署。所以大型單體架構(gòu)的應(yīng)用軟件的部署已經(jīng)變得越來越復(fù)雜，而且無法按需伸縮。
關(guān)于伸縮性，舉個(gè)例子，拿一個(gè)十萬人企業(yè)為例，電子郵件系統(tǒng)通常都會(huì)要十幾或幾百甚至上千臺(tái)的X86的機(jī)器作為服務(wù)器在后面跑，但是夜間這些服務(wù)器基本都屬于空轉(zhuǎn)狀態(tài)。如何讓這些設(shè)備更加有效的運(yùn)行，能否晚上只留十幾臺(tái)二十臺(tái)保證一些基本的服務(wù)在運(yùn)行，然后大量的計(jì)算能力全部都是休眠狀態(tài)。等到上班之后，再把資源喚醒，逐步伸展出去。云架構(gòu)的優(yōu)勢(shì)顯而易見了。這種需求，單體架構(gòu)是無法做到的，它必須是用一個(gè)更先進(jìn)的技術(shù)來做就是云架構(gòu)。
SOA架構(gòu)
大概十年前，新的架構(gòu)SOA被提出來。SOA架構(gòu):數(shù)據(jù)+用戶界面+公共服務(wù)，這是面向服務(wù)的架構(gòu)。在數(shù)據(jù)庫(kù)和用戶界面之間加了一堆公共的服務(wù)，把這種公共的服務(wù)用企業(yè)數(shù)據(jù)總線串起來。在制造業(yè)中，OPC UA標(biāo)準(zhǔn)體系，可把所有工業(yè)產(chǎn)品、工業(yè)裝備連接進(jìn)來。在軟件體系架構(gòu)里面（即數(shù)字世界里）它就是一個(gè)服務(wù)，開放出來的接口有多少個(gè)就可以有多少個(gè)服務(wù)。所以在軟件世界里，無論一個(gè)設(shè)備還是一個(gè)軟件服務(wù)，對(duì)用戶而言，沒有區(qū)別。
SOA架構(gòu)主要特點(diǎn)就是松耦合了服務(wù)的提供者和服務(wù)的消費(fèi)者之間的關(guān)聯(lián)，應(yīng)用架構(gòu)的靈活性大大提升了。但是SOA架構(gòu)沒有考慮服務(wù)大小。小的只有幾兆甚至幾百K，大的有幾個(gè)G的，甚至100G以上，也都叫做服務(wù)。前面單體架構(gòu)里面談到所謂“伸縮”問題，又出現(xiàn)了。
架構(gòu)又需要改進(jìn)，這就是今天提到的微服務(wù)架構(gòu)。
微服務(wù)來了
微服務(wù)，是一種全新的服務(wù)架構(gòu)。它是軟件開發(fā)的一種方法，這里面會(huì)涉及到很多的概念。幾年前互聯(lián)網(wǎng)公司提出一個(gè)叫SQUAD概念，它是伴隨著微服務(wù)架構(gòu)的軟件開發(fā)的一種人員組織形式。通俗地講，Squad就是賦予一定職能的小分隊(duì)，具有一定的獨(dú)立性。這個(gè)小組其很像軍隊(duì)的一個(gè)班，可以作為基本單位去執(zhí)行任務(wù)，而且squad里也有管理制度。這個(gè)概念其實(shí)到了軟件里面也是一樣，通常會(huì)建議10-12個(gè)人組成一個(gè)Squad，以一定的相對(duì)獨(dú)立性來開發(fā)，然后相互之間再進(jìn)行編排、組合。
最近提的多反而是Agile敏捷開發(fā)，與瀑布式相對(duì)應(yīng)。這個(gè)概念不新鮮。
瀑布式軟件開發(fā)是傳統(tǒng)的開發(fā)方式。舉個(gè)例子，供應(yīng)商管理系統(tǒng)SRM，應(yīng)該長(zhǎng)成什么樣子，需要做大量的調(diào)研，形成規(guī)格書。然后封存起來不能再改了，開發(fā)團(tuán)隊(duì)按照這個(gè)規(guī)格書再進(jìn)行軟件工程。軟件工程之后，再需要幾個(gè)月時(shí)間進(jìn)行測(cè)試，測(cè)試完了進(jìn)行發(fā)布，發(fā)布完了之后，這個(gè)版本就要維持一年，甚至兩年，甚至三年。一個(gè)版本通常它會(huì)有一個(gè)周期，有的是五年，有的六年，但一般不會(huì)超過8年。這就是一個(gè)典型的叫瀑布式的，它就像水似的從上往下倒，是不可逆的，只能順序推進(jìn)。
這種方式開發(fā)出來的軟件推向市場(chǎng)，不太容易適應(yīng)快速變化。后來出現(xiàn)了一個(gè)迭代式開發(fā)方式，也就是敏捷開發(fā)，整個(gè)研發(fā)周期發(fā)生變化，開發(fā)的組織形式也發(fā)生變化。
微服務(wù)開發(fā)正是從敏捷開發(fā)的方式演化而來。這里，現(xiàn)在又出了一個(gè)新的詞，叫CQRS（Command Query Responsibilities Segaration）。中心思想是，所有的功能，分成兩類：一類是發(fā)號(hào)施令的Command型，這是一個(gè)大類；一類是Query查詢型的，到后臺(tái)的分布式數(shù)據(jù)里去把所需要的信息查找出來。
微服務(wù)開發(fā)要求軟件架構(gòu)設(shè)計(jì)時(shí)，要滿足CQRS這樣的設(shè)計(jì)原則。每個(gè)微服務(wù)都可以獨(dú)立運(yùn)行，可以獨(dú)立編排。就像導(dǎo)演一樣，每個(gè)演員演好自己的角色，導(dǎo)演把這些角色編排好，演繹出一個(gè)精彩的故事。一個(gè)系統(tǒng)就像是一個(gè)劇，有眾多的微服務(wù)組成，提供更加完整的服務(wù)能力。這個(gè)系統(tǒng)可以就是我們?cè)瓉碇v到的一個(gè)應(yīng)用軟件，一個(gè)具有豐富功能應(yīng)用軟件。
一個(gè)功能點(diǎn)可能就是一個(gè)微服務(wù)，但也可能需要調(diào)用幾個(gè)微服務(wù)來組合完成。這就是微服務(wù)的理念。
微服務(wù)的大小與容器
在微服務(wù)架構(gòu)中，一個(gè)微服務(wù)的大小雖然沒有一個(gè)固定的標(biāo)準(zhǔn)值，，但一般在幾十兆到100M以內(nèi)。分拆得太小了，微服務(wù)的治理的復(fù)雜度加大；太大了，違背微服務(wù)的對(duì)資源占用的靈活伸縮初衷，也不便于問題隔離。
微服務(wù)的部署，往往就是一個(gè)可執(zhí)行程序（image）部署在那里。啟動(dòng)時(shí)，該微服務(wù)會(huì)調(diào)入容器（一個(gè)運(yùn)行環(huán)境）中，當(dāng)然就會(huì)占用計(jì)算資源，如存儲(chǔ)、網(wǎng)絡(luò)和通訊、CPU資源。使用完畢后，這些資源會(huì)被釋放回去。
那么容器又是什么？技術(shù)上講，是給容器里的程序運(yùn)行時(shí)涉及到的指令的解釋器。拿一個(gè)共享辦公室來類比。共享辦公室提供一個(gè)辦公環(huán)境，所有的辦公室既不能一概都是100平方米；或者一概都是1000平方米，需要有不同大小的房間以滿足不同體量的公司進(jìn)駐辦公。但每間辦公室必須有一些基礎(chǔ)，如水、電、氣或者WiFi，等等。一個(gè)公司進(jìn)來，拎包入住，需要的服務(wù)一應(yīng)俱全。用多長(zhǎng)一段時(shí)間付多少錢，用完了可以隨時(shí)走人，辦公空間回收。這個(gè)環(huán)境，就可以類比成微服務(wù)所需要的容器。
開發(fā)運(yùn)維一體化流程DevOps
“開發(fā)運(yùn)維DevOps”一體化流程，已經(jīng)成為當(dāng)前軟件交付最重要的一種形式。它是一個(gè)流水線。
首先是程序員編寫程序。
其次是源代碼的管理。在一些成熟的軟件開發(fā)組織里，對(duì)源碼的管理是非常的嚴(yán)格的。
下一步是build，對(duì)做OT的人可能對(duì)這個(gè)術(shù)語有點(diǎn)陌生，對(duì)IT人員，這個(gè)術(shù)語就耳熟能詳了，就是把軟件的源代碼要把它編成一個(gè)可執(zhí)行代碼，如exe。
然后打包這個(gè)過程叫pagage。除了源代碼編譯之后的軟件本身，還包括它的一些依賴程序。單體架構(gòu)的應(yīng)用是一定需要打一個(gè)很大的包；而在云里，打包就小很多。
打完包之后再去部署deploy，部署完了就開始測(cè)試.
測(cè)試會(huì)有功能測(cè)試和性能測(cè)試。通常功能測(cè)試的難度會(huì)相對(duì)小一點(diǎn)，在測(cè)試環(huán)境里面測(cè)試;但是要進(jìn)行性能測(cè)試的時(shí)候，必須有大量實(shí)際數(shù)據(jù)，仿真的、模擬的數(shù)據(jù)都沒有不能最終說明問題，必須要有實(shí)際數(shù)據(jù)，壓力測(cè)試才更加令人信服。還有用戶體驗(yàn)也需要目標(biāo)用戶的參與，體驗(yàn)好壞才更加現(xiàn)實(shí)。
測(cè)試完了之后開始進(jìn)行灰度發(fā)布?；叶劝l(fā)布之后發(fā)現(xiàn)問題，再修改程序，進(jìn)入迭代過程，迭代完了之后才會(huì)進(jìn)行大規(guī)模、全面的部署。那就是上生產(chǎn)線了。
這是一個(gè)完整的生命周期。
那么，這個(gè)過程之中，人員怎么配備，比如說有架構(gòu)師，有測(cè)試工程師，產(chǎn)品經(jīng)理或者叫Offering Manager，等等。互聯(lián)網(wǎng)公司OM的身價(jià)一般都非常高。因?yàn)镺M的責(zé)任會(huì)比過去的項(xiàng)目經(jīng)理責(zé)任要大。后續(xù)還有運(yùn)維工作。軟件系統(tǒng)投入使用以后，怎么進(jìn)行管理？我們借用一個(gè)概念OSS，叫Operation & support services。
整個(gè)管道pipeline，形成一個(gè)完整的概念DevOps。
DevOps需要大量的工具
目前,很多企業(yè)聽上去都有DevOps，但成熟度參差不齊。運(yùn)維體系、工具、流程有些缺乏。很多大型企業(yè)，IT人員規(guī)模達(dá)到好幾千人，但運(yùn)維體系不夠清晰，甚至干脆就缺乏體系。文化和組織配套完全跟不上，光有幾個(gè)工具，僅此而已。
Continuous DevOps
進(jìn)一步探究，就是持續(xù)性的概念。也就是Continuous DevOps。持續(xù)性，包括持續(xù)集成、持續(xù)部署、持續(xù)測(cè)試等。這是所有云平臺(tái)都需要具備的能力。
顯然Devops，已經(jīng)超越了開發(fā)流程。它是工具集，但它更是一種組織，是一種軟件文化。這是工業(yè)互聯(lián)網(wǎng)的開發(fā)過程中，技術(shù)之外容易避不開的大坑。
小結(jié)
DevOps是一個(gè)漫長(zhǎng)的征程，但它為工業(yè)互聯(lián)網(wǎng)滿足制造業(yè)需求的軟件開發(fā)提供了很好的路徑。而微服務(wù)架構(gòu)也正在成為一種非常流行的工業(yè)軟件開發(fā)方法。理解微服務(wù)和DevOps架構(gòu)的開發(fā)方式，會(huì)使得工業(yè)應(yīng)用能夠快速形成服務(wù)能力，不斷迭代更新，從而以IT強(qiáng)大支撐和服務(wù)能力，支持更多的OT應(yīng)用，使得工業(yè)互聯(lián)網(wǎng)能夠更好落地。（來源：知識(shí)自動(dòng)化 文/顧世山 編選：電子商務(wù)研究中心）
