云平臺運維管理詳細設(shè)計

云平臺運維管理詳細設(shè)計

容器云平臺運維架構(gòu)和容器云平臺的架構(gòu)設(shè)計密切相關(guān)。容器云

平臺的架構(gòu)會直接影響著其運維架構(gòu)的設(shè)計。我們在設(shè)計容器云平臺

的時候，就從DevOps的思想角度出發(fā)，就考慮到了開辟、測試和運

維之間的協(xié)作和配合，因此定義了以鏡像倉庫為媒介，明確分離開辟、

測試和應(yīng)用運維職責。把鏡像倉庫作為標準化交付庫，把應(yīng)用服務(wù)整

個生命周期過程就劃分為三個階段：開辟、測試和應(yīng)用服務(wù)運維（應(yīng)

用運維和資源運維分兩層）。

應(yīng)用服務(wù)的管理和運維是整個容器云平臺的核心。運維運營能力

是整個DevOps過程中最重要的一部份，是企業(yè)創(chuàng)造新價值的支撐。

在數(shù)字化轉(zhuǎn)型4T（指的是IT信息技術(shù)、CT通信技術(shù)、DT數(shù)據(jù)技術(shù)、

0T運營技術(shù)）融合的時代，運維運營是關(guān)鍵。容器云平臺的運維狹

義的說是容器云平臺自身的運維及對平臺運營支持；廣義的說也包括

容器云平臺之上業(yè)務(wù)應(yīng)用服務(wù)的運維運營支持。我們在設(shè)計容器云平

臺時，定義了容器云平臺”以應(yīng)用管理為核心”，是從廣義上來定義

容器云平臺的運維架構(gòu)。作為傳統(tǒng)企業(yè)用戶，我們覺得不能只關(guān)注一

個平臺或者一個工具，更要關(guān)注其價值或者潛在的價值在哪里，更更

好的協(xié)助、配合相關(guān)部門團隊取得價值，這樣我們的運維工作才真

的更故意義和更有價值。畢竟我們不是互聯(lián)網(wǎng)企業(yè)，側(cè)重點不一樣,

容器云平臺、云管平臺等都是基本的工具，都是為了更好的服務(wù)好

業(yè)務(wù)團隊，因此在設(shè)計容器云平臺架構(gòu)和定義容器云平臺運維架構(gòu)

的時候，

更多的是基于實際的需求來確定的。

因此，基于實際的需求考慮，在劃分三個階段的基礎(chǔ)上，我們定

義容器云平臺運維架構(gòu)包含應(yīng)用服務(wù)運維和基礎(chǔ)設(shè)施資源運維兩個

層次。傳統(tǒng)丹田系統(tǒng)的運維運營，通常要自己管理和維護系統(tǒng)的基礎(chǔ)

設(shè)施資源。但如果采用了容器云平臺，就不能從上到下還是自己來維

護，否則那運維工作量可能遠遠超出想象。也正是基于此考慮，我們

將基礎(chǔ)設(shè)施資源運維和應(yīng)用服務(wù)運維分離，使應(yīng)用服務(wù)運維人員專注

于應(yīng)用運維，基礎(chǔ)設(shè)施資源運維人員專注于基礎(chǔ)設(shè)施資源運維。而又

由于基礎(chǔ)設(shè)施資源類型眾多，有虛擬化、私有云、眾多共有云等不同

類型，需要由多云管理平臺來統(tǒng)一管理和維護基礎(chǔ)設(shè)施資源，并為容

器云平臺提供標準化的基礎(chǔ)設(shè)施資源服務(wù)。容器云平臺的平臺管理員

只負責容器云平臺的基礎(chǔ)設(shè)施資源的管理和分配，容器云平臺只是使

用資源而不運維資源。

同時、為了更好的利用容器的輕量、彈性、無狀態(tài)等特性，同時

又保證滿足某些應(yīng)用和服務(wù)的穩(wěn)定性要求，我們結(jié)合容器化部署和非

容器化部署各自優(yōu)缺點，將應(yīng)用服務(wù)管理和管理分為兩層體系，容器

云平臺層和API網(wǎng)關(guān)層。

綜合上面的思路和分析定義，容器云平臺運維架構(gòu)設(shè)計定義為三

