本文由知識自動化（zhishipai）授權轉發

作者： 顧世山

來源：知識自動化

DevOps就是開發Dev和運維Ops集成在一起的平臺。隨著工業互聯網的崛起， DevOps和微服務恰逢其時。它重塑軟件開發的能力，正在引發廣泛的關注。

隨著工業APP的普及，企業應用變成新的熱點。那么一個企業到底需要有多少個“應用”？從六組案例說起。

第一個數據，某銀行有2萬多個應用，其中有1萬個左右的應用是基于J2EE，運行在IBM的中間件軟件WAS系統（WebSphere Application Server）。

第二個就是某個電信行業的OEM廠商，其內部IT管理應用大約有2000個左右。

第三個是某鋼鐵集團企業。它的應用從研發到現場制造再到企業運營管理在內，也包括工業互聯網，應用有500個左右。

第四個是某車聯網平臺。該車聯網平臺已經建設有17個應用。但在2019年的新需求，則是按照功能點提出來的，加在一起有700多個新的功能點。這些需求撲面而來，根本無法來得及開發。而這700多個功能點，到底是多少個應用。客戶也無法確定。

第五組數據，某制造企業SRM（供應商關系管理系統），拆分成了四大功能模塊，這四大功能模塊給它分拆成了47個微服務。

第六組數據，某汽車零配件制造企業，第一代的車聯網有5個應用，總共分拆成38個微服務。38個微服務所開發出來的程序，卻只能支撐3萬臺注冊的汽車。一般按照1:10的并發經驗值，意味著它無法實現3000臺汽車同時并發的需求。而現在國內的大部分車企目標，都是在幾百萬到一千萬臺車的注冊需求。這意味著，這個車聯網平臺，剛剛開發出來，就面臨全新的改造壓力。

這些數據背后的潛臺詞，都是跟軟件架構有關系。如果把一個一個的微服務就叫一個應用，那不能說錯；要把一個大的一個應用的集合叫一個應用，也是可以的。像SAP的ERP這樣大的系統里面，包括了那么多的子模塊，叫一個應用也可以。如果要把整個ERP把它拆成比如說財務管理、人事管理等應用，甚至財務管理繼續拆下去到應用子模塊，都可以。也許一個ERP可能會分拆成100個應用，不是不可能的。

銀行是2萬多個，制造業好像才幾十、幾百，最多的一家也就數千個。為什么？因為銀行的IT成熟度非常高，而制造業的應用場景則非常復雜系。那么走向數字化的制造企業，到底應該有多少個應用？未來制造企業里面的IT到底需要什么樣的人員規模來支撐？

這些話題，都涉及到應用架構，以及工業軟件整個研發流程和研發體系問題。

軟件開發和流程制造的類比性非常大，它們都是一個流水線。而軟件開發，則與軟件技術架構密切相關。

比較成熟的軟件開發，不管是哪個行業，大規模軟件開發的過程都會面臨許多許多的挑戰。例如，很多客戶提出自動化測試的需求，但這就意味著好多運維工具的使用。

灰度發布，也是一個重要的概念，尤其在當今基于云技術軟件開發的一個重要需求。一個應用開發的完整生命周期過程中，需要進行功能測試和性能測試。在企業開發環境里測試，通常都是功能性測試；進行壓力測試包括用戶體驗測試，那就必須要有一些用戶真實的體驗。灰度發布則是使得測試工作以分群的、分區域的、分功能的階梯式的開展，以便于迭代。 

另外一個重要的概念是多云管理。將來工業互聯網有可能會在后臺會有多個云，包括多個私有云、多個公有云，還有一些數據和應用是傳統非云的環境里。在軟件開發過程中，這些問題都需要兼顧。許多場合下，各種應用軟件以及中間件軟件有數百甚至上萬個，每一個軟件本身在編程過程之中都會有一個機制，這個機制會吐出一些信息來，這個信息就叫做日志（LOG）。如數據庫，IBM DB2與Oracel各自有不同的日志信息；就PLM而言，SAP和西門子的日志也不可能一樣。要對整個軟件的運行狀況進行分析，綜合了解它的狀態的時候，就必須對各個軟件的日志要很清楚。當軟件數量大到一定的程度時，就不可能做到人工處理了，必須要有軟件，對這些日志信息自動進行分析，輔助運維人員的運維工作。

這些都是在軟件開發生命周期中遇到的諸多挑戰。如果將更多的包括人員、組織架構等問題考慮進去，則更為復雜。

以上都是大規模軟件開發的挑戰。

