從六組數(shù)據(jù)說起

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

第一個數(shù)據(jù)，某銀行有2萬多個應(yīng)用，其中有1萬個左右的應(yīng)用是基于J2EE，運行在IBM的中間件軟件WAS系統(tǒng)（WebSphereApplicationServer）。

第二個就是某個電信行業(yè)的OEM廠商，其內(nèi)部IT管理應(yīng)用大約有2000個左右。

第三個是某鋼鐵集團企業(yè)。它的應(yīng)用從研發(fā)到現(xiàn)場制造再到企業(yè)運營管理在內(nèi)，也包括工業(yè)互聯(lián)網(wǎng)，應(yīng)用有500個左右。

第四個是某車聯(lián)網(wǎng)平臺。該車聯(lián)網(wǎng)平臺已經(jīng)建設(shè)有17個應(yīng)用。但在2019年的新需求，則是按照功能點提出來的，加在一起有700多個新的功能點。這些需求撲面而來，根本無法來得及開發(fā)。而這700多個功能點，到底是多少個應(yīng)用?？蛻粢矡o法確定。

第五組數(shù)據(jù)，某制造企業(yè)SRM（供應(yīng)商關(guān)系管理系統(tǒng)），拆分成了四大功能模塊，這四大功能模塊給它分拆成了47個微服務(wù)。

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

有了上面六組數(shù)據(jù)，我們不禁要問：這里面的應(yīng)用，都是怎么數(shù)的。有的是2萬個，有的只有區(qū)區(qū)17個，差別如此之大？

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

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

這些話題，都涉及到應(yīng)用架構(gòu)，以及工業(yè)軟件整個研發(fā)流程和研發(fā)體系問題。

大規(guī)模軟件開發(fā)的挑戰(zhàn)

軟件開發(fā)和流程制造的類比性非常大，它們都是一個流水線。而軟件開發(fā)，則與軟件技術(shù)架構(gòu)密切相關(guān)。

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

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

工業(yè)互聯(lián)網(wǎng)應(yīng)用開發(fā)，不能把所用功能一口氣一下子全部發(fā)布出去，否則會對企業(yè)沖擊會過大。通常在軟件開發(fā)過程之中，它會分階段，比如選特定一些客戶群，或者特定一些功能，在一些特定的時間點做一些發(fā)布。

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

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

以上都是大規(guī)模軟件開發(fā)的挑戰(zhàn)。

軟件技術(shù)架構(gòu)的三次大演進

軟件技術(shù)架構(gòu)在不斷進化。從單體應(yīng)用到SOA架構(gòu)，再到當(dāng)下的微服務(wù)架構(gòu)。

圖1:軟件架構(gòu)的進化

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

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

圖2:SOA架構(gòu)

大概十年前，新的架構(gòu)SOA被提出來。SOA架構(gòu):數(shù)據(jù)+用戶界面+公共服務(wù)，這是面向服務(wù)的架構(gòu)。在數(shù)據(jù)庫和用戶界面之間加了一堆公共的服務(wù)，把這種公共的服務(wù)用企業(yè)數(shù)據(jù)總線串起來。在制造業(yè)中，OPCUA標(biāo)準(zhǔn)體系，可把所有工業(yè)產(chǎn)品、工業(yè)裝備連接進來。在軟件體系架構(gòu)里面（即數(shù)字世界里）它就是一個服務(wù)，開放出來的接口有多少個就可以有多少個服務(wù)。所以在軟件世界里，無論一個設(shè)備還是一個軟件服務(wù)，對用戶而言，沒有區(qū)別。

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

架構(gòu)又需要改進，這就是今天提到的微服務(wù)架構(gòu)。

微服務(wù)來了

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

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

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

圖3:瀑布式開發(fā)

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

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

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

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

微服務(wù)的大小與容器

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

微服務(wù)的部署，往往就是一個可執(zhí)行程序（image）部署在那里。啟動時，該微服務(wù)會調(diào)入容器（一個運行環(huán)境）中，當(dāng)然就會占用計算資源，如存儲、網(wǎng)絡(luò)和通訊、CPU資源。使用完畢后，這些資源會被釋放回去。

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

開發(fā)運維一體化流程DevOps

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

圖4:DevOps的流程

首先是程序員編寫程序。

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

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

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

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

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

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

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

那么，這個過程之中，人員怎么配備，比如說有架構(gòu)師，有測試工程師，產(chǎn)品經(jīng)理或者叫OfferingManager，等等?；ヂ?lián)網(wǎng)公司OM的身價一般都非常高。因為OM的責(zé)任會比過去的項目經(jīng)理責(zé)任要大。后續(xù)還有運維工作。軟件系統(tǒng)投入使用以后，怎么進行管理？我們借用一個概念OSS，叫Operation&supportservices。

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

圖5:DevOps需要大量的工具

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

圖6:ContinuousDevOps

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

顯然Devops，已經(jīng)超越了開發(fā)流程。它是工具集，但它更是一種組織，是一種軟件文化。這是工業(yè)互聯(lián)網(wǎng)的開發(fā)過程中，技術(shù)之外容易避不開的大坑。

小結(jié)

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

聲明：本文為轉(zhuǎn)載類文章，如涉及版權(quán)問題，請及時聯(lián)系我們刪除（QQ: 2737591964），不便之處，敬請諒解！