個階段、兩層運維和雙層服務(wù)管理架構(gòu)。使整個容器云平臺運維架構(gòu)

清晰簡明，也很便利的劃分相關(guān)運維人員職責，更好的協(xié)調(diào)不同團隊

之間的工作，滿足DevOps所期望的減少資源浪費、提升團隊協(xié)作、

提高IT效率、降低業(yè)務(wù)成本等需求。

一、以鏡像倉庫為媒介

2/18

容器云平臺構(gòu)建了以鏡像倉庫為媒介的三段過程，使開辟、測試

和運維分離，既兼顧傳統(tǒng)開辟運維模式，也滿足實現(xiàn)開辟運維一體化

需求。

（-）開辟階段

開辟階段以交付標準化鏡像為重點，以自動化方式編譯、打包、

提交鏡像到測試鏡像倉庫，這樣使開辟人員依然關(guān)注業(yè)務(wù)邏輯的設(shè)計

和實現(xiàn)，同時也要關(guān)注滿足應(yīng)用服務(wù)架構(gòu)容器化部署的可擴展性、彈

性、高性能等要求，但不需要考慮服務(wù)器、網(wǎng)絡(luò)、存儲等來源、管理、

監(jiān)控和維護等事項。

（二）測試階段

測試階段以測試鏡像倉庫為起點，在完成為了各項測試任務(wù)之后,

滿足生產(chǎn)部署要求的應(yīng)用鏡像自動化交付到生產(chǎn)鏡像庫。鏡像不變，

則相當于環(huán)境不變，從而實現(xiàn)了環(huán)境一致性。在鏡像測試部署和生產(chǎn)

部署過程中，都能實現(xiàn)分鐘級的配置部署，從而提升了效率。配合標

準化基礎(chǔ)設(shè)施資源的分鐘級申請部署，可以在任何測試環(huán)境實現(xiàn)快速

的測試環(huán)境搭建和測試。

（三）運維階段

運維階段以生產(chǎn)鏡像庫為起點，部署、運行、監(jiān)控、維護業(yè)務(wù)應(yīng)

用系統(tǒng)，同時需要按需供給這些業(yè)務(wù)應(yīng)用運行和業(yè)務(wù)運營所需的基礎(chǔ)

設(shè)施資源。這是持續(xù)時間最長最重要的過程，也是創(chuàng)造新價值的過程。

運維階段又可以細分為若干個子階段和部份，比如持續(xù)部署、持

續(xù)監(jiān)控、日志管理、服務(wù)管理與管理、基礎(chǔ)設(shè)施資源管理與分配等。

3/18

細化這些階段和部份是為了更好的理解和設(shè)計容器云平臺運維架構(gòu)，

更好的實現(xiàn)容器云平臺的運維能力。

以鏡像倉庫為媒介，實現(xiàn)了一次構(gòu)建，多環(huán)境部署運行能力。我

們未采用一些人建議的在不同環(huán)境都需要打包構(gòu)建的方式，而是采用

“開辟環(huán)境一次構(gòu)建，交付標準化鏡像，多環(huán)境部署運行”的方式，

在開辟環(huán)境一次構(gòu)建之后，自動上傳到測試鏡像倉庫；由測試人員在

容器云平臺快速部署構(gòu)建應(yīng)用服務(wù)的測試環(huán)境，可以是多版本并行，

通過兩層服務(wù)管理體系能實現(xiàn)；在完成測試之后，同步鏡像到生產(chǎn)環(huán)

境鏡像倉庫，然后就可以在生產(chǎn)環(huán)境部署運行。

以鏡像倉庫為媒介既簡化了DevOps流程，也提高了安全性和效

率。測試和生產(chǎn)環(huán)境可以實現(xiàn)物理隔離，提高了安全性。雖然構(gòu)建流

程是自動化的，但在不同環(huán)境構(gòu)建既浪費時間和資源，也帶來了潛在

的不安全因素。因此，我們采用鏡像倉庫為媒介這種簡單的方式來滿

足需求，提高效率和安全性。

二、資源運維和應(yīng)用運維分離

云計算的三層架構(gòu)QaaS、PaaS、SaaS）很好的定義了每一層云

平臺的能力。容器作為基礎(chǔ)的單元，可以作為一種資源，提供運行時

