中國(guó)移動(dòng) "磐舟" DevOps平臺(tái)實(shí)踐

本演講分享了中國(guó)移動(dòng)磐舟一體化開(kāi)發(fā)交付平臺(tái)在敏捷研發(fā)、統(tǒng)一制品、開(kāi)源治理、安全掃描、開(kāi)發(fā)環(huán)境、持續(xù)交付、GitOps 等方面的建設(shè)實(shí)施以及效果提升，并與大家一起探討低代碼與 Serverless 的未來(lái)演進(jìn)。目前磐舟平臺(tái)已服務(wù) 300 多開(kāi)發(fā)項(xiàng)，近 200 個(gè)代碼倉(cāng)庫(kù)，管理代碼超 2 億行，制品超 50 萬(wàn)，服務(wù)調(diào)用超 3 億，月均部署近萬(wàn)次。在云原生開(kāi)發(fā)方面起到了顯著地引導(dǎo)作用，促進(jìn)了中國(guó)移動(dòng)數(shù)字資產(chǎn)沉淀，提升了整體研發(fā)效能，推動(dòng)了應(yīng)用從 on cloud 向 in cloud 的演進(jìn)。

本文整理自中國(guó)移動(dòng)信息技術(shù)中心 PaaS 架構(gòu)師魏寶輝在 DIVE 全球基礎(chǔ)軟件創(chuàng)新大會(huì) 2022（基礎(chǔ)設(shè)施及架構(gòu)設(shè)計(jì)專(zhuān)場(chǎng)）的演講分享，主題為“中國(guó)移動(dòng)磐舟 DevOps 平臺(tái)實(shí)踐”。

分享主要分三個(gè)部分展開(kāi)：第一部分是磐?DevOps 平臺(tái)的建設(shè)背景及成效；第二部分是磐?DevOps 平臺(tái)在 DevSecOps、Serverless 等方面的云原?實(shí)踐；第三部分是磐?DevOps 平臺(tái)的未來(lái)演進(jìn)?向。

以下是分享實(shí)錄：

最近幾年，云原生已成為一個(gè)非常熱門(mén)的話(huà)題。以容器、微服務(wù)、DevOps 為核心的云原生技術(shù)快速地席卷了整個(gè)互聯(lián)網(wǎng)行業(yè)，此外，傳統(tǒng)行業(yè)也已經(jīng)加入到了云原生的行列之中。為什么要做云原生技術(shù)呢？首先，云原生技術(shù)能夠幫助我們業(yè)務(wù)系統(tǒng)快速地進(jìn)行迭代；其次，它能夠有效地降低企業(yè)在 IT 開(kāi)發(fā)和運(yùn)維方面的成本；最后，它也能夠提高我們企業(yè)業(yè)務(wù)的創(chuàng)新效率和產(chǎn)業(yè)的價(jià)值。

總體來(lái)說(shuō)，我們經(jīng)歷了從傳統(tǒng)服務(wù)器時(shí)代到云化時(shí)代、再到云原生時(shí)代三個(gè)大的階段。我們從最開(kāi)始的小型機(jī)、X86 服務(wù)器演進(jìn)到后來(lái)的云化資源池，再到現(xiàn)在在云化資源池上發(fā)展出來(lái)的云原生技術(shù)底座。

通過(guò)這三個(gè)大的階段，在完成云原生技術(shù)之后，我們發(fā)現(xiàn)：應(yīng)用隨著基礎(chǔ)設(shè)施的下沉，業(yè)務(wù)能力的沉淀復(fù)用，成為了這種軟件模塊化的一些能夠“化整為零”的“積木”。容器將這些“一塊塊的積木”和運(yùn)行環(huán)境打包在一起，形成了一個(gè)個(gè)可以獨(dú)立運(yùn)行的“集裝箱”，這使得運(yùn)維更加容易了。此外，在微服務(wù)時(shí)代，由于要結(jié)合容器，對(duì)應(yīng)用的編排需求就會(huì)更加迫切。通過(guò)組裝“集裝箱”的方式進(jìn)行裝配編排，也使得我們的調(diào)度更加輕松、交付更加迅速了。

云原?技術(shù)底座向上可為中臺(tái)和平臺(tái)能?的統(tǒng)?封裝、靈活調(diào)?提供技術(shù)基礎(chǔ)；向下可調(diào)度、兼容各類(lèi)異構(gòu)“算?”，促進(jìn)資源、要素的?效匯聚、流動(dòng)、共享，具備敏捷、海量和簡(jiǎn)單的特點(diǎn)。它以彈性可擴(kuò)展、?可?、?靈活、強(qiáng)兼容性和低成本的?式將云的價(jià)值最?化，也能讓云把它的價(jià)值輸送到應(yīng)用之中，應(yīng)用通過(guò)云原生的一些開(kāi)發(fā)基礎(chǔ)也能夠把云計(jì)算基礎(chǔ)設(shè)施所帶來(lái)的這種便利能力對(duì)外釋放，形成我們業(yè)務(wù)上的一些應(yīng)用價(jià)值。

在中國(guó)移動(dòng)，云原生技術(shù)底座拓展了我們“連接 + 算?+ 能?”的這種新型信息服務(wù)體系，在我們集團(tuán)內(nèi)外部3的“上云?數(shù)賦智”，以及落實(shí)世界一流“?量?廈” 等方面的戰(zhàn)略布局都成為了一個(gè)有力的幫手，所以說(shuō)在我們中國(guó)移動(dòng)內(nèi)部，云原生技術(shù)底座是數(shù)字化轉(zhuǎn)型的一個(gè)最佳實(shí)踐。

磐基、磐舟是我們自主可控的云原生技術(shù)底座，是以自研為主，打造的共平臺(tái)、共研發(fā)、共能力的云原生技術(shù)體系。