軟件技術架構在不斷進化。從單體應用到SOA架構，再到當下的微服務架構。

圖1:軟件架構的進化

早年的軟件開發都是單體架構monothetic+UI。這個架構特點是后臺有一個Database，前面有一個用戶界面UI，把后臺的Database的一些數據通過UI以某種形式展現。此時，軟件架構層次比較簡單，它只有兩層。但單體架構的缺點很顯然，它的復雜性逐步提高，部署的速度越來越慢，等等。一個單體應用系統，從操作系統，到上面的數據庫、運行時環境，再有一些配套的庫，再到應用軟件，一般情況都得要兩三個月才能部署。所以大型單體架構的應用軟件的部署已經變得越來越復雜，而且無法按需伸縮。

關于伸縮性，舉個例子，拿一個十萬人企業為例，電子郵件系統通常都會要十幾或幾百甚至上千臺的X86的機器作為服務器在后面跑，但是夜間這些服務器基本都屬于空轉狀態。如何讓這些設備更加有效的運行，能否晚上只留十幾臺二十臺保證一些基本的服務在運行，然后大量的計算能力全部都是休眠狀態。等到上班之后，再把資源喚醒，逐步伸展出去。云架構的優勢顯而易見了。這種需求，單體架構是無法做到的，它必須是用一個更先進的技術來做就是云架構。

圖2:SOA架構

大概十年前，新的架構SOA被提出來。SOA架構:數據+用戶界面+公共服務，這是面向服務的架構。在數據庫和用戶界面之間加了一堆公共的服務，把這種公共的服務用企業數據總線串起來。在制造業中，OPC UA標準體系，可把所有工業產品、工業裝備連接進來。在軟件體系架構里面（即數字世界里）它就是一個服務，開放出來的接口有多少個就可以有多少個服務。所以在軟件世界里，無論一個設備還是一個軟件服務，對用戶而言，沒有區別。

SOA架構主要特點就是松耦合了服務的提供者和服務的消費者之間的關聯，應用架構的靈活性大大提升了。但是SOA架構沒有考慮服務大小。小的只有幾兆甚至幾百K，大的有幾個G的，甚至100G以上，也都叫做服務。前面單體架構里面談到所謂“伸縮”問題，又出現了。

架構又需要改進，這就是今天提到的微服務架構。

微服務，是一種全新的服務架構。它是軟件開發的一種方法，這里面會涉及到很多的概念。幾年前互聯網公司提出一個叫SQUAD概念，它是伴隨著微服務架構的軟件開發的一種人員組織形式。通俗地講，Squad就是賦予一定職能的小分隊，具有一定的獨立性。這個小組其很像軍隊的一個班，可以作為基本單位去執行任務，而且squad里也有管理制度。這個概念其實到了軟件里面也是一樣，通常會建議10-12個人組成一個Squad，以一定的相對獨立性來開發，然后相互之間再進行編排、組合。

最近提的多反而是Agile敏捷開發，與瀑布式相對應。這個概念不新鮮。

瀑布式軟件開發是傳統的開發方式。舉個例子，供應商管理系統SRM，應該長成什么樣子，需要做大量的調研，形成規格書。然后封存起來不能再改了，開發團隊按照這個規格書再進行軟件工程。軟件工程之后，再需要幾個月時間進行測試，測試完了進行發布，發布完了之后，這個版本就要維持一年，甚至兩年，甚至三年。一個版本通常它會有一個周期，有的是五年，有的六年，但一般不會超過8年。這就是一個典型的叫瀑布式的，它就像水似的從上往下倒，是不可逆的，只能順序推進。

圖3:瀑布式開發

這種方式開發出來的軟件推向市場，不太容易適應快速變化。后來出現了一個迭代式開發方式，也就是敏捷開發，整個研發周期發生變化，開發的組織形式也發生變化。

微服務開發正是從敏捷開發的方式演化而來。這里，現在又出了一個新的詞，叫CQRS（Command Query Responsibilities Segaration）。中心思想是，所有的功能，分成兩類：一類是發號施令的Command型，這是一個大類；一類是Query查詢型的，到后臺的分布式數據里去把所需要的信息查找出來。

微服務開發要求軟件架構設計時，要滿足CQRS這樣的設計原則。每個微服務都可以獨立運行，可以獨立編排。就像導演一樣，每個演員演好自己的角色，導演把這些角色編排好，演繹出一個精彩的故事。一個系統就像是一個劇，有眾多的微服務組成，提供更加完整的服務能力。這個系統可以就是我們原來講到的一個應用軟件，一個具有豐富功能應用軟件。