環(huán)境，可以是在laaS層，可以通過laaS云平臺或者云管提供容器化

服務(wù)。而基于容器而實現(xiàn)的容器云平臺，我們認為目的是為了更好支

撐應(yīng)用，簡化應(yīng)用管理工作。不僅僅簡單提供容器服務(wù)，否則就復雜

化了應(yīng)用管理的工作。

4/18

從云計算的三層體系劃分（laaS、PaaS、SaaS）考慮，我們把容

器云平臺定義為輕量化PaaS平臺。容器可以作為資源放在laaS層,

但容器云平臺一定是在PaaS層。因此我們設(shè)計的容器云平臺的四層

架構(gòu)（基礎(chǔ)設(shè)施資源層、資源調(diào)度層、平臺層、應(yīng)用層）很好的解決

了應(yīng)用運維和資源運維的耦合問題，將基礎(chǔ)設(shè)施資源運維和應(yīng)用運維

分離，使專業(yè)的人員用專業(yè)的技能去完成專業(yè)的事項。

（一）基礎(chǔ)設(shè)施資源運維

容器云平臺的重點并不在基礎(chǔ)設(shè)施資源運維?；A(chǔ)設(shè)施資源可以

通過laaS層的標準化資源服務(wù)來提供。在容器云平臺，平臺只是使

用基礎(chǔ)設(shè)施資源而不維護基礎(chǔ)設(shè)施資源。租戶使用申請或者分配的資

源來部署運行應(yīng)用，而不需要考慮基礎(chǔ)設(shè)施資源的維護和運營，這

樣就把重心放到了應(yīng)用本身，按需申請和使用資源。而不同的云資

源也很好的提供了備份、遷移、容災(zāi)等能力。

應(yīng)用服務(wù)的部署運行離不開基礎(chǔ)設(shè)施資源的支持，但對租戶來

說，基礎(chǔ)設(shè)施資源應(yīng)該是透明的。在基礎(chǔ)設(shè)施資源維護方面，私有云

也需要借鑒公有云的思想。租戶關(guān)心的是業(yè)務(wù)應(yīng)用，透明的按需申請

使用資源。云廠商越來越多，提供的云資源類型也各不相同，對于任

何一家公司來說，必須要整合這些不同的云資源，以標準化資源服務(wù)

的形式才干更好的支撐企業(yè)業(yè)務(wù)運營。這就需要依托多云管理平臺，

通過基礎(chǔ)設(shè)施資源的整合和融合，構(gòu)建統(tǒng)一的基礎(chǔ)設(shè)施資源服務(wù)；容

器云平臺所使用的基礎(chǔ)設(shè)施資源如CPU、內(nèi)存、存儲、網(wǎng)絡(luò)等資源由

云管平臺進行統(tǒng)一的管控和分配，租戶只是使用基礎(chǔ)設(shè)施資源而不需

5/18

要維護基礎(chǔ)設(shè)施資源，使他們專注于應(yīng)用的管理運維。容器云平臺基

于云管的抽象定義并提供集群、資源分區(qū)、節(jié)點、CPU、內(nèi)存、存儲

等資源供租戶按需使用。容器云平臺也可以根據(jù)配置規(guī)則在資源不足

時自動擴展資源，并同時告警提醒，以提醒租戶管理員和平臺管理員

能及時地檢查并更改資源分配。

基礎(chǔ)設(shè)施資源的維護和納管不是在容器云平臺來實現(xiàn)，而是由多

云管理平臺來實現(xiàn)。容器云平臺（定位于輕量化Paas）只是使用標

準化基礎(chǔ)設(shè)施資源而不維護資源。多云管理平臺維護管理私有云、公

有云、內(nèi)部物理服務(wù)器、存儲、網(wǎng)絡(luò)、超融合等資源，通過多云管理

平臺提供標準化的資源服務(wù)。這樣也清晰的定位了云管平臺和容器云

平臺的職責，在企業(yè)內(nèi)構(gòu)建容器云平臺和使用內(nèi)外部不同類型的私

有、公有云資源時，整個一個云運維架構(gòu)結(jié)構(gòu)清晰、職責明確、功能

范圍合理，容易理解和構(gòu)建。

1.多云（laaS）管理平臺