磐基、磐舟在我們內(nèi)部是兩個(gè)大的品牌，它們的云原生技術(shù)底座是統(tǒng)一的。磐基 PaaS 平臺(tái)，磐舟 DevOps 開(kāi)發(fā)平臺(tái)，以統(tǒng)一的技術(shù)棧加快對(duì)技術(shù)組件的收斂、服務(wù)標(biāo)準(zhǔn)構(gòu)建；基于盤(pán)舟一體化開(kāi)發(fā)交付平臺(tái)能夠加強(qiáng)對(duì)開(kāi)發(fā)過(guò)程的端到端管控，包括像需求任務(wù)管理、代碼管理、自動(dòng)化的一些編譯掃描、灰度發(fā)布。在磐基上可以進(jìn)行彈性計(jì)、微服務(wù)治理、多集群管理等等一系列的生產(chǎn)運(yùn)行，兩者融合為開(kāi)發(fā)交付一體化的解決方案，推進(jìn)了應(yīng)用從開(kāi)發(fā)階段生于云上，實(shí)現(xiàn)應(yīng)用的全生命周期的管理，充分釋放云原生的價(jià)值。

通過(guò)我們引入云原生的核心技術(shù)，能夠讓開(kāi)發(fā)更簡(jiǎn)單，讓部署更容易，讓生產(chǎn)運(yùn)轉(zhuǎn)地更加高效，也能夠讓系統(tǒng)的韌性更加強(qiáng)勁。而且通過(guò)這種模式也把我們的 IT 治理體系變得更為全面了。

磐基 PaaS，由統(tǒng)?PaaS?戶(hù)、?產(chǎn)運(yùn)??撐、平臺(tái)管控治理等組成，具備多租戶(hù)管理、多集群管理、統(tǒng)一的鏡像管理、應(yīng)用的可視化管理以及微服務(wù)管理，而且包含了像開(kāi)源軟件管控、智能運(yùn)維管理等一系列的管理方式。能夠極大地減少應(yīng)用開(kāi)發(fā)運(yùn)維的工作，為能力向共享、拉通奠定基礎(chǔ)，提升了資源的利用率。

磐舟平臺(tái)是一個(gè)與磐基平臺(tái)共平臺(tái)、共研發(fā)、共能力的平臺(tái)，它主要側(cè)重在端到端的自動(dòng)化交付流水線(xiàn)，能夠沉淀 IT 軟件資產(chǎn)、核心的代碼掌控，也能夠讓我們的開(kāi)發(fā)過(guò)程更加可控，通過(guò)流水線(xiàn)使我們的開(kāi)發(fā)交付效率再進(jìn)一步提升。

磐舟平臺(tái)是將我們中國(guó)移動(dòng)在開(kāi)發(fā)交付過(guò)程中沉淀的經(jīng)驗(yàn)提煉為最佳平臺(tái)實(shí)踐的能力，為團(tuán)隊(duì)也提供云原生的 DevOps 研發(fā)環(huán)境和 DevOps 的一些落地手段。推進(jìn)業(yè)務(wù)系統(tǒng)規(guī)范、標(biāo)準(zhǔn)、自動(dòng)化地進(jìn)行業(yè)務(wù)交付，通過(guò)統(tǒng)一的規(guī)劃、建設(shè)、運(yùn)營(yíng)實(shí)現(xiàn)統(tǒng)一技術(shù)生態(tài)下的應(yīng)用系統(tǒng)開(kāi)發(fā)，快速提升研發(fā)效率，節(jié)約開(kāi)發(fā)成本，支撐應(yīng)用從開(kāi)發(fā)階段?于云上，融入云里，最終成長(zhǎng)為云原生應(yīng)用，充分釋放云原生的價(jià)值。

磐基、磐舟的規(guī)模落地，推動(dòng)了我們集團(tuán)核心業(yè)務(wù)系統(tǒng)向云原生的轉(zhuǎn)型。我們通過(guò)磐基、磐舟這兩個(gè)有效的手段，推動(dòng)業(yè)務(wù)系統(tǒng)向云原生方向進(jìn)行演進(jìn)，在大規(guī)模的落地過(guò)程中，不斷地強(qiáng)化了全網(wǎng) IT 系統(tǒng)自主開(kāi)發(fā)的過(guò)程，也提高了我們業(yè)務(wù)系統(tǒng)向云原生轉(zhuǎn)型的程度。

磐基 PaaS 平臺(tái)方面，覆蓋了大概 B/O/M 三個(gè)域的 160 多個(gè)核心業(yè)務(wù)系統(tǒng)，建成了大概 200 多個(gè) K8S 集群，節(jié)點(diǎn)規(guī)模數(shù)現(xiàn)在已經(jīng)達(dá)到 1.5 萬(wàn)，容器實(shí)例數(shù)已經(jīng)達(dá)到 10 萬(wàn) +。

磐舟方面，也已經(jīng)覆蓋了 150 多個(gè)核心系統(tǒng)，托管了 2300 多個(gè)代碼倉(cāng)庫(kù)，管理了 5 億多行代碼，制品方面也已經(jīng)提供了 6 億多次的服務(wù)。

應(yīng)用效果方面，像一些核心的計(jì)費(fèi)系統(tǒng)：開(kāi)發(fā)代碼的工作量比以前有了顯著的降低，整個(gè)開(kāi)發(fā)過(guò)程也有了比較好的效率提升，系統(tǒng)中斷時(shí)間也從分鐘級(jí)縮短到了秒級(jí)，系統(tǒng)擴(kuò)容響應(yīng)的時(shí)間也有了較大的提升。在一些省份公司和專(zhuān)業(yè)機(jī)構(gòu)中也有相關(guān)的一些案例。

接下來(lái)，我們看一下磐舟 DevOps 平臺(tái)是如何進(jìn)行云原生實(shí)踐的。