一個功能點可能就是一個微服務，但也可能需要調用幾個微服務來組合完成。這就是微服務的理念。

在微服務架構中，一個微服務的大小雖然沒有一個固定的標準值，，但一般在幾十兆到100M以內。分拆得太小了，微服務的治理的復雜度加大；太大了，違背微服務的對資源占用的靈活伸縮初衷，也不便于問題隔離。

微服務的部署，往往就是一個可執行程序（image）部署在那里。啟動時，該微服務會調入容器（一個運行環境）中，當然就會占用計算資源，如存儲、網絡和通訊、CPU資源。使用完畢后，這些資源會被釋放回去。

那么容器又是什么？技術上講，是給容器里的程序運行時涉及到的指令的解釋器。拿一個共享辦公室來類比。共享辦公室提供一個辦公環境，所有的辦公室既不能一概都是100平方米；或者一概都是1000平方米，需要有不同大小的房間以滿足不同體量的公司進駐辦公。但每間辦公室必須有一些基礎，如水、電、氣或者WiFi，等等。一個公司進來，拎包入住，需要的服務一應俱全。用多長一段時間付多少錢，用完了可以隨時走人，辦公空間回收。這個環境，就可以類比成微服務所需要的容器。

“開發運維DevOps”一體化流程，已經成為當前軟件交付最重要的一種形式。它是一個流水線。

圖4:DevOps的流程

首先是程序員編寫程序。

其次是源代碼的管理。在一些成熟的軟件開發組織里，對源碼的管理是非常的嚴格的。

下一步是build，對做OT的人可能對這個術語有點陌生，對IT人員，這個術語就耳熟能詳了，就是把軟件的源代碼要把它編成一個可執行代碼，如exe。

然后打包這個過程叫pagage。除了源代碼編譯之后的軟件本身，還包括它的一些依賴程序。單體架構的應用是一定需要打一個很大的包；而在云里，打包就小很多。

打完包之后再去部署deploy，部署完了就開始測試.

測試會有功能測試和性能測試。通常功能測試的難度會相對小一點，在測試環境里面測試;但是要進行性能測試的時候，必須有大量實際數據，仿真的、模擬的數據都沒有不能最終說明問題，必須要有實際數據，壓力測試才更加令人信服。還有用戶體驗也需要目標用戶的參與，體驗好壞才更加現實。 

測試完了之后開始進行灰度發布。灰度發布之后發現問題，再修改程序，進入迭代過程，迭代完了之后才會進行大規模、全面的部署。那就是上生產線了。

這是一個完整的生命周期。

那么，這個過程之中，人員怎么配備，比如說有架構師，有測試工程師，產品經理或者叫Offering Manager，等等。互聯網公司OM的身價一般都非常高。因為OM的責任會比過去的項目經理責任要大。后續還有運維工作。軟件系統投入使用以后，怎么進行管理？我們借用一個概念OSS，叫Operation & support services。

整個管道pipeline，形成一個完整的概念DevOps。

圖5:DevOps需要大量的工具

目前,很多企業聽上去都有DevOps，但成熟度參差不齊。運維體系、工具、流程有些缺乏。很多大型企業，IT人員規模達到好幾千人，但運維體系不夠清晰，甚至干脆就缺乏體系。文化和組織配套完全跟不上，光有幾個工具，僅此而已。

圖6:Continuous DevOps

進一步探究，就是持續性的概念。也就是Continuous DevOps。持續性，包括持續集成、持續部署、持續測試等。這是所有云平臺都需要具備的能力。

顯然Devops，已經超越了開發流程。它是工具集，但它更是一種組織，是一種軟件文化。這是工業互聯網的開發過程中，技術之外容易避不開的大坑。

DevOps是一個漫長的征程，但它為工業互聯網滿足制造業需求的軟件開發提供了很好的路徑。而微服務架構也正在成為一種非常流行的工業軟件開發方法。理解微服務和DevOps架構的開發方式，會使得工業應用能夠快速形成服務能力，不斷迭代更新，從而以IT強大支撐和服務能力，支持更多的OT應用，使得工業互聯網能夠更好落地。

（鳴謝南山工業書院的各位同事的協助，尤其感謝新華三杜立征的整理。）

作者簡介

作 者

顧世山：南山工業書院研究員，26年IT從業經驗，熟悉大規模軟件開發體系，車聯網高級顧問

編 審

林雪萍：南山工業書院發起人，北京聯訊動力咨詢公司總經理