市面上多云管理平臺幾乎包含了云計算的三層能力，導致不少企

業(yè)在建設(shè)云平臺時依然面臨著單體、重復建設(shè)等問題。不得不在公司

內(nèi)部建設(shè)不少朵云，這些云往往難以融合，這是一個很大的問題。因

此，云平臺的建設(shè)一定需要考慮分層。

從目前云市場的現(xiàn)狀來看，更多的還是提供基礎(chǔ)設(shè)施資源服務(wù)和

SaaS服務(wù)。PaaS服務(wù)很不容易。PaaS可以認為是云操作系統(tǒng)，提供

操作系統(tǒng)級的平臺服務(wù)。從實際的需求出發(fā)，為更好的服務(wù)于企業(yè)業(yè)

務(wù)應(yīng)用生命周期管理，界定多云管理平臺的能力。把多云管理平臺劃

6/18

歸于laaS層，而不是跨云計算多層能力，這就比較清晰的定義了云

管平臺的能力和功能范圍。云管平臺的職責是納管laaS層的不同類

型的資源，抽象并輸出標準化資源服務(wù)。而平臺服務(wù)(PaaS)和應(yīng)用

服務(wù)(SaaS)不在云管平臺實現(xiàn)。比如應(yīng)用部署、中間件服務(wù)等。應(yīng)

用管理和中間件管理都是在PaaS層,而PaaS則支撐SaaS層服務(wù)，

比如消息服務(wù)、財務(wù)服務(wù)等。應(yīng)用部署時由PaaS平臺調(diào)度云管平臺

提供的標準化資源，比如，可以把應(yīng)用調(diào)度到阿里云、騰訊云、或者

華為云，這項調(diào)度是由PaaS平臺來實現(xiàn)的，調(diào)用云管平臺抽象封裝

過的阿里云、騰訊云或者華為云的標準化資源服務(wù)。

所以，為更好的支撐業(yè)務(wù)應(yīng)用，需要明確多云管理平臺是管理不

同的laaS云資源，包括私有化基礎(chǔ)設(shè)施資源。它不應(yīng)跨層去管應(yīng)用

或者提供SaaS服務(wù)。

2.資源分區(qū)

資源分區(qū)是我們抽象定義的一個資源管理對象。目的是為了給容

器云平臺提供標準化資源服務(wù)?；A(chǔ)設(shè)施資源可以來自于公有云、私

有云、虛擬化、物理服務(wù)器、各種存儲、不同的網(wǎng)絡(luò)類型等。通過資

源分區(qū)抽象之后，把不同類型的資源都劃分為一個個標準化的資源分

區(qū)，分配給租戶，租戶按需部署調(diào)度應(yīng)用服務(wù)到相應(yīng)云資源分區(qū)中，

實現(xiàn)業(yè)務(wù)部署需求。

(二)應(yīng)用運維

7/18

容器云平臺提供平臺級的服務(wù)能力，為業(yè)務(wù)應(yīng)用的部署、運行、

監(jiān)控、升級、維護等提供平臺支撐。應(yīng)用管理和維護是容器云平臺功

能實現(xiàn)的核心。

容器云平臺建設(shè)的目的是為了支撐企業(yè)業(yè)務(wù)應(yīng)用，實現(xiàn)業(yè)務(wù)應(yīng)用

微服務(wù)化的統(tǒng)一平臺部署和運維管理。把容器云平臺建設(shè)成為企業(yè)級

應(yīng)用管理平臺，采用微服務(wù)架構(gòu)，實現(xiàn)業(yè)務(wù)應(yīng)用的整合與重構(gòu)、快速

響應(yīng)業(yè)務(wù)需求。因此，容器云平臺應(yīng)用管理是其核心功能。

應(yīng)用運維包括應(yīng)用的部署、運行、彈性伸縮、灰度發(fā)布、運行時

監(jiān)控、運行時配置更新、升級、服務(wù)管理與管理、租戶隔離等。

1.租戶隔離

多租戶的設(shè)計既可以滿足不同業(yè)務(wù)場景合規(guī)上的隔離要求，也可

以根據(jù)業(yè)務(wù)需要進行業(yè)務(wù)租戶的整合和分離部署管理。

由于Kubernetes并沒有租戶的概念，因此不同的容器云平臺對