磐基是生產(chǎn)運(yùn)行的過(guò)程，磐舟為業(yè)務(wù)系統(tǒng)的開(kāi)發(fā)提供了開(kāi)發(fā)工具鏈，像需求設(shè)計(jì)、任務(wù)拆分、迭代、發(fā)版管理等等的一些敏捷開(kāi)發(fā)過(guò)程，而且我們實(shí)現(xiàn)了一些 CI/CD 的流水線(xiàn)，在流水線(xiàn)的基礎(chǔ)上也融入了 DevSecOps 的理念。不僅如此，我們也提供了開(kāi)發(fā)環(huán)境，可以支撐應(yīng)用在線(xiàn)拉起、開(kāi)發(fā)測(cè)試、服務(wù)聯(lián)調(diào)。覆蓋了從代碼到運(yùn)行的全過(guò)程。

接下來(lái)也會(huì)隨著 Serverless 的引進(jìn)，進(jìn)一步地抽象平臺(tái)能力，將磐基磐舟向 Serverless 方向做進(jìn)一步的演化。

在 DevSecOps 工具鏈方面，首先不能不提的就是敏捷研發(fā)。但是在我們移動(dòng)內(nèi)部，有很多傳統(tǒng)的瀑布式開(kāi)發(fā)，也有敏捷的開(kāi)發(fā)，還有很多特性的研發(fā)訴求，現(xiàn)有的工具不能很好地支撐。

磐舟是基于我們自主開(kāi)發(fā)的，能根據(jù)內(nèi)部的一些開(kāi)發(fā)方式、開(kāi)發(fā)需求、開(kāi)發(fā)的個(gè)性化訴求進(jìn)行定制化的開(kāi)發(fā)，尤其是在開(kāi)發(fā)過(guò)程方面，不僅僅是提供需求、任務(wù)、缺陷、迭代、發(fā)版等基礎(chǔ)功能，還能夠識(shí)別像研發(fā)的狀態(tài)、研發(fā)的工作量、研發(fā)的任務(wù)與代碼的關(guān)聯(lián)，并能為后續(xù)的發(fā)版追溯。在關(guān)鍵流程體系方面，實(shí)現(xiàn)了對(duì)需求管理、敏捷開(kāi)發(fā)、測(cè)試管理、發(fā)布管理，還有變更管理的一些流程支持。在日常協(xié)作方面，滿(mǎn)足了各種開(kāi)發(fā)團(tuán)隊(duì)對(duì)于電子臺(tái)賬、每日站會(huì)、重點(diǎn)關(guān)注、多人評(píng)論等等方面的一些訴求。在追溯性方面，也打通了需求、代碼、部署，通過(guò)關(guān)聯(lián)，實(shí)現(xiàn)從需求到代碼到版本的統(tǒng)一管理。

任務(wù)分解之后，面臨的第一件事情就是我們需要寫(xiě)代碼，代碼托管在哪里？我們?cè)谂椭凵咸峁┝艘粋€(gè)安全的代碼托管工具。

磐舟是在生產(chǎn)環(huán)境上提供統(tǒng)一的代碼倉(cāng)庫(kù)，用戶(hù)可以根據(jù)自己的研發(fā)模式來(lái)創(chuàng)建、管理代碼倉(cāng)庫(kù)，而且在安全權(quán)限方面，也支持設(shè)置團(tuán)隊(duì)的成員、密鑰等等一些個(gè)性化的校驗(yàn)。目前來(lái)看，我們有很多應(yīng)用都是微服務(wù)的，微服務(wù)一般會(huì)創(chuàng)建多個(gè)倉(cāng)庫(kù)，多人協(xié)同，共同開(kāi)發(fā)。支持使用一些模板化的工具對(duì)倉(cāng)庫(kù)進(jìn)行統(tǒng)一的初始化管理。在開(kāi)發(fā)方面，也支持像 IDEA、Eclipse 等等的一些編輯器，從本地環(huán)境中進(jìn)行直接的拉取、提交、推送代碼。在平臺(tái)頁(yè)面上，也提供了一些管理的功能，如合并、操作、比較等等的一些管理功能。除此之外，我們還在界面上提供了云 IDE 的開(kāi)發(fā)環(huán)境，因此一些簡(jiǎn)單的操作，一些簡(jiǎn)單的調(diào)試，用戶(hù)也可以從在線(xiàn)的 IDE 中直接打開(kāi)代碼，進(jìn)行開(kāi)發(fā)調(diào)試。

在平臺(tái)功能方面，我們也提供了像代碼行數(shù)的統(tǒng)計(jì)、平均代碼缺陷密度、代碼質(zhì)量掃描、安全掃描等等一系列的安全功能，不僅會(huì)給出一些風(fēng)險(xiǎn)提示，而且也會(huì)給出一些如何修改的建議。這種安全掃描在我們內(nèi)部也會(huì)作為一個(gè)上線(xiàn)前的必要校驗(yàn)環(huán)節(jié)，只有提供了相應(yīng)的安全掃描報(bào)告，比如漏洞都進(jìn)行了修復(fù)，才能夠進(jìn)行下一個(gè)關(guān)節(jié)的上線(xiàn)。

一般在我們寫(xiě)代碼的過(guò)程當(dāng)中會(huì)用到各種各樣的開(kāi)發(fā)框架。這些框架一般都會(huì)依賴(lài)于各種各樣的開(kāi)源的組件，尤其是 Java、Node.js 、Golang 等等，這些語(yǔ)言都會(huì)大量地用到各種各樣的依賴(lài)。我們?cè)趦?nèi)網(wǎng)的開(kāi)發(fā)過(guò)程中用到的依賴(lài)版本經(jīng)常會(huì)與公網(wǎng)上管理的依賴(lài)版本不太一致，這時(shí)，就會(huì)遇到一些問(wèn)題，我們的幾個(gè)開(kāi)發(fā)環(huán)境可能會(huì)出現(xiàn)功能不一致的問(wèn)題，排查這種問(wèn)題一般都是比較費(fèi)時(shí)費(fèi)力的。

為了解決這個(gè)問(wèn)題，我們?cè)谏a(chǎn)環(huán)境里打通了訪問(wèn)的一些單向網(wǎng)絡(luò)，在這個(gè)網(wǎng)絡(luò)里，我們可以提供了統(tǒng)一的依賴(lài)倉(cāng)庫(kù)，以生產(chǎn)環(huán)境為標(biāo)準(zhǔn)進(jìn)行同步依賴(lài)，從而一來(lái)可以直接使用，二來(lái)可以構(gòu)建同源。通過(guò)統(tǒng)一的制品庫(kù)，為研發(fā)、測(cè)試、生產(chǎn)幾個(gè)不同的環(huán)境提供可信來(lái)源。一點(diǎn)管控，可行分發(fā)。

不只是提供了多種語(yǔ)言框架的依賴(lài)倉(cāng)庫(kù)，還提供了多種類(lèi)型的私有庫(kù)，用戶(hù)也可以根據(jù)自己的使用方式對(duì)私有庫(kù)進(jìn)行管理。在依賴(lài)庫(kù)的掃描方面，因?yàn)槲覀冏隽艘稽c(diǎn)的可信管控，可以對(duì)使用到的依賴(lài)進(jìn)行統(tǒng)一的掃描。當(dāng)有風(fēng)險(xiǎn)發(fā)生的時(shí)候，可以進(jìn)行統(tǒng)一的告知，不僅是可以進(jìn)行一些提醒，而且還能給出一些可行的解決方法。

在代碼開(kāi)發(fā)的過(guò)程中，不同的業(yè)務(wù)系統(tǒng)往往使用不同的開(kāi)發(fā)語(yǔ)言、框架，使用不同的打包工具，依賴(lài)不同的組件，存在如此多的變量，如何進(jìn)行統(tǒng)一地持續(xù)構(gòu)建，其實(shí)對(duì)我們的 DevOps 平臺(tái)提出了非常高的考驗(yàn)。

在云原生的理念下，更多的是以容器的方式進(jìn)行交付，我們以引導(dǎo)用戶(hù)更多地使用 Dockerfile 進(jìn)行構(gòu)建，通過(guò)對(duì)標(biāo) Github，我們也提出了我們自己的一些構(gòu)建方式，首先使用 Dockerfile 的多階段構(gòu)建技術(shù)，把構(gòu)建的主動(dòng)權(quán)還給用戶(hù)，用戶(hù)可以根據(jù)自己的開(kāi)發(fā)語(yǔ)言、開(kāi)發(fā)框架、使用習(xí)慣去構(gòu)建自己的流水線(xiàn)，自己的業(yè)務(wù)系統(tǒng)將要如何編譯打包、如何配置通過(guò)描述語(yǔ)言寫(xiě)入到這個(gè)流水線(xiàn)中，也將運(yùn)行容器和構(gòu)建容器進(jìn)行分開(kāi)管理，避免在代碼的管理當(dāng)中混入太多的環(huán)境管理、過(guò)程管理，而且一些配置類(lèi)的信息代入生產(chǎn)環(huán)境中也是不安全的，有一定安全隱患。通過(guò)版本化的配置文件，我們可以將整個(gè)的配置文件放到代碼倉(cāng)庫(kù)中，隨著代碼一起進(jìn)行版本的管理。

再就是我們打通了 Docker  build 出來(lái)的鏡像如何在開(kāi)發(fā)、測(cè)試、生產(chǎn)等不同環(huán)境中進(jìn)行的統(tǒng)一同步。通過(guò)這種鏡像的同步，可以有效地解決在這幾個(gè)環(huán)境中不斷進(jìn)行推送同步的工作量，而且通過(guò)我們實(shí)現(xiàn)的這個(gè)統(tǒng)一分發(fā)推送渠道，用戶(hù)只需要關(guān)心兩個(gè)方面：第一是我的代碼如何去構(gòu)建成鏡像；第二是我的鏡像如何去使用。

在我們平臺(tái)提供的功能里，首先是解決鏡像的分發(fā)，可以從構(gòu)建環(huán)境中單向地向不同的環(huán)境進(jìn)行推送，而且在推送之前，添加了一些安全保障能力，為了保障生產(chǎn)安全，尤其是在向生產(chǎn)環(huán)境、準(zhǔn)生產(chǎn)環(huán)境同步之前，會(huì)進(jìn)行安全掃描，只有安全掃描通過(guò)，才能夠同步通過(guò)。這一方面保證了便利性，另一方面也對(duì)安全性提供了一定的保障。

有一些鏡像修復(fù)起來(lái)并不是那么容易，所以我們提供了一些基礎(chǔ)鏡像。我們會(huì)對(duì)常見(jiàn)的漏洞進(jìn)行統(tǒng)一的加固修復(fù)，加固修復(fù)完成之后再提供給業(yè)務(wù)系統(tǒng)使用。業(yè)務(wù)系統(tǒng)使用我們提供的這種構(gòu)建鏡像，在一些漏洞的修復(fù)方面，只需我們統(tǒng)一修復(fù)構(gòu)建完成即可，整體的開(kāi)發(fā)效率也能得到進(jìn)一步的提升。

應(yīng)用部署后，面臨的第一個(gè)問(wèn)題就是如何訪問(wèn)它，而現(xiàn)在隨著 ServiceMesh 的流行，我們?cè)谄脚_(tái)中也增加了對(duì) ServiceMesh 的完整支持，而且默認(rèn)開(kāi)啟了 ServiceMesh 的能力，用戶(hù)在提交了自己的應(yīng)用程序之后，會(huì)被編譯成云原生的鏡像，通過(guò) GitOps 也能夠?qū)?ServiceMesh 的控制 YAML，尤其是 Isito 的，一起進(jìn)行提交。

首先，我們?cè)谀芰ι习送暾?Isito 管理功能，用戶(hù)在使用的過(guò)程中，可以根據(jù)自己的開(kāi)發(fā)需要編寫(xiě) YAML。

第二，我們?cè)谄脚_(tái)里配置了通用的網(wǎng)關(guān)配置域名。有時(shí)需要訪問(wèn)一些臨時(shí)域名，這時(shí)可以比較方便地打通從用戶(hù)自己的開(kāi)發(fā)環(huán)境到我們平臺(tái)的訪問(wèn)。