租戶的定義可能是不一樣的。有的租戶對應(yīng)Kubernetes的

namespace,有的則獨立于Kubernetes的單獨對象。基于我們的容器

云平臺架構(gòu)，在平臺層定義租戶，一個租戶下可以管理一到多個應(yīng)用，

每一個應(yīng)用對應(yīng)于Kubernetes的一個namespaceo每一個租戶有租

戶資源限額，為了支持應(yīng)用下服務(wù)實例的彈性伸縮需求，namespace

則不做資源限額控制。

2.持續(xù)部署

持續(xù)部署并不適合所有應(yīng)用場景，因此是否需要實現(xiàn)持續(xù)部署能

力，要根據(jù)業(yè)務(wù)需求來確定。持續(xù)部署更多可能在測試環(huán)境，快速部

8/18

署應(yīng)用服務(wù)滿足bug修復驗證、回歸測試等要求。傳統(tǒng)企業(yè)生產(chǎn)環(huán)境

往往追求的是穩(wěn)定，和互聯(lián)網(wǎng)企業(yè)是不一樣的，因此在設(shè)計實現(xiàn)運維

架構(gòu)和運維能力的時候也要從實際需求出發(fā)來確定。

3.彈性伸縮

彈性伸縮是容器云的重要特性，也是采用容器云的重要原因。我

們定義應(yīng)用管理為應(yīng)用、服務(wù)、實例三層對象管理機制，實例運行在

容器中，是支持分價式部署的微服務(wù)實例，借助容器的特性和規(guī)則定

義可以實現(xiàn)微服務(wù)實例的彈性伸縮。

4.灰度發(fā)布

灰度發(fā)布能力主要用來驗證新版本的功能，導入或者復制部份實

際流量來實現(xiàn)生產(chǎn)驗證?；诜?wù)管理的兩層負載分發(fā)能力，可以根

據(jù)需要在API網(wǎng)關(guān)層或者容器云平臺層進行流量分導和分發(fā)。

5.運行時監(jiān)控

應(yīng)用服務(wù)運行時的狀態(tài)、流量、資源使用量、響應(yīng)時間等是判斷

業(yè)務(wù)應(yīng)用實例運行狀況的依據(jù)。實時的數(shù)據(jù)采集和展示是應(yīng)用服務(wù)運

行時監(jiān)控和管理的基礎(chǔ)。容器云平臺的平臺層對容器運行時數(shù)據(jù)采集

和存儲及處理，為業(yè)務(wù)應(yīng)用服務(wù)的管理和維護提供了數(shù)據(jù)支持，也為

持續(xù)的監(jiān)控管理及趨勢分析提供了數(shù)據(jù)基礎(chǔ)。

6.服務(wù)運行時配置動態(tài)更新

業(yè)務(wù)應(yīng)用服務(wù)運行時配置的動態(tài)更新是應(yīng)用敏捷運維的要求。在

不需要重新部署應(yīng)用的情況下，通過配置中心配置的更改，下發(fā)給業(yè)

9/18

務(wù)服務(wù)實現(xiàn)自動配置更新，對于特殊環(huán)境或者情況下無法重啟應(yīng)用或

者

9/18

者服務(wù)，就顯得非常重要了。例如某些情況下，需要打開應(yīng)用服務(wù)的

debug日志，如果重啟服務(wù)則可能無法重現(xiàn)當前異常，如果能支持運

行時配置動態(tài)更新，則會方便的多。

7.升級/多集群容災(zāi)

升級包括平臺升級和應(yīng)用服務(wù)升級。容器云平臺多集群設(shè)計一個

重要的需求場景就是平臺升級不會影響業(yè)務(wù)的運行，對客戶不可見。

同時支持業(yè)務(wù)應(yīng)用的容災(zāi)備份需求，可以部署應(yīng)用服務(wù)到位于不同機

房或者數(shù)據(jù)中心的集群中，滿足業(yè)務(wù)多地多中心的容災(zāi)備份要求。

8.服務(wù)管理雙層體系

服務(wù)管理實現(xiàn)容器云平臺層和API網(wǎng)關(guān)層雙層服務(wù)管理能力，在

容器云平臺借助容器的特性實現(xiàn)服務(wù)的注冊、負載均衡、灰度、自愈、