第三，支持內(nèi)部域名的自定義 CRD。這樣用戶(hù)在開(kāi)發(fā)調(diào)試的過(guò)程中可以保持相同的配置，只是在不同的集群里配置一下域名的解析 CRD 即可。在整個(gè)過(guò)程中，環(huán)境的配置變量都無(wú)需調(diào)整，進(jìn)一步縮小了研發(fā)環(huán)境和生產(chǎn)環(huán)境的差異性，生產(chǎn)環(huán)境、研發(fā)環(huán)境的差異越小，上線(xiàn)后的穩(wěn)定性也一定會(huì)有所提升，從而降低問(wèn)題的排查成本。

應(yīng)用部署完成之后，往往需要進(jìn)行?志的查看，檢查應(yīng)用是否運(yùn)行正常，有沒(méi)有報(bào)錯(cuò)，所以在平臺(tái)上，我們對(duì)應(yīng)用程序的文件日志、標(biāo)準(zhǔn)輸出 Console?志，還有一些網(wǎng)關(guān)訪問(wèn)的日志，以及操作的日志都進(jìn)行了統(tǒng)一的收集，并進(jìn)行了一些關(guān)聯(lián)，這樣用戶(hù)在出現(xiàn)程序問(wèn)題時(shí)，可以比較方便地從這幾個(gè)方面進(jìn)行故障定位，從而提升開(kāi)發(fā)效率。

在開(kāi)發(fā)過(guò)程中，除了查看日志，還會(huì)經(jīng)常查看應(yīng)用的運(yùn)行狀況，甚至有可能需要進(jìn)入到容器中一點(diǎn)點(diǎn)地執(zhí)行調(diào)試命令。在沒(méi)有我們平臺(tái)界面之前，用戶(hù)需要不斷地在各個(gè)環(huán)境、各個(gè)系統(tǒng)中切換，會(huì)帶來(lái)非常高的切換成本和操作的復(fù)雜度。我們提供了一體化的管理界面，既能看到集群的運(yùn)行情況，也能看到應(yīng)用的簡(jiǎn)單運(yùn)行情況、資源的用量、應(yīng)用資源的關(guān)聯(lián)關(guān)系、應(yīng)用的運(yùn)行日志，還能進(jìn)入到容器中執(zhí)行一些 Shell 命令。通過(guò)這種方式，不管是運(yùn)維人員還是開(kāi)發(fā)人員，都能夠?qū)θ蘸笙到y(tǒng)如何在容器的云環(huán)境中運(yùn)行，有一個(gè)更加直觀、更加貼切的感受，對(duì)于日后發(fā)布到生產(chǎn)環(huán)境，如何排錯(cuò)、如何保證業(yè)務(wù)的穩(wěn)定運(yùn)行都能打下比較好的基礎(chǔ)。

在集群管理方面，我們主要提供了一站式的開(kāi)發(fā)驗(yàn)證環(huán)境，前面提到的整個(gè)過(guò)程都是對(duì)如何開(kāi)發(fā)軟件做支撐的，開(kāi)發(fā)軟件運(yùn)行所需要的環(huán)境，目前來(lái)說(shuō)，一般是要提供一套 Kubernetes 環(huán)境的，而 Kubernetes 環(huán)境相對(duì)來(lái)說(shuō)還是比較昂貴的，對(duì)配置的要求也比較高，并且我們也難以為每個(gè)同學(xué)都提供一套 Kubernetes 環(huán)境。

因此我們?cè)谂椭燮脚_(tái)上提供了 Kubernetes 開(kāi)發(fā)環(huán)境，用戶(hù)在使用時(shí)，可以通過(guò)界面來(lái)點(diǎn)選申請(qǐng)。申請(qǐng)到開(kāi)發(fā)環(huán)境之后，他可以在環(huán)境內(nèi)進(jìn)行各種開(kāi)發(fā)調(diào)試。一般來(lái)說(shuō)，申請(qǐng)到的開(kāi)發(fā)環(huán)境有一定的時(shí)間要求，時(shí)間到期或者用戶(hù)使用完成之后，它可以被歸還到大池子中，從而提高了整體的資源利用率。

在開(kāi)發(fā)方面，其實(shí)還有一個(gè)比較大的問(wèn)題，那就是數(shù)據(jù)從哪來(lái)。目前來(lái)說(shuō)，我們還不能將數(shù)據(jù)從生產(chǎn)環(huán)境中直接拷貝到測(cè)試環(huán)境中，這些數(shù)據(jù)需要進(jìn)行一定的脫敏驗(yàn)證。另外，在自動(dòng)化測(cè)試方面往往需要進(jìn)行自動(dòng)化的接口測(cè)試、UI 測(cè)試、回歸測(cè)試，如果沒(méi)有自動(dòng)化的工具，整個(gè)測(cè)試效率也會(huì)比較受影響。在我們的環(huán)境中會(huì)整合這幾類(lèi)自動(dòng)化進(jìn)行統(tǒng)一提供。

在安全門(mén)禁體系方面，磐基磐舟共用一套 DevSecOps 設(shè)計(jì)，涵蓋了研發(fā)、構(gòu)建、運(yùn)行的各個(gè)方面。通過(guò)在研發(fā)流水線(xiàn)的整個(gè)過(guò)程中，設(shè)置不同的檢查點(diǎn)形成安全門(mén)禁，有問(wèn)題可以盡早發(fā)現(xiàn)、盡早修復(fù)，可以避免將這些問(wèn)題代入到生產(chǎn)中。我們主要是從開(kāi)發(fā)安全、構(gòu)建交付安全、數(shù)據(jù)安全、以及應(yīng)用運(yùn)行安全等幾方面進(jìn)行安全防護(hù)的：

• 在開(kāi)發(fā)安全方面，主要是進(jìn)行代碼的安全檢查掃描、SQL 注入檢測(cè)、以及代碼質(zhì)量的掃描門(mén)禁。