彈性伸縮、容災(zāi)備份、鏈路跟蹤、拓撲展示、日志、監(jiān)控等能力，在

API網(wǎng)關(guān)層則實現(xiàn)服務(wù)的認證、訪問控制、路由分發(fā)、轉(zhuǎn)換、過濾、

限流、熔斷、訪問統(tǒng)計等能力。

（三）平臺運維

把容器云平臺自身的運維單獨拿出來簡單說幾句。應(yīng)用、容器云

平臺和基礎(chǔ)設(shè)施資源的關(guān)系是平臺使用基礎(chǔ)設(shè)施資源支撐業(yè)務(wù)應(yīng)用。

通常容器云平臺自身運維也比較簡單，沒有太多工作量，主要是平臺

運行狀態(tài)的監(jiān)控和組件的維護、升級事項。

1.多集群

10/18

容器云多集群場景下部署架構(gòu)可能是不一樣，無非多集群運維基

本相同。集群的部署、節(jié)點的維護、集群運行監(jiān)控、集群升級等是日

常的運維工作內(nèi)容。

2.中間件

容器云平臺很重要的一個能力是提供中間件平臺化能力，比如消

息通信、數(shù)據(jù)存儲、日志采集及處理等。在容器云平臺測試環(huán)境，為

支撐快速敏捷構(gòu)建業(yè)務(wù)場景測試環(huán)境，選擇容器云平臺上的服務(wù)組件

（中間件）如kafka>redis>mysql>rabbitmq、jenkins>git等實

現(xiàn)一鍵部署和回收，保證環(huán)境的一致性和無污染性。

三、應(yīng)用運維服務(wù)管理雙層架構(gòu)

應(yīng)用管理能力是容器云平臺的核心能力。主要實現(xiàn)應(yīng)用服務(wù)的部

署、運行、監(jiān)控、升級、維護、管理等運維能力。在應(yīng)用服務(wù)的管理

架構(gòu)設(shè)計上，為了充分利用容器的特性和特點，同時兼顧不同業(yè)務(wù)的

穩(wěn)定性等需求，我們定義了應(yīng)用運維的兩層管理體系，一是利用容器

云平臺的服務(wù)管理能力，充分發(fā)揮容器輕量、彈性、無狀態(tài)等特性；

二是利用API網(wǎng)關(guān)管理全局API和OpenAPI接口的能力，實現(xiàn)API的

全局的服務(wù)管理能力。

（一）容器云平臺層

容器云平臺基于Kubernetes的能力基礎(chǔ)上，實現(xiàn)對Kubernetes

的封裝和擴展，在Kubernetes之上實現(xiàn)了PaaS平臺層能力，更好的

支撐業(yè)務(wù)應(yīng)用服務(wù)管理和管理需求。Kubernetes提供了容器服務(wù)的

部署、運行、調(diào)度、注冊、路由分發(fā)等能力，但在服務(wù)管理方面也有

11/18

一定的局限性，比如按照服務(wù)的響應(yīng)時間進行流量分發(fā)，如果沒有平

臺層則比較難以實現(xiàn)。惟獨在平臺層記錄了請求的響應(yīng)時間，才干對

比不同實例的處理能力，才干將更多的請求分發(fā)給響應(yīng)快的服務(wù)實

例。而不是默認輪詢的方式，可能導致某個實例壓力大而浮現(xiàn)超時等

問題。同時還有限流、熔斷等都可以在容器云平臺層實現(xiàn)，而不用在

服務(wù)代碼中實現(xiàn)。

容器云平臺“三視角、四層次、一閉環(huán)”的架構(gòu)很好的滿足了應(yīng)

用開辟、運維的需求。也為服務(wù)的管理、管理提供了良好的架構(gòu)支撐。

（二）API網(wǎng)關(guān)層

API網(wǎng)關(guān)提供了一層穩(wěn)定的可重用接口層。API網(wǎng)關(guān)在ESB時代

就已經(jīng)廣泛應(yīng)用于對外集成API的管理和管理。微服務(wù)架構(gòu)使API網(wǎng)

關(guān)的作用越來越重要。其非但可以對外提供安全的OpenAPI服務(wù)，同

樣也可以在企業(yè)內(nèi)部實現(xiàn)內(nèi)部API的管理和管理。