• 在構(gòu)建過(guò)程中，主要進(jìn)行依賴(lài)的漏洞掃描、開(kāi)源協(xié)議的掃描、開(kāi)源漏洞的掃描以及鏡像漏洞的掃描。

• 在數(shù)據(jù)安全方面，主要是數(shù)據(jù)審計(jì)和數(shù)據(jù)庫(kù)的高危操作，以及脫敏流程。

• 在應(yīng)用運(yùn)行方面，主要是容器的安全運(yùn)行防護(hù)、應(yīng)用的提前檢測(cè)、容器命令的審計(jì)、以及 WiFi 隱私安全防護(hù)。

通過(guò)這幾個(gè)方面的安全能力組合，可以有效地避免將安全問(wèn)題帶入到生產(chǎn)中，從而降低了整個(gè)生產(chǎn)安全的威脅。

開(kāi)發(fā)安全主要是通過(guò)代碼質(zhì)量、代碼審計(jì)、開(kāi)源掃描、以及移動(dòng)端的 APP 安全掃描形成一個(gè)綜合分?jǐn)?shù)，在項(xiàng)目緯度上進(jìn)行統(tǒng)一的展示，用戶(hù)可以比較直觀地看到自己的項(xiàng)目風(fēng)險(xiǎn)等級(jí)。平臺(tái)在提供掃描的同時(shí)，也會(huì)提供一些修復(fù)建議，因此我們的研發(fā)和安全人員可以參考這些信息來(lái)解決程序中的安全問(wèn)題。

在構(gòu)建交付安全方面，主要是在流水線(xiàn)中插入各種掃描環(huán)節(jié)。在鏡像掃描部分，主要是對(duì)鏡像中涉及到操作系統(tǒng)、中間件依賴(lài)、以及程序本身的文件系統(tǒng)等不同層面進(jìn)行掃描，通過(guò)增量的、批量的、以及全量的安全掃描來(lái)給出一份安全報(bào)告。如果這份報(bào)告的得分較低會(huì)被門(mén)禁系統(tǒng)卡到流水線(xiàn)之外，只有通過(guò)安全掃描的鏡像才能夠同步到生產(chǎn)環(huán)境中去，這種方式能夠有效地避免在生產(chǎn)運(yùn)行中出現(xiàn)安全漏洞。

在數(shù)據(jù)安全方面，尤其是在數(shù)據(jù)審計(jì)方面，還是需要前置到開(kāi)發(fā)環(huán)境中。在敏感 SQL 審核、數(shù)據(jù)的脫敏方面，一般會(huì)伴有程序的開(kāi)發(fā)調(diào)試，如果是在生產(chǎn)環(huán)境中發(fā)現(xiàn)這種問(wèn)題，然后再反饋到開(kāi)發(fā)環(huán)境中，整個(gè)過(guò)程會(huì)比較長(zhǎng)。而我們通過(guò)在開(kāi)發(fā)環(huán)境中內(nèi)置 SQL 掃描、脫敏數(shù)據(jù)掃描，有利于在開(kāi)發(fā)環(huán)境中前置處理好這些問(wèn)題。在自動(dòng)化測(cè)試方面，需要解釋一下測(cè)試數(shù)據(jù)，我們從開(kāi)發(fā)環(huán)境中將相應(yīng)的一些數(shù)據(jù)經(jīng)過(guò)脫敏處理之后導(dǎo)入到測(cè)試環(huán)境中，對(duì)于提升測(cè)試的整體質(zhì)量而言，效果還是比較明顯的。

接下來(lái)，將會(huì)介紹我們?cè)?Serverless 方面的一些云原生實(shí)踐。

從我們自己的理解來(lái)看 Serverless 平臺(tái)，首先它是一個(gè)平臺(tái)，同時(shí)也是一種思想理念。Serverless 更多的是用戶(hù)提交了一小段代碼，通過(guò)這一小段代碼，我們?cè)谄脚_(tái)上將它補(bǔ)充成為一個(gè)完整的容器，比如容器內(nèi)的 Dockerfile、打包進(jìn)來(lái)的整個(gè)運(yùn)行環(huán)境，從而形成一個(gè)完整的鏡像。這個(gè)完整鏡像其實(shí)是獨(dú)立運(yùn)行的，但是我們給到用戶(hù)的只是部分，可能只是將用戶(hù)的業(yè)務(wù)代碼進(jìn)行上傳，在這個(gè)過(guò)程中，我們可以在基礎(chǔ)環(huán)境、標(biāo)準(zhǔn)化的配置、Dockerfile 等方面進(jìn)行不同的能力切入，比如運(yùn)行參數(shù)的優(yōu)化、平臺(tái)參數(shù)的配置、資源用量的管理，而且還能提供一些統(tǒng)一的升級(jí)管理手段。

不僅如此，由于這些配置都是在平臺(tái)上統(tǒng)一配置的，對(duì)于 ARM、X86，業(yè)務(wù)是高 IO 的，還是高 CPU 的，對(duì)于這些不同的特殊情況，我們都可以在后臺(tái)為用戶(hù)的應(yīng)用進(jìn)行統(tǒng)一的調(diào)度管理，經(jīng)過(guò)這個(gè)過(guò)程，用戶(hù)提交的還只是他自己的業(yè)務(wù)函數(shù)，但是我們會(huì)在平臺(tái)級(jí)幫它提供更多的功能。

在開(kāi)發(fā)過(guò)程中，一般需要進(jìn)行不斷的開(kāi)發(fā)調(diào)試，對(duì)于 CD 的過(guò)程，其實(shí)會(huì)要求更加的迅速。針對(duì)這種開(kāi)發(fā)過(guò)程不斷連續(xù)的調(diào)試部署，我們推出了一個(gè) GitOps 的管理平臺(tái)，GitOps 能夠以版本化的方式將聲明式的配置，將應(yīng)用的編排、構(gòu)建等等一系列的操作形成流水線(xiàn)，而且是在 Git 中進(jìn)行版本化管理，不同的環(huán)境中都使用相同的聲明式配置。它也是非常方便的一種部署方式，我們目前提供的這種 GitOps 管理主要有兩種：一種是提供了界面的引導(dǎo)式，能夠滿(mǎn)足初學(xué)者對(duì)界面操作的使用訴求；另一種是提供純粹的 YAML 提交方式，一些高級(jí)的研發(fā)運(yùn)維更習(xí)慣于直接去操作 YAML 文件，以進(jìn)行應(yīng)用的編排管理。這兩種方式，不管是針對(duì)初級(jí)的用戶(hù)，還是高級(jí)的用戶(hù)，在使用上都是非常方便的。

談到彈性能力，Serverless 平臺(tái)本身也有比較豐富的彈性參數(shù)，我們平臺(tái)在這方面也進(jìn)行了更多的一些拓展，比如基于業(yè)務(wù)指標(biāo)的節(jié)點(diǎn)級(jí)彈性以及集群級(jí)的彈性。如果按照副本數(shù)，當(dāng)?shù)竭_(dá)一定的極限之后，是需要往資源池里加機(jī)器的。我們平臺(tái)對(duì)這種彈性能力進(jìn)行了拓展，如果是在加機(jī)器的情況下，或者是在某一區(qū)域負(fù)載不夠用的情況下，我們也可以在其他區(qū)域進(jìn)行整個(gè)集群級(jí)的彈性，所以我們現(xiàn)在能夠?qū)崿F(xiàn) Pod 級(jí)、Pod 實(shí)例級(jí)、Node 節(jié)點(diǎn)級(jí)、以及 Cluster 集群級(jí)等三種級(jí)別的彈性能力。

得益于我們前面提到的統(tǒng)一代碼托管流水線(xiàn)，并且為應(yīng)用進(jìn)行了 Dockerfile 的構(gòu)建收斂，我們可以利用 ARM、X86 雙平面的環(huán)境，為用戶(hù)提供這兩個(gè)平面下的鏡像構(gòu)建。用戶(hù)提供一份代碼，但我們會(huì)幫它編譯成這兩種運(yùn)行環(huán)境的鏡像，這樣在國(guó)產(chǎn)化的進(jìn)程中，用戶(hù)的代碼不需要太多的改造就能夠適配這兩種運(yùn)行環(huán)境，也有利于我們加大對(duì)國(guó)產(chǎn)化的支持力度。

在國(guó)產(chǎn)化方面，主要是從我們平臺(tái)級(jí)進(jìn)行了一些兼容適配，比如硬件、操作系統(tǒng)、容器、以及中間件，我們平臺(tái)級(jí)對(duì)這些方面都進(jìn)行了兼容適配，通過(guò)這種兼容適配，業(yè)務(wù)系統(tǒng)只需像使用 X86 的場(chǎng)景一樣去使用即可。所以在整個(gè)過(guò)程中，我們通過(guò) Serverless 能夠?qū)⒏嗟倪m配細(xì)節(jié)隱藏到平臺(tái)之中，對(duì)于應(yīng)用而言，它可以更多地關(guān)注于自己的業(yè)務(wù)邏輯，從而降低了對(duì)國(guó)產(chǎn)化適配的難度。

接下來(lái)，我們主要談一下盤(pán)舟 DevOps 平臺(tái)的未來(lái)演進(jìn)方向。

通過(guò)我們自己在開(kāi)發(fā)過(guò)程中引入低代碼，能夠切實(shí)地感受到在不少場(chǎng)景下開(kāi)發(fā)交付效率都有了大幅的提升，保守估計(jì)，很多場(chǎng)景下的提升達(dá)到了 30%，甚至是 60%～70%。

低代碼的開(kāi)發(fā)模式，將傳統(tǒng)的開(kāi)發(fā)模式需配備產(chǎn)品經(jīng)理、需求、UI、設(shè)計(jì)等等一系列專(zhuān)業(yè)人員，轉(zhuǎn)變?yōu)榱酥恍枧鋫湎鄳?yīng)的業(yè)務(wù)分析人員即可。低代碼開(kāi)發(fā)模式極大地提高了軟件的生產(chǎn)效率、質(zhì)量和安全，也有助于打破 IT 人員的一些溝通壁壘，尤其是在跨廠商、跨部門(mén)、跨系統(tǒng)的協(xié)作方面，解決了這種“周期長(zhǎng)、門(mén)檻高、適應(yīng)性差”的傳統(tǒng)開(kāi)發(fā)模式。

通過(guò)我們一段時(shí)間的使用，總體的感受是在低代碼的開(kāi)發(fā)模式下，開(kāi)發(fā)交付效率已經(jīng)有了大幅面的提升，原來(lái)很多業(yè)務(wù)邏輯是需要寫(xiě)到代碼中，使用了低代碼之后，很多業(yè)務(wù)邏輯可以通過(guò)可視化編排的方式來(lái)實(shí)現(xiàn)。這個(gè)過(guò)程也極大地降低了對(duì)開(kāi)發(fā)的要求，原來(lái)需要比較專(zhuān)業(yè)的人員進(jìn)行開(kāi)發(fā)、架構(gòu)、設(shè)計(jì)、測(cè)試，現(xiàn)在就不需要這么專(zhuān)業(yè)的人員了，只要有一定基礎(chǔ)的人員即可掌握如何通過(guò)可視化的方式、如何通過(guò)編排的方式來(lái)實(shí)現(xiàn)新的功能，并進(jìn)行一體化的開(kāi)發(fā)、交付、測(cè)試，從而降低了整體的從業(yè)門(mén)檻。

通過(guò)上圖，大家可以感受一下，在我們的業(yè)務(wù)場(chǎng)景中，原來(lái)從用戶(hù)認(rèn)證，到過(guò)戶(hù)校驗(yàn)，再到最后的生產(chǎn)上線(xiàn)，這個(gè)過(guò)程相對(duì)還是比較清晰地，但是在我們分析完成之后，就會(huì)編寫(xiě)具體的業(yè)務(wù)代碼，在編寫(xiě)代碼時(shí)，會(huì)按照?qǐng)D中中間部分的模式對(duì)更多的業(yè)務(wù)邏輯進(jìn)行拆分以及組合，在這個(gè)過(guò)程中，從某一個(gè)層面來(lái)看，基本上已經(jīng)很難體現(xiàn)原有的這種開(kāi)發(fā)過(guò)程了。