API網(wǎng)關(guān)同時可以提供安全的保護能力，阻撓客戶端應(yīng)用以非安

全和非管理的方式直接訪問API,保護企業(yè)內(nèi)外開放的應(yīng)用接口APE

這是API網(wǎng)關(guān)最重要的能力之一。同時API網(wǎng)關(guān)也隔離內(nèi)外服務(wù)也就

減少了對外暴露服務(wù)的可能性，增加了系統(tǒng)的安全性?？梢栽贏PI接

口層實現(xiàn)授權(quán)認證、訪問控制、防范威脅和0WASP漏洞、謹防性緩存、

通過SSP和統(tǒng)一身份管理等方法來提高安全性，為應(yīng)用程序、挪移和

IoT提供端到端的安全機制。也可能需要在API網(wǎng)關(guān)實現(xiàn)流量控制、

分流、過濾、熔斷、服務(wù)優(yōu)先級控制、超時處理、負載均衡等機制來

保護應(yīng)用服務(wù)的安全。

12/18

將安全、訪問控制等非業(yè)務(wù)邏輯功能從微服務(wù)設(shè)計實現(xiàn)中分離出

來，也使微服務(wù)的設(shè)計和實現(xiàn)簡化，使微服務(wù)更輕盈、更便捷。這是

我們在做微服務(wù)設(shè)計時很重要的一個考量點，也和容器云平臺部署微

服務(wù)時充分利用容器輕量的特點相匹配。

從API網(wǎng)關(guān)的定位和能力來看，主要可以在網(wǎng)關(guān)層實現(xiàn)微服務(wù)的

安全認證及訪問控制（包括路由、轉(zhuǎn)換、流量控制等），同時API網(wǎng)

關(guān)也提供注冊發(fā)現(xiàn)、日志記錄、流量監(jiān)控、服務(wù)編排、負載均衡等能

力。利用這些能力，可以便利的實現(xiàn)微服務(wù)的管理，天然融合，無需

再開辟或者部署一套微服務(wù)管理平臺或者工具，也不用為不同平臺之

間的集成花費人力物力財力和珍貴的時間。

四、周邊支撐體系

目前配合容器化PaaS平臺建設(shè)的基礎(chǔ)上，已經(jīng)規(guī)劃或者正在推

進集中日志中心平臺、統(tǒng)一身份認證和權(quán)限平臺、kafka消息平臺、

配置中心、注冊中心、統(tǒng)一監(jiān)控平臺、APM等基礎(chǔ)技術(shù)中臺支撐平臺

的建設(shè)。

（一）統(tǒng)一身份認證和權(quán)限中心

統(tǒng)一身份認證平臺實現(xiàn)企業(yè)員工和企業(yè)業(yè)務(wù)客戶兩級身份管理

認證能力，支持多種認證方式、多因子認證和單點登錄。權(quán)限中心則

實現(xiàn)員工和用戶的基于角色的系統(tǒng)和應(yīng)用的安全訪問控制準入機制

（RBAC）o企業(yè)新建系統(tǒng)和應(yīng)用通過統(tǒng)一身份認證和權(quán)限中心提供的

13/18

標準化API,實現(xiàn)登錄認證和訪問控制的統(tǒng)一管理。避免重復建設(shè)和

浪費，更節(jié)省時間，實現(xiàn)敏捷響應(yīng)。

身份認證和權(quán)限管理是所有系統(tǒng)的必需組件，因此首先規(guī)劃和構(gòu)

建統(tǒng)一身份認證和權(quán)限中心平臺是關(guān)鍵的第一步。

（二）集中日志中心

集中日志中心實現(xiàn)對企業(yè)內(nèi)應(yīng)用、系統(tǒng)、工具、平臺等所產(chǎn)生的

日志的統(tǒng)一標準化采集、分類、存儲，提供查詢、搜索、分析等服務(wù)

能力，可結(jié)合大數(shù)據(jù)平臺數(shù)據(jù)處理和分析能力、人工智能平臺機器學

習、模型構(gòu)建、模型訓練等能力，逐步實現(xiàn)企業(yè)級智能化監(jiān)控和運維

能力。

（三）配置中心

配置中心實現(xiàn)企業(yè)業(yè)務(wù)應(yīng)用和平臺、工具配置文件和配置信息的