但是在我們低代碼的開(kāi)發(fā)過(guò)程中，在每一個(gè)層中，具體的業(yè)務(wù)邏輯體現(xiàn)如右側(cè)模式圖所示，它是中間模式圖中的一個(gè)個(gè)原子能力，對(duì)這些原子能力的編排又能還原成了最左邊的業(yè)務(wù)邏輯圖。通過(guò)這種可視化的編排方式，整體的業(yè)務(wù)邏輯還是能夠體現(xiàn)出來(lái)。

結(jié)合 Serverless 來(lái)看，低代碼編排的服務(wù)更多的就是微服務(wù)，甚至是更小顆粒度的原子級(jí)服務(wù)。而我們的 Serverless 平臺(tái)主要就是把函數(shù)級(jí)的原子服務(wù)直接發(fā)布為運(yùn)行態(tài)，提供調(diào)用接口。

這些函數(shù)級(jí)的能力是否可以使用 Serverless 來(lái)進(jìn)行開(kāi)發(fā)和發(fā)布呢？其實(shí)這兩者是可以比較流暢地結(jié)合在一起的。Serverless 負(fù)責(zé)提供底層、函數(shù)級(jí)、原子級(jí)能力的運(yùn)行、維護(hù)、以及彈性；低代碼負(fù)責(zé)對(duì)這些接口進(jìn)行編排，進(jìn)行使用。在這種模式下，用戶(hù)不用關(guān)心底層的資源，通過(guò)平臺(tái)自動(dòng)地發(fā)布上線(xiàn)、按量彈性擴(kuò)縮容，降低了整個(gè)項(xiàng)目的開(kāi)發(fā)以及運(yùn)營(yíng)成本，也減少了運(yùn)維難度和工作量，整體迭代的上線(xiàn)周期也能得到提速。

通過(guò)磐基磐?低代碼，為業(yè)務(wù)系統(tǒng)帶來(lái)了快速上線(xiàn)、接口的可視化編排、新場(chǎng)景的場(chǎng)景化應(yīng)用能力。而 Serverless 平臺(tái)則解決了后端接口、微服務(wù)應(yīng)用和原子級(jí)應(yīng)用的按需彈性、穩(wěn)定運(yùn)行。它們兩者結(jié)合形成了一個(gè)新的開(kāi)發(fā)組合，能夠使我們整個(gè)部門(mén)的開(kāi)發(fā)更加簡(jiǎn)單，運(yùn)行更加穩(wěn)定，服務(wù)更加彈性。

以上是我今天的主要分享內(nèi)容，感謝大家的觀看收聽(tīng)，謝謝！

        
        

         往期推薦
        
        
        
        

         
         

        
        

              
              

               
               
基于Kubernetes構(gòu)建完整的DevOps體系

               
               
nmcli 命令詳解

               
               
CentOS 搭建 OpenVPN 服務(wù)，一次性成功！

               
               
600條最強(qiáng) Linux 命令總結(jié)

               
               
大規(guī)模運(yùn)維監(jiān)控落地后，低頭深思！
               
               
面試官：Redis 緩存滿(mǎn)了怎么辦？
               
               
Kubernetes 網(wǎng)絡(luò)：16 張圖帶你從小白到專(zhuān)家
               
               
得物App全棧 DevOps 可觀測(cè)平臺(tái)落地實(shí)踐

               
               

                
                

                 小孩也能學(xué)會(huì)的 Kubernetes 繪本教程
                 
                 

                
                
               
               

                
                

                 優(yōu)秀的 Shell 運(yùn)維腳本鑒賞
                
                
               
               

                
                

                 阿里 Nacos 高可用集群部署
                
                
               
               

                
                

                 神器 Nginx 的學(xué)習(xí)手冊(cè) ( 建議收藏 )
                
                
               
               

                
                

                 K8S 常用資源 YAML 詳解
                
                
               
               

                
                

                 DevOps與CI/CD常見(jiàn)面試問(wèn)題匯總
                 
                 

                
                
               
               

                
                

                 我會(huì)在Docker容器中抓包了！
                
                
               
               

                
                

                 19 個(gè) K8S集群常見(jiàn)問(wèn)題總結(jié)，建議收藏
                
                
               
               

                
                

                 9 個(gè)實(shí)用 Shell 腳本，建議收藏！
                
                
               
               

                
                

                 詳解 K8S Helm CI/CD發(fā)布流程
                
                
               
               

                
                

                 一臺(tái)服務(wù)器最大能支持多少條TCP連接？
                
                
               
               

                
                

                 K8S運(yùn)維必知必會(huì)的 Kubectl 命令總結(jié)

                
                
               
               

                
                

                 16 張圖硬核講解 Kubernetes 網(wǎng)絡(luò)

                
                
               
               

                
                

                 史上最全 Jenkins Pipeline流水線(xiàn)詳解
                
                
               
               

                
                

                 主流監(jiān)控系統(tǒng) Prometheus 學(xué)習(xí)指南
                
                
              
              
               
               

                
                

                 
                 

                  搭建一套完整的企業(yè)級(jí) K8s 集群（二進(jìn)制方式）
                 
                 
               
               
                  
                  

                   
                   

                    
                    

                     40個(gè) Nginx 常問(wèn)面試題
                    
                    
                   
                   

                    
                    

                     Linux運(yùn)維工程師 50個(gè)常見(jiàn)面試題
                    
                    
                  
                  

    
    

     
     

      
      
        
        

         
         
          
          

           
           

          
          
          
          

           
           
            
            

          
          
          
          

           
           

          
          
          
          

           點(diǎn)亮，服務(wù)器三年不宕機(jī)