統(tǒng)一管理，以支持業(yè)務(wù)應(yīng)用的運行時實時更新能力，減少應(yīng)用和系統(tǒng)

重啟所帶來的影響，更提升敏捷的響應(yīng)能力。

（四）統(tǒng)一監(jiān)控中心

統(tǒng)一監(jiān)控中心實現(xiàn)應(yīng)用和系統(tǒng)的全鏈路監(jiān)控和跟蹤。可以規(guī)劃兩

層監(jiān)控體系：基礎(chǔ)設(shè)施資源監(jiān)控層和APM（Applicationperformance

Monitor）層，實現(xiàn)業(yè)務(wù)應(yīng)用監(jiān)控信息的實施下鉆鉆取能力。

1.基礎(chǔ)設(shè)施資源監(jiān)控

基礎(chǔ)設(shè)施資源監(jiān)控要實現(xiàn)對基礎(chǔ)設(shè)施資源的運行狀況、資源占用

等情況進行分層分類采集，以支持應(yīng)用和服務(wù)的運行時監(jiān)控鉆取能力

2.APM

14/18

APM實現(xiàn)對業(yè)務(wù)應(yīng)用和服務(wù)的運行狀況進行監(jiān)控，同時根據(jù)應(yīng)用

運行所在節(jié)點資源使用情況，跟蹤分析、定位應(yīng)用和服務(wù)運行過程中

的異常，預警潛在的異常問題，保證業(yè)務(wù)應(yīng)用和服務(wù)的良好運行。

3.告警

短信、郵件、微信等告警渠道配合監(jiān)控體系，及時通知相關(guān)運維

人員進行檢查和維護。

（五）消息中心

消息中心實現(xiàn)消息中間件能力，提供消息交換機制API接口，目

前在用的TIBCOEMS和kafka工具提供消息中轉(zhuǎn)服務(wù)。同時可能需要

考慮構(gòu)建端到端消息通信機制。在企業(yè)內(nèi)多種消息平臺可能需要并

存，并根據(jù)業(yè)務(wù)場景選擇合適的消息處理機制。

1.Kafka平臺

Kafka支持大量消息并行處理，適合處理應(yīng)用、系統(tǒng)日志類消息。

不適合消息順序處理場景。Kafka消息通過server中轉(zhuǎn)，對于消息

延遲比較小的場景可能也不合適。

2.JMS平臺

JMS消息中間件也比較多,比如商用的TIBCOEMS.IBMMQ等，

開源的RabbitMQ>ActiveMQ等，都提供穩(wěn)定的輕量級JMS消息服

務(wù)。JMS消息中間件提供簡單易用、穩(wěn)定的發(fā)布定閱和請求應(yīng)答消息

處理機制，相對輕量。延遲通常在毫秒級，普通業(yè)務(wù)可以滿足需求。

3.端到端消息平臺

15/18

端到端消息處理平臺實現(xiàn)了消息在兩端之間的通信，延遲小，通

常在微秒級，特定場景可以達納秒級，適合極低延遲需求業(yè)務(wù)場景。

例如TIBCOFTL,Solace等。

五、容器云平臺運維典型問題案例

容器云平臺架構(gòu)和運維架構(gòu)盡管很清晰，但運維過程中依然會遇

到各種各樣的問題，比如資源碎片的問題、資源爭搶的問題、多集群

部署問題、不同環(huán)境需求和定位問題等等。

（一）部署運維資源碎片問題

每一個容器或者每一個Kubernetespod就是一個獨立的整體。

分配給該容器或者pod的資源其他容器或者pod是不可以共享的。

而每一個容器節(jié)點資源總是有一定限量的。如果pod的資源分配不

合理，就可能導致容器節(jié)點的資源雖有剩余卻無法調(diào)度更多pod運

行，導致資源碎片的產(chǎn)生。

而且不同的應(yīng)用服務(wù)需要的資源類型也可能是不一樣的。比如有

需要CPU優(yōu)化的、有需要內(nèi)存優(yōu)化的、有需要存儲有優(yōu)化的等。雖然

說通用的資源類型可以滿足大部份需求，但不同的資源類型需求也或

者導致一些資源的碎片和浪費。特殊是容器