基于容器技術(shù)構(gòu)建一站式業(yè)務(wù)支撐平臺方案

1、 基于容器技術(shù)構(gòu)建一站式業(yè)務(wù)支撐平臺方案 【導(dǎo)讀】本方案是“2020容器云職業(yè)技能大賽”團(tuán)隊(duì)比賽冠軍團(tuán)隊(duì)的作品。為大家呈現(xiàn)了容器平臺較全面的體系化建設(shè)的方方面面：包括承載應(yīng)用運(yùn)行時(shí)的集群建設(shè)，多集群管理平臺的架構(gòu)，PaaS服務(wù)的建設(shè)，DevOps應(yīng)用全生命周期管理，以及為標(biāo)準(zhǔn)化與大規(guī)模推廣服務(wù)的規(guī)范指引的建設(shè)。每個(gè)部分都有詳細(xì)的設(shè)計(jì)與介紹，為企業(yè)建設(shè)一站式業(yè)務(wù)支撐平臺提供了一個(gè)好的參考。1 建設(shè)背景隨著互聯(lián)網(wǎng)的興起，互聯(lián)網(wǎng)企業(yè)依托互聯(lián)網(wǎng)，特別是移動互聯(lián)網(wǎng)為公眾提供越來越多方便快捷、穩(wěn)定高效的服務(wù)，對傳統(tǒng)業(yè)務(wù)帶來了很大沖擊。作為應(yīng)對，傳統(tǒng)行業(yè)也在業(yè)務(wù)上不斷創(chuàng)新，帶來對IT基礎(chǔ)設(shè)施和應(yīng)用架構(gòu)方面進(jìn)

2、行轉(zhuǎn)型升級的要求。例如為了支撐電商促銷活動對帶來的高峰期海量支付請求，某銀行很早就對支付渠道相關(guān)業(yè)務(wù)應(yīng)用進(jìn)行微服務(wù)架構(gòu)改造，由此帶來了容器技術(shù)的研究和運(yùn)用。經(jīng)多年實(shí)踐證明，采用容器技術(shù)平臺很好地支撐了新的業(yè)務(wù)模式和業(yè)務(wù)容量。基于業(yè)務(wù)發(fā)展的需要，和快速進(jìn)步的金融科技技術(shù)，越來越多的傳統(tǒng)企業(yè)開始思考自身的互聯(lián)網(wǎng)戰(zhàn)略、上云規(guī)劃等。其中重要內(nèi)容之一，是希望從技術(shù)層面更有效地支持業(yè)務(wù)創(chuàng)新，如微服務(wù)架構(gòu)、更好的靈活性、擴(kuò)展性、高可用性、更高效的業(yè)務(wù)上線效率等，因此跟上云計(jì)算技術(shù)發(fā)展的趨勢，建設(shè)并推廣適合自身的基于容器技術(shù)的云平臺是關(guān)鍵任務(wù)。2 需求分析2.1 業(yè)務(wù)需求2.1.1 應(yīng)用架構(gòu)改造需求某銀行的客

3、戶交互渠道系統(tǒng)存在以下兩點(diǎn)架構(gòu)問題，制約了其快速迭代，影響了用戶體驗(yàn)：第一，豎井式系統(tǒng)架構(gòu)，各模塊各自開發(fā)和管理基礎(chǔ)功能，存在大量重復(fù)開發(fā)工作；第二，非分布式架構(gòu)，橫向擴(kuò)展效率低。為了縮短系統(tǒng)的迭代周期，增強(qiáng)橫向擴(kuò)展能力，該渠道需要運(yùn)用DDD思想，重構(gòu)一套使用微服務(wù)架構(gòu)的新系統(tǒng)。本文設(shè)計(jì)了一套基于容器的一站式業(yè)務(wù)支撐平臺解決方案，用于部署該渠道系統(tǒng)的微服務(wù)版本。2.1.2 應(yīng)用架構(gòu)概要設(shè)計(jì)基于微服務(wù)架構(gòu)的新系統(tǒng)，將服務(wù)端在邏輯上分為業(yè)務(wù)域和通用服務(wù)域，業(yè)務(wù)域是面向客戶的交互界面，主要功能是整合微服務(wù)向前端提供統(tǒng)一的交互視圖；通用服務(wù)域是從各業(yè)務(wù)領(lǐng)域提煉出來的通用服務(wù)的集合，與業(yè)務(wù)域解耦，只提供

4、單一的服務(wù)輸出即原子服務(wù)，業(yè)務(wù)域可整合不同的通用域服務(wù)單元完成相應(yīng)的業(yè)務(wù)邏輯處理，同時(shí)通用域還包含與業(yè)務(wù)無關(guān)的后臺處理模塊。圖 1 業(yè)務(wù)設(shè)計(jì)示意圖2.2 建設(shè)企業(yè)級容器平臺容器平臺作為企業(yè)的新一代IT基礎(chǔ)設(shè)施，不僅需要為基于微服務(wù)架構(gòu)的新業(yè)務(wù)提供容器化運(yùn)行和管控平臺之外，還必須非常重視安全需求。因此建設(shè)容器平臺的需求時(shí)，需要考慮包括的方面有： 管理大規(guī)模容器集群能力，包括：提供容器所需的高可用集群、資源池管理、網(wǎng)絡(luò)通信方案、存儲方案、編排調(diào)度引擎、微服務(wù)運(yùn)行框架、鏡像管理、事件告警、集群監(jiān)控和日志收集等。 為滿足安全要求，平臺需要考慮應(yīng)用的高可用性和業(yè)務(wù)連續(xù)性、多租戶安全隔離、不同等級業(yè)務(wù)隔離

5、、防火墻策略、安全漏洞掃描、鏡像安全、后臺運(yùn)維的4A納管、審計(jì)日志；如果容器平臺還對公網(wǎng)提供訪問，那么還需要考慮訪問鏈路加密、安全證書等。另外，一個(gè)重要方面是，容器平臺通常是企業(yè)IT整個(gè)復(fù)雜系統(tǒng)中的一部分，因此容器平臺還要遵從企業(yè)已有IT技術(shù)規(guī)范和運(yùn)維要求，例如可能還需要考慮： 支持企業(yè)自身的應(yīng)用發(fā)布體系、持續(xù)集成系統(tǒng)、應(yīng)用建模規(guī)范、高可用管理策略。 對接云計(jì)算底層資源池（例如IaaS），遵從云計(jì)算資源的統(tǒng)一管理和分配。 對接或改造容器平臺的網(wǎng)絡(luò)，以滿足容器平臺中應(yīng)用與傳統(tǒng)虛擬機(jī)、物理機(jī)中舊業(yè)務(wù)系統(tǒng)的相互通信，避免或盡可能減少對企業(yè)現(xiàn)有網(wǎng)絡(luò)管理模式的沖擊。 對接統(tǒng)一身份驗(yàn)證、和整個(gè)金融云其它系

6、統(tǒng)采用統(tǒng)一的租戶定義、角色定義、資源配額定義等。 對接漏洞掃描、集中監(jiān)控系統(tǒng)、日志分析系統(tǒng)等已有周邊系統(tǒng)。2.3 基于容器平臺構(gòu)建DevOps體系業(yè)務(wù)市場競爭加劇，業(yè)務(wù)部門要求業(yè)務(wù)快速交付，業(yè)務(wù)系統(tǒng)就要充分復(fù)用其它業(yè)務(wù)應(yīng)用系統(tǒng)服務(wù)： 作為業(yè)務(wù)部門，綜合著眼關(guān)注業(yè)務(wù)進(jìn)度，不關(guān)注需求之外的其它交付內(nèi)容。 作為開發(fā)部門，期待資源得倒?jié)M足，需求明確，交付內(nèi)容清晰，項(xiàng)目計(jì)劃到位，資源充足，時(shí)間充裕；如何以更有效的方法進(jìn)行需求調(diào)研，更好的架構(gòu)進(jìn)行開發(fā)，更有效率的測試策略及項(xiàng)目管理方式。 云資源交付部門，期待資源容量評估、架構(gòu)評估、交付內(nèi)容完整、時(shí)間寬裕、安全合規(guī)。 安全部門，所有各個(gè)階段嚴(yán)格按照網(wǎng)絡(luò)規(guī)范實(shí)

7、施交付，并配以持續(xù)監(jiān)測和更新到最新安全機(jī)制。 運(yùn)維部門，期待支撐所有交付均考慮運(yùn)維體系完備性，基于主機(jī)和服務(wù)兩個(gè)維度、不同對象目標(biāo)的運(yùn)維體系完備；所有運(yùn)維數(shù)據(jù)均可以共享互訪并使用。關(guān)注在業(yè)務(wù)場景下，對于容器平臺及DevOps要求的需求上，還包括彈性要求、高可用要求、快速交付、需求變化要求等。在Kubernetes和容器普及之前，我們通過虛擬機(jī)也可以實(shí)現(xiàn)DevOps，只是速度相對較慢，因此普及性不高（想象一下通過x86虛擬化來實(shí)現(xiàn)中間件集群彈性伸縮的效率）。而正是容器的出現(xiàn)，為DevOps工具層面的落地提供非常好的承載平臺： 容器云平臺，需要DevOps以標(biāo)準(zhǔn)化和提升IT研發(fā)和交付能力。DevO

8、ps可以部署在容器云平臺上。 基于容器化PaaS平臺的DevOps，可以使用容器云的資源，譬如DevOps平臺的相關(guān)技術(shù)組件，可以以容器方式部署在容器云上，以支持多pipeline流水線并發(fā)編譯所需要的彈性資源。Openshift以容器技術(shù)和Kubernetes為基礎(chǔ)，在此之上擴(kuò)展提供了軟件定義網(wǎng)絡(luò)、軟件定義存儲、權(quán)限管理、企業(yè)級鏡像倉庫、統(tǒng)一入口路由、持續(xù)集成流程（ S2I/Jenkins ）、統(tǒng)一管理控制臺、監(jiān)控日志等功能，形成覆蓋整個(gè)軟件生命周期的解決方案，實(shí)現(xiàn)DevOps落地效率比較高。3 設(shè)計(jì)架構(gòu)3.1 整體設(shè)計(jì)一站式開發(fā)交付運(yùn)行平臺提供持續(xù)集成、自動部署、彈性伸縮、高可用、監(jiān)控告警

9、、微服務(wù)治理等特性，解決互聯(lián)網(wǎng)業(yè)務(wù)爆發(fā)性強(qiáng)，難預(yù)測，響應(yīng)要求高，需求變化快的的特點(diǎn)，為應(yīng)用提供全生命周期的支撐管理能力，從業(yè)務(wù)需求管理、應(yīng)用開發(fā)、持續(xù)構(gòu)建、持續(xù)部署到應(yīng)用運(yùn)維保障。圖 2 一站式開發(fā)交付容器平臺整體架構(gòu)3.1.1 容器平臺 基礎(chǔ)設(shè)施IT基礎(chǔ)設(shè)施為平臺提供計(jì)算、網(wǎng)絡(luò)、存儲、安全等資源，支持物理機(jī)、虛擬化、私有云和公有云等多種環(huán)境。 容器引擎Docker平臺使用Docker作為容器引擎層。容器技術(shù)是一種進(jìn)程隔離技術(shù)，它通過namespace/cgroup等技術(shù)從內(nèi)核空間、資源和安全等方面對進(jìn)程做隔離。因?yàn)槿萜魇沁M(jìn)程級別的，所以它非常輕量，能夠?qū)崿F(xiàn)秒級啟動。另外容器鏡像將運(yùn)行環(huán)境與應(yīng)

10、用一起打包，實(shí)現(xiàn)了一處構(gòu)建，處處部署，為應(yīng)用的交付與運(yùn)維管理提供了一種標(biāo)準(zhǔn)的方式。Docker是目前使用最為廣泛的容器引擎，已被大規(guī)模生產(chǎn)環(huán)境驗(yàn)證。 容器編排層Openshift平臺使用Openshift作為容器編排層，Openshift基于業(yè)界容器編排標(biāo)準(zhǔn)Kubernetes技術(shù)，并在安全性上進(jìn)行了增強(qiáng)，同時(shí)為了方便開發(fā)者使用容器技術(shù)，對應(yīng)用的構(gòu)建與部署等集成方面也做了功能的增加，有助于快速構(gòu)建一個(gè)功能全面的容器平臺。作為容器編排引擎，Openshift具備全面的編排相關(guān)的功能：應(yīng)用編排、應(yīng)用部署、應(yīng)用配置、應(yīng)用升級、負(fù)載均衡、彈性伸縮、健康檢查、權(quán)限管理、容器網(wǎng)絡(luò)、網(wǎng)絡(luò)存儲等；除此之外，O

11、penshift還提供了更全面的管理功能，如應(yīng)用構(gòu)建、日志中心、資源監(jiān)控，應(yīng)用商店等。但是Openshift自帶的運(yùn)維管理功能有它的局限性，平臺將會對其日志中心、資源監(jiān)控等功能進(jìn)行全面擴(kuò)展與增強(qiáng)。 PaaS服務(wù)平臺基于Openshift之上，采用Operator技術(shù)實(shí)現(xiàn)的可擴(kuò)展PaaS服務(wù)（包括數(shù)據(jù)庫、消息隊(duì)列、緩存、反向代理等中間件服務(wù)）。Operator為PaaS服務(wù)提供構(gòu)建、擴(kuò)展、監(jiān)控、備份等能力。研發(fā)與運(yùn)維人員只需要在平臺門戶進(jìn)行提交表單，就能方便快速地構(gòu)建高成熟度中間件服務(wù)。 容器平臺門戶平臺基于Openshift和Docker容器技術(shù)，并與DevOps支撐平臺進(jìn)行集成，提供面向應(yīng)用

12、全生命周期管理的企業(yè)級PaaS云解決方案。提供對平臺與應(yīng)用服配置、部署、運(yùn)維及管理能力；支持多數(shù)據(jù)中心、多集群、多租戶、多項(xiàng)目等多個(gè)維度管理；與DevOps平臺集成，實(shí)現(xiàn)一體化的持續(xù)構(gòu)建與部署的能力。3.1.2 DevOps支撐DevOps平臺提供了需求管理、CICD流水線、代碼配置管理、制品管理、質(zhì)量管控等功能，提供了從計(jì)劃到測試的問題持續(xù)集成過程，提供了從計(jì)劃到測試完成的過程持續(xù)發(fā)布過程，解決了從計(jì)劃到上線的持續(xù)部署過程，覆蓋了用戶提出價(jià)值到用戶使用并且監(jiān)控維護(hù)的端到端過程。通過DevOps平臺，實(shí)現(xiàn)了在制品的持續(xù)流動、持續(xù)反饋，進(jìn)行持續(xù)優(yōu)化，讓質(zhì)量持續(xù)提高。通過DevOps平臺，實(shí)現(xiàn)了研

13、發(fā)數(shù)據(jù)的度量管理，通過對團(tuán)隊(duì)的研發(fā)數(shù)據(jù)進(jìn)行定量分析，及時(shí)發(fā)現(xiàn)研發(fā)過程中的不足，有助于提高研發(fā)團(tuán)隊(duì)的效率和質(zhì)量。通過AIOPS的接入，通過對日志等數(shù)據(jù)的持續(xù)監(jiān)控，實(shí)現(xiàn)常見問題的自動化運(yùn)維，保證應(yīng)用的持續(xù)可用。3.1.3 運(yùn)維保障 資源管理通過開發(fā)Openshift管理門戶，實(shí)時(shí)管理集群資源使用現(xiàn)狀，通過記錄資源臺賬（記錄計(jì)算、存儲、網(wǎng)絡(luò)ip端口資源）的方式，記錄并預(yù)分配準(zhǔn)備上線的系統(tǒng)，保障集群配額充足，及時(shí)提出擴(kuò)容需求。租戶資源：通過ResourceQuotas對租戶資源進(jìn)行限制，以保障租戶間不相互影響。pod資源：通過LimitRange對pod和container資源進(jìn)行限制。 日志管理集群

14、日志統(tǒng)一由EFK組件收集、管理和展示，通過統(tǒng)一管理，大大提升了日志查找、故障排查的效率，同時(shí)Openshifi管理門戶也開發(fā)了日志的展示和查詢功能，實(shí)現(xiàn)了在掛歷門戶對集群故障的初步定位能力。 監(jiān)控告警除了集群內(nèi)部的Prometheus，還將集群資源使用情況、集群組件狀態(tài)、項(xiàng)目pod狀態(tài)等信息以標(biāo)準(zhǔn)格式輸出給集群外部的監(jiān)控工具，進(jìn)行統(tǒng)一管理、告警和展示，具備短信郵件等告警提醒等功能。 事件管理容器平臺上運(yùn)行著成千上萬個(gè)資源，每個(gè)資源在生命周期過程中狀態(tài)不斷變化，每一個(gè)狀態(tài)變化過程中都會涉及到多條事件信息，及時(shí)獲取到這些信息中有問題的部分能夠幫助項(xiàng)目最早時(shí)間發(fā)現(xiàn)問題，這就是事件管理的重要意義。本方

15、案中，將采用EventRouter收集平臺所有事件，對于異常事件會在第一時(shí)間通過告警平臺發(fā)出。 網(wǎng)絡(luò)管理網(wǎng)絡(luò)管理包括兩個(gè)部分：傳統(tǒng)網(wǎng)絡(luò)管理、集群內(nèi)部網(wǎng)絡(luò)管理。傳統(tǒng)網(wǎng)絡(luò)管理，主要集群內(nèi)外網(wǎng)絡(luò)訪問以及不同網(wǎng)絡(luò)區(qū)域之間底層網(wǎng)絡(luò)控制策略的管理，主要通過網(wǎng)絡(luò)防火墻策略的維護(hù)。集群內(nèi)部網(wǎng)絡(luò)管理，主要通過NetworkPolicy策略進(jìn)行控制。平臺支持圖形化配置該策略，為管理員提供良好的操作體驗(yàn)。 數(shù)據(jù)備份數(shù)據(jù)備份包括以下兩個(gè)方面：集群數(shù)據(jù)備份、應(yīng)用數(shù)據(jù)備份，其中集群數(shù)據(jù)備份包括有資源對象備份、證書與集群配置備份、集群Etcd數(shù)據(jù)庫全量備份。集群數(shù)據(jù)備份通過oc、Etcdctl命令客戶端及shell命令實(shí)現(xiàn)

16、資源對象、證書、配置及Etcd數(shù)據(jù)庫全量數(shù)據(jù)的備份與恢復(fù)。引入NBU（NetBackup）備份策略，為應(yīng)用持久化存儲做備份。Veritas NetBackup擁有Docker認(rèn)證，它能為應(yīng)用存儲提供高效、簡便、靈活的應(yīng)用備份解決方案。 巡檢機(jī)制通過編寫健康檢查腳本，對集群核心組件的健康狀態(tài)、核心組件運(yùn)行過程中的異常日志以及平臺的負(fù)載狀態(tài)等按日進(jìn)行巡檢，將高危風(fēng)險(xiǎn)以郵件形式發(fā)送給平臺運(yùn)維和研發(fā)人員，并及時(shí)分析處理，以確保平臺穩(wěn)定運(yùn)行。 集群升級平臺在日常運(yùn)維中將定期關(guān)注集群的最新補(bǔ)丁與漏洞報(bào)告，并及時(shí)對集群進(jìn)行升級，保證平臺的安全穩(wěn)定。3.2 非功能性設(shè)計(jì)圖 3 非功能性展示圖3.2.1 高可用

17、性平臺高可用性涉及到五個(gè)方面：集群高可用、應(yīng)用高可用、存儲高可用、網(wǎng)絡(luò)高可用以及制品庫高可用。 集群高可用集群的高可用主要有兩部分：單集群的高可用和多集群提供雙活服務(wù)兩個(gè)部分。單集群的高可用：控制節(jié)點(diǎn)是集群最核心的部分，其上面的組件均采用高可用部署：Etcd集群化部署、Master組件服務(wù)均為多副本部署。同時(shí)Master組件部署在支持自動遷移策略的虛擬機(jī)平臺，即當(dāng)?shù)讓游锢頇C(jī)發(fā)生宕機(jī)后，其上運(yùn)行的虛所機(jī)會自動漂移到備用節(jié)點(diǎn)，并且多個(gè)控制節(jié)點(diǎn)分散部署，進(jìn)一步提升集群的可靠性。雙活機(jī)制提升集群服務(wù)可靠性：在同一機(jī)房部署多套集群，集群業(yè)務(wù)互為備份，同時(shí)提供服務(wù)。 應(yīng)用高可用應(yīng)用高可用主要有兩部分：應(yīng)用

18、設(shè)計(jì)和應(yīng)用部署。應(yīng)用設(shè)計(jì)：應(yīng)用提供對應(yīng)的健康檢查接口，與容器平臺的檢查機(jī)制配合實(shí)現(xiàn)應(yīng)用自動恢復(fù)；容器平臺支持應(yīng)用生命周期控制，例如通過HTTP接口健康探測機(jī)制可實(shí)現(xiàn)故障的容器實(shí)例的自動重啟。應(yīng)用部署：應(yīng)用采用多集群多副本部署，容器具有輕量、啟動快速等特性能夠支持快速擴(kuò)容；平臺為應(yīng)用提供親和與反親和等調(diào)度策略，應(yīng)用部署可選擇合適的策略以提升應(yīng)用的可用性；容器平臺支持應(yīng)用滾動升級保證應(yīng)用升級過程中服務(wù)不中斷。 存儲高可用平臺為不同場景提供多種存儲方案。分布式存儲、本地存儲、共享存儲等都考慮多副本機(jī)制提高存儲的高可用性，并且對于重要數(shù)據(jù)基于NBU提供定時(shí)備份。 網(wǎng)絡(luò)高可用網(wǎng)絡(luò)高可用主要有兩部分：集群

19、底層網(wǎng)絡(luò)和集群內(nèi)部網(wǎng)絡(luò)。集群底層網(wǎng)絡(luò)：交換機(jī)、路由器等網(wǎng)絡(luò)設(shè)備采用雙活部署，主機(jī)雙網(wǎng)口綁定bond提供可靠的本地網(wǎng)絡(luò)；集群將數(shù)據(jù)網(wǎng)、業(yè)務(wù)網(wǎng)、管理網(wǎng)分離，減小不同網(wǎng)絡(luò)數(shù)據(jù)之的干擾。集群內(nèi)部網(wǎng)絡(luò)：集群提供多副本且支持流量分片的Ingress/Router節(jié)點(diǎn)，并通過高可用負(fù)載均衡器承載外部包括TCP、HTTP協(xié)議的請求流量。平臺提供全面的監(jiān)控體系，對網(wǎng)絡(luò)服務(wù)的異常進(jìn)行自動監(jiān)測與診斷，在滿足一定的條件下，實(shí)現(xiàn)網(wǎng)絡(luò)服務(wù)自動恢復(fù)。 制品庫高可用制品庫采用單地備份、多地同步的機(jī)制。單個(gè)制品庫的服務(wù)端采用多活的方案同時(shí)提供服務(wù)，底層數(shù)據(jù)則采用冷備方案對應(yīng)用鏡像進(jìn)行定期備份。同時(shí)平臺在各地分別部署制品庫，各地

20、制品庫通過之前的同步機(jī)制實(shí)現(xiàn)多地鏡像的同步，實(shí)現(xiàn)互為備份。3.2.2 易用性 可視化管理平臺提供了可視化管理界面，通過界面可以直觀地查看集群的狀態(tài)。同時(shí)對于應(yīng)用開發(fā)的整個(gè)生命周期都支持可視化，包括需求管理，開發(fā)流水線，應(yīng)用的測試報(bào)告，流水線度量指標(biāo)以及運(yùn)行狀態(tài)等。 自動化管理容器平臺部分提供自動化運(yùn)維工具，實(shí)現(xiàn)集群自動化部署、自動化升級、自動化備份、定期自動巡檢、服務(wù)及資源監(jiān)控告警。DevOps平臺部分，自動化流水線實(shí)現(xiàn)應(yīng)用的持續(xù)構(gòu)建，持續(xù)部署與持續(xù)監(jiān)控。 交互式操作平臺提供表單交互式，實(shí)現(xiàn)快速創(chuàng)建PaaS應(yīng)用以及應(yīng)用部署。 多集群管理研發(fā)人員通過一個(gè)入口就可以管理多中心多集群，實(shí)現(xiàn)多集群統(tǒng)一

21、管理，同時(shí)權(quán)限與用戶集中化管理，方便容器平臺的使用。 多系統(tǒng)集成與監(jiān)控告警平臺、日志平臺、DevOps平臺等系統(tǒng)集成，實(shí)現(xiàn)一站式應(yīng)用全生命周期的支撐。 多租戶管理平臺具有豐富的用戶與權(quán)限管理，支持細(xì)粒度的權(quán)限控制以滿足更多的安全控制的要求。3.2.3 安全性平臺從主機(jī)、容器、平臺自身、鏡像、網(wǎng)絡(luò)、應(yīng)用及數(shù)據(jù)等方面構(gòu)建全面的容器安全體系，保障平臺及應(yīng)用的安全。 主機(jī)主機(jī)操作系統(tǒng)安全加固；系統(tǒng)安全補(bǔ)丁管理機(jī)制；針對不同安全要求主機(jī)劃進(jìn)行分組管理，不同組的應(yīng)用間物理隔離。 容器容器引擎漏洞管理；容器最小權(quán)限原則，禁用root等用戶；容器資源限制；容器日志分析與審計(jì)；CIS容器配置基準(zhǔn)保證。 平臺基于

22、RBAC的權(quán)限管理；平臺升級機(jī)制，修復(fù)平臺漏洞；平臺運(yùn)行日志分析與審計(jì)；CIS平臺配置基準(zhǔn)保證。 鏡像制定安全標(biāo)準(zhǔn)鏡像作為應(yīng)用基礎(chǔ)鏡像；通過鏡像掃描機(jī)制防范安全漏洞；鏡像簽名保證平臺運(yùn)行鏡像均已被可靠認(rèn)證。 網(wǎng)絡(luò)通過底層網(wǎng)絡(luò)策略，防火墻和ACL，按照安全等級設(shè)計(jì)不同安全要求的網(wǎng)絡(luò)區(qū)域；集群采用細(xì)粒度網(wǎng)絡(luò)控制機(jī)制NetworkPolicy；通過路由分片實(shí)現(xiàn)對不同網(wǎng)絡(luò)安全要求應(yīng)用進(jìn)行隔離；通過EgressIP機(jī)制實(shí)現(xiàn)集群間網(wǎng)絡(luò)訪問控制。 應(yīng)用DevOps流水線對應(yīng)用代碼與服務(wù)進(jìn)行持續(xù)漏洞掃描，進(jìn)行安全合規(guī)審查，保證應(yīng)用的安全。 數(shù)據(jù)對于底層存儲數(shù)據(jù)采用硬件加密；對于應(yīng)用的敏感配置數(shù)據(jù)采用vault

23、管理的secret資源保存。3.3 關(guān)鍵模塊設(shè)計(jì)3.3.1 容器平臺圖 4 容器平臺部署設(shè)計(jì) 服務(wù)編排與管理服務(wù)編排中，需要考慮資源的統(tǒng)一管理、應(yīng)用部署及應(yīng)用彈性伸縮。資源管理：平臺通過對項(xiàng)目配額的管理實(shí)現(xiàn)對集群資源的統(tǒng)一分配，能夠快速響應(yīng)開發(fā)部門的資源需求；針對不同類型應(yīng)用提供不同的底層計(jì)算節(jié)點(diǎn)，如計(jì)算型、內(nèi)存型等，以便進(jìn)一步提高資源的利用率。應(yīng)用部署：應(yīng)用支持多地多集群部署，通過容器平臺可以同時(shí)指定應(yīng)用部署的集群及各自的副本數(shù)，容器編排引擎將會自動完成應(yīng)用的部署。彈性伸縮：應(yīng)用通過HPA、VPA資源配置，對應(yīng)用的負(fù)載進(jìn)行監(jiān)控實(shí)現(xiàn)應(yīng)用資源限制與副本數(shù)配置的擴(kuò)展與收縮，以支持流量激增的互聯(lián)網(wǎng)場

24、景。 網(wǎng)絡(luò)網(wǎng)絡(luò)場景主要考慮以下四種場景：集群內(nèi)部網(wǎng)絡(luò)、集群間網(wǎng)絡(luò)、集群訪問外部網(wǎng)絡(luò)以及外部訪問集群間網(wǎng)絡(luò)。對于金融行業(yè)，網(wǎng)絡(luò)安全非常重要，該方案中充分考慮在任意種場景下的網(wǎng)絡(luò)安全問題。集群內(nèi)部網(wǎng)絡(luò)：采用OVS-Networkpolicy網(wǎng)絡(luò)策略實(shí)現(xiàn)集群內(nèi)部服務(wù)網(wǎng)絡(luò)精細(xì)化管理，不同項(xiàng)目間的應(yīng)用默認(rèn)網(wǎng)絡(luò)隔離。集群間網(wǎng)絡(luò)：平臺支持多網(wǎng)絡(luò)區(qū)域下集群的統(tǒng)一管理，不同的網(wǎng)絡(luò)區(qū)域底層通過硬件實(shí)現(xiàn)隔離。例如，DMZ區(qū)與生產(chǎn)區(qū)分別部署Openshfit集群，之間通過硬件防火墻進(jìn)行隔離。集群訪問外部網(wǎng)絡(luò)：采用EgressIP機(jī)制，為每個(gè)Project指定出口IP，該P(yáng)roject下的所有應(yīng)用都以該IP對外部發(fā)送請

25、求，通過集群與外部系統(tǒng)間的防火墻控制網(wǎng)絡(luò)的訪問權(quán)限。外部訪問集群：集群服務(wù)通過Openshift Router服務(wù)對外提供HTTP/TCP服務(wù)。并且根據(jù)業(yè)務(wù)類型對Router進(jìn)行分片，更大程度提升Router服務(wù)的性能與擴(kuò)展性。 存儲單一的存儲方式無法滿足復(fù)雜的業(yè)務(wù)場景，方案根據(jù)不同的場景內(nèi)容提供對應(yīng)的存儲介質(zhì)。圖 5 存儲場景展示圖場景一：應(yīng)用內(nèi)部多容器共享緩存，使用容器自身臨時(shí)存儲。場景二：應(yīng)用不同副本間共享存儲使用NFS網(wǎng)絡(luò)存儲。場景三：對于存儲IO要求較高，并且支持單節(jié)點(diǎn)掛載，使用Ceph RBD分布式存儲作為應(yīng)用持久化存儲。場景四：對于存儲IO要求很高，采用本地盤存儲方案，將應(yīng)用與主

26、機(jī)通過Node Label進(jìn)行綁定。場景五：采用MinIO部署獨(dú)立的對象存儲服務(wù)，為容器應(yīng)用提供相關(guān)數(shù)據(jù)持久化 鏡像倉庫鏡像倉庫是一個(gè)集中存儲容器鏡像的空間，在企業(yè)中建立企業(yè)級的鏡像倉庫有利于集中管理容器鏡像，并且利于實(shí)現(xiàn)多個(gè)環(huán)境之間的鏡像資源共享。Openshift組件中提供了鏡像倉庫，且它與資源對象DeploymentConfig、BuildConfig等能夠聯(lián)動，以快速實(shí)現(xiàn)自動構(gòu)建與自動部署，但是它與項(xiàng)目強(qiáng)關(guān)聯(lián)并且在鏡像安全掃描方面有所欠缺，很難將它作為一個(gè)企業(yè)級通用的鏡像倉庫?；谏厦娴目紤]，本方案中將引入Harbor作為平臺的統(tǒng)一鏡像倉庫，并通過鏡像倉庫命名規(guī)范與制品庫管理規(guī)范集中管

27、理所有環(huán)境中的鏡像。圖 6 鏡像倉庫Harbor多中心多部署示意圖開發(fā)測試環(huán)境與生產(chǎn)環(huán)境網(wǎng)絡(luò)是隔離的，分別部署獨(dú)立的Harbor服務(wù)。其中項(xiàng)目在開發(fā)測試環(huán)境的鏡像會被分別存放在不同的倉庫中分別是DEV/SIT/UAT/PROD，鏡像只有經(jīng)過嚴(yán)格測試達(dá)到上線標(biāo)準(zhǔn)后才能推送到PROD倉庫中，PROD倉庫與其它地區(qū)的開發(fā)測試環(huán)境中的PROD倉庫同步，同時(shí)這與同地的生產(chǎn)環(huán)境中的PROD倉庫同步，實(shí)現(xiàn)應(yīng)用鏡像的多地分發(fā)。為了提高鏡像的下載速度，以加快應(yīng)用的部署，鏡像服務(wù)還開啟P2P預(yù)熱，生產(chǎn)中將應(yīng)用鏡像提前分發(fā)到P2P網(wǎng)絡(luò)。 監(jiān)控告警監(jiān)控告警系統(tǒng)是平臺系統(tǒng)運(yùn)營維護(hù)的有利保障，目前云原生生態(tài)中較為成熟也是

28、被使用最廣的方案是Prometheus套裝。通過不同的exporter服務(wù)獲取相關(guān)的指標(biāo)數(shù)據(jù)，由Prometheus統(tǒng)一收集，并通過Grafana展示出圖表，相關(guān)監(jiān)控項(xiàng)狀態(tài)與趨勢一目了然，下圖為Prometheus方案組件架構(gòu)圖。圖 7 Prometheus方案組件架構(gòu)圖Exporters：面向全方面資源的監(jiān)控指標(biāo)，具體有底層節(jié)點(diǎn)的相關(guān)指標(biāo)、平臺組件狀態(tài)與性能指標(biāo)、集群應(yīng)用容器資源狀態(tài)指標(biāo)、自定義應(yīng)用性能指標(biāo)。Prometheus server：通過pull方式從Exporters收集底層設(shè)備、平臺組件、容器資源、應(yīng)用自定義所有監(jiān)控指標(biāo)。Grafana：提供對Prometheus采集的監(jiān)控?cái)?shù)據(jù)

29、進(jìn)行可視化展示。Alertmanager：接入多種告警渠道（郵件、短信、微信等），統(tǒng)一管理多個(gè)來源的告警信息，如Prometheus rules策略觸發(fā)的告警、日志監(jiān)控觸發(fā)的告警、自定檢查腳本觸發(fā)的告警，如下圖所示為Alertmanager作為統(tǒng)一告警系統(tǒng)架構(gòu)。圖 8Alertmanager 統(tǒng)一告警系統(tǒng)架構(gòu)為了便于對多個(gè)集群集中監(jiān)控，采用Prometheus Federation架構(gòu)實(shí)現(xiàn)多級監(jiān)控，將不同集群監(jiān)控指標(biāo)統(tǒng)一收集，并將歷史監(jiān)控?cái)?shù)據(jù)持久化在MinIO S3存儲中。圖 9 監(jiān)控服務(wù)部署示意圖 日志雖然Openshift組件中提供了基于EFK的日志方案，但這種方案并不能適應(yīng)所有的業(yè)務(wù)場景

30、。它有以下不足之處：應(yīng)用日志只有標(biāo)準(zhǔn)化輸出才能被收集；只能有一個(gè)日志輸出文件，而真實(shí)業(yè)務(wù)場景中會有多個(gè)日志文件；Fluentd的性能并不算太好；Fluented直接發(fā)送到ES，當(dāng)日志量大時(shí)，很容易發(fā)生堵塞，導(dǎo)致日志延時(shí)大甚至丟失日志。基于以上這些考慮，本方案中將對日志方案進(jìn)行性能與功能的增強(qiáng)。圖 10 日志方案架構(gòu)圖采用更輕量及性能更好的Filebeat替換掉Fluentd來收集集群組件日志及應(yīng)用標(biāo)準(zhǔn)輸出的日志，仍然以DaemonSet資源的形式部署。對于沒有標(biāo)準(zhǔn)輸出的應(yīng)用，以sidecar的形式共享日志文件并通過filebeat收集日志文件，將其發(fā)送到Kafka中，由logstash轉(zhuǎn)發(fā)到E

31、lasticSearch服務(wù)，最后由Kibana服務(wù)展示。引入Kafka作為日志緩沖層，提高集群應(yīng)用日志的吞量。應(yīng)用的標(biāo)準(zhǔn)輸出日志，通過DaemonSetFileBeat服務(wù)統(tǒng)一收集并轉(zhuǎn)發(fā)到Kafka中，由后端logstash轉(zhuǎn)發(fā)到Elasticsearch服務(wù)中。該日志方案不僅滿足生產(chǎn)業(yè)務(wù)中的各種場景，而且能夠支持高并發(fā)日志量。同時(shí)使用的組件均可通過橫向擴(kuò)展來擴(kuò)大整個(gè)系統(tǒng)的吞吐量。 容器平臺門戶為了讓架構(gòu)具有更好的擴(kuò)展性，云平臺設(shè)計(jì)了四層架構(gòu)：展示層、業(yè)務(wù)層、驅(qū)動層、數(shù)據(jù)層，如下圖所示。另外為云平臺設(shè)計(jì)了平臺控制器，通過它實(shí)現(xiàn)容器集群資源對象數(shù)據(jù)實(shí)時(shí)緩存到Redis中。圖 11 容器平臺門戶

32、架構(gòu)圖 展示層負(fù)責(zé)平臺的頁面展示，它為用戶提供一套可視化，交互式的界面。研發(fā)人員通過查看或者填寫表單等操作，調(diào)用業(yè)務(wù)層Restful API接口，獲取詳細(xì)的資源與業(yè)務(wù)數(shù)據(jù)，并在頁面渲染。 業(yè)務(wù)層負(fù)責(zé)平臺的業(yè)務(wù)邏輯，為展示層提供Restful API接口。它會對請求的權(quán)限做驗(yàn)證，通過調(diào)用驅(qū)動層獲取請求的資源基礎(chǔ)信息，并通過Redis獲取底層資源的詳細(xì)信息，最后以JSON格式數(shù)據(jù)返回給展示層。 驅(qū)動層負(fù)責(zé)與底層集群的交互，它通過指定的證書可直接訪問底層集群的Master API Server，進(jìn)而實(shí)現(xiàn)對容器集群資源的管理。同時(shí)它通過Restful API為業(yè)務(wù)層提供所需的服務(wù)。 數(shù)據(jù)層負(fù)責(zé)保存容器

33、平臺的業(yè)務(wù)數(shù)據(jù)，包括有項(xiàng)目信息、用戶信息、審計(jì)信息、權(quán)限配置、集群配置信息等。 平臺控制器每個(gè)集群都會部署單獨(dú)的平臺控制器，并為它綁定獲取該集群的所有資源信息的權(quán)限，使用watch API監(jiān)聽底層資源的變化，一旦對應(yīng)集群有新增的資源，或有資源信息發(fā)生更改，或資源被刪除，平臺控制器都會將信息同步在Redis緩存中，從而收集所有集群的資源對象信息，并確保信息一直處于最新狀態(tài)。容器平臺門戶支持多集群管理，集群信息通過平臺管理功能保存在數(shù)據(jù)庫中。業(yè)務(wù)層請求驅(qū)動層時(shí)會帶上被訪問的集群名，驅(qū)動層通過查詢數(shù)據(jù)庫獲取集群的訪問信息，定位到正確的集群。3.3.2 DevOps支撐DevOps平臺采用禪道做為需求

34、管理工具，同時(shí)采用Jenkins作為流水線引擎，其它工具鏈通過Jenkins進(jìn)行驅(qū)動，實(shí)現(xiàn)應(yīng)用自動高效構(gòu)建與自動部署。同時(shí)Jenkins引入k8s插件，所有節(jié)點(diǎn)，包括Master節(jié)點(diǎn)與slave節(jié)點(diǎn)均部署在容器云平臺之上，充分利用容器平臺的快速部署能力，實(shí)現(xiàn)流水線的高效執(zhí)行。以下是DevOps支撐能力的整體示意圖。圖 12 DevOps支撐能力的整體示意圖 需求管理引入禪道開源產(chǎn)品進(jìn)行產(chǎn)品需求管理，并通過禪道中的電子看板實(shí)現(xiàn)需求全生命周期的可視化跟蹤，完成需求計(jì)劃管理。通過電子看板中的模塊管理實(shí)現(xiàn)對需求所屬功能模塊的劃分，讓產(chǎn)品人員能夠從整體上看到需求的功能劃分。通過計(jì)劃管理實(shí)現(xiàn)對需求的統(tǒng)一規(guī)

35、劃，我們可以定義每個(gè)時(shí)間節(jié)點(diǎn)的目標(biāo)，根據(jù)優(yōu)先級、工作量等條件把需求規(guī)劃到每個(gè)計(jì)劃中。團(tuán)隊(duì)成員根據(jù)自身情況分析每個(gè)需求的工作量大小，并將需求分配到個(gè)人，計(jì)劃開啟后，每個(gè)人根據(jù)需求的實(shí)際完成情況修改需求的狀態(tài)。同時(shí)通過與代碼庫、測試平臺的對接，展現(xiàn)需求的代碼提交情況、測試情況。使用統(tǒng)計(jì)報(bào)表，圖形化展現(xiàn)需求的完成速率、歷史情況，幫助項(xiàng)目組進(jìn)行工作回顧。 開發(fā) 代碼配置管理提供組織級的gitlab平臺用于研發(fā)人員對代碼進(jìn)行配置管理。通過制定配置管理規(guī)劃能夠?qū)μ峤坏拇a進(jìn)行有效管控；通過對代碼提交信息的格式約束能夠?qū)⒋a與需求進(jìn)行關(guān)聯(lián)；通過對代碼庫的webhook進(jìn)行配置，代碼提交即可觸發(fā)流水線，對代碼

36、進(jìn)行構(gòu)建、掃描、測試，能夠有效管控代碼質(zhì)量。除此之外，對于關(guān)鍵代碼，還進(jìn)行code review、代碼走查等，保證提交的代碼質(zhì)量。 代碼掃描提供組織級的靜態(tài)代碼掃描平臺SonarQube和Fortify，基于PMD、CheckStyle、FindBugs制訂了組織級的代碼檢查規(guī)則。研發(fā)人員代碼一旦提交到代碼庫就會觸發(fā)代碼掃描流水線，能夠及時(shí)發(fā)現(xiàn)代碼中的Issues和Bugs，可視化技術(shù)債務(wù)，明確技術(shù)債務(wù)分布情況、債務(wù)點(diǎn)以及改進(jìn)建議等，從而能夠及時(shí)得到解決，提高產(chǎn)品質(zhì)量。 制品管理基于Nexus構(gòu)建組織級的制品倉庫，對制品進(jìn)行成熟度管理，只有制品滿足各項(xiàng)度量指標(biāo)后，制品才能部署到下一階段，最終部

37、署生產(chǎn)環(huán)境。同時(shí)在制品元數(shù)據(jù)中記錄制品的質(zhì)量數(shù)據(jù)，確保了部署到生產(chǎn)環(huán)境的制品是經(jīng)過嚴(yán)格測試的、滿足質(zhì)量要求的。 單元測試要求代碼的單元測試覆蓋率滿足一定要求，同時(shí)關(guān)鍵代碼必須要有單元測試。在實(shí)際開發(fā)過程中，使用TestNG、Junit等工具進(jìn)行單元測試案例的編寫，并引入Jacoco進(jìn)行單元測試覆蓋率的收集。只有單元測試覆蓋率滿足一定要求后，代碼才能進(jìn)行打包構(gòu)建并上傳到制品倉庫中，進(jìn)而后期才能進(jìn)行部署及自動化測試等。 測試禪道平臺也作為測試管理平臺，對測試案例、缺陷進(jìn)行統(tǒng)一管理，并且與需求進(jìn)行關(guān)聯(lián)。同時(shí)會將測試的結(jié)果數(shù)據(jù)記錄在制品的元數(shù)據(jù)中，確保部署到生產(chǎn)環(huán)境的制品必須要符合質(zhì)量要求。 功能測試

38、采用selenium工具對于需要上線的系統(tǒng)進(jìn)行功能測試并且生成測試報(bào)告，待評審?fù)ㄟ^以后才能進(jìn)行上線。通過對系統(tǒng)進(jìn)行白盒、黑盒、灰盒、邊界值等多維度的測試，確保系統(tǒng)能夠滿足功能需求。 自動化測試采用selenium工具開發(fā)實(shí)現(xiàn)自動化測試腳本，并作為Jenkins構(gòu)建任務(wù)的一部分。自動化測試主要包含兩個(gè)方面，一個(gè)是UI測試，一個(gè)是接口測試。通過CICD流水線將制品成功部署到測試環(huán)境以后，自動會觸發(fā)自動化測試流水線，通過編寫好的自動化測試腳本對系統(tǒng)進(jìn)行測試。 部署通過打包構(gòu)建生成制品以后，制品會根據(jù)事先定義好的Dockerfile構(gòu)建成鏡像并上傳到鏡像倉庫中。然后使用容器平臺將鏡像依次部署到SIT、

39、UAT等環(huán)境進(jìn)行測試。測試通過以后將鏡像提交到待發(fā)布庫中。生成下發(fā)流程通過以后，觸發(fā)容器平臺進(jìn)行生產(chǎn)部署。 運(yùn)營維護(hù)通過容器平臺，可以很便利的對其中的應(yīng)用進(jìn)行日志、性能等多維度的監(jiān)控，同時(shí)提供了預(yù)警機(jī)制，當(dāng)機(jī)器或應(yīng)用性能觸發(fā)閾值以后，會向應(yīng)用負(fù)責(zé)人發(fā)送短信和郵件提醒。從而應(yīng)用負(fù)責(zé)人能夠?qū)崟r(shí)掌握應(yīng)用狀態(tài)，對出現(xiàn)的一些狀況能及時(shí)處理。 平臺度量對各個(gè)能力子域的指標(biāo)進(jìn)行量化，在流水線的實(shí)際執(zhí)行過程中收集這些指標(biāo)，同時(shí)對收集指標(biāo)進(jìn)行分析、打分，得出此次執(zhí)行的一個(gè)量化數(shù)據(jù)。通過收集每次流水線執(zhí)行的指標(biāo)數(shù)據(jù)，就可以獲取到該應(yīng)用的整個(gè)質(zhì)量的趨勢，從而能夠更好的指導(dǎo)應(yīng)用開發(fā)。4 規(guī)范指引圖 13 規(guī)范指引展示

40、圖4.1 業(yè)務(wù)規(guī)范4.1.1 用戶認(rèn)證架構(gòu) 統(tǒng)一語言業(yè)務(wù)需求應(yīng)當(dāng)使用統(tǒng)一的語言，所謂統(tǒng)一語言，是指項(xiàng)目研發(fā)過程中，產(chǎn)品、研發(fā)、測試、運(yùn)維、管理、運(yùn)營等角色在交流中，對一些專有名詞理解達(dá)成統(tǒng)一，以保證大家在溝通中沒有信息不一致或信息歧異，提高溝通效率和準(zhǔn)確度。 業(yè)務(wù)需求格式業(yè)務(wù)需求描述中應(yīng)明確，清晰，不應(yīng)使用可能、一般等模棱兩可的描述，應(yīng)當(dāng)體現(xiàn)出業(yè)務(wù)功能的角色、活動、價(jià)值（效果）。此處不應(yīng)使用技術(shù)語言來描述，要使用用戶可以理解的業(yè)務(wù)語言來描述。通常格式為作為一個(gè), 我想要,以便于商業(yè)價(jià)值。舉例：作為一個(gè)“網(wǎng)站管理員”，我想要“統(tǒng)計(jì)每天有多少人訪問了我的網(wǎng)站”，以便于“我的贊助商了解我的網(wǎng)站會給他

41、們帶來什么收益?！?.2 應(yīng)用上云設(shè)計(jì)規(guī)范4.2.1 應(yīng)用容器化設(shè)計(jì)規(guī)范 應(yīng)用中不指定Pod的IP應(yīng)用容器化部署后，Pod的替換伴隨著IP的變化。若應(yīng)用指定Pod的IP訪問目標(biāo)應(yīng)用，一旦目標(biāo)應(yīng)用的Pod發(fā)生變動，目標(biāo)應(yīng)用的IP也會隨著變化，目標(biāo)應(yīng)用將無法被正常訪問。為了保證應(yīng)用訪問服務(wù)的穩(wěn)定性，應(yīng)用中不直接通過Pod的IP來訪問目標(biāo)應(yīng)用?？梢酝ㄟ^注冊中心，獲得動態(tài)IP的方式來實(shí)現(xiàn)服務(wù)間的調(diào)用，也可以直接使用serviceIP來實(shí)現(xiàn)不同應(yīng)用間的調(diào)用。 同一Pod內(nèi)的不同容器間使用相互訪問同一個(gè)Pod可以有多個(gè)容器，這些容器共享同一個(gè)網(wǎng)絡(luò)命名空間，它們之間推薦直接使用來實(shí)現(xiàn)互相訪問。 為應(yīng)用實(shí)例提

42、供健康檢查接口應(yīng)用需提供健康檢測接口，用來配置容器的健康檢查策略，從而保證滾動升級過程中的服務(wù)可用性。 應(yīng)用容器需要考慮優(yōu)雅退出為了保證應(yīng)用服務(wù)的穩(wěn)定，應(yīng)用容器需要考慮優(yōu)雅退出，確保容器退出時(shí)關(guān)閉所有連接。如果應(yīng)用程序未處理SIGTERM信號,可以在編排文件中設(shè)置preStop Hook,即在關(guān)閉容器前等待一段時(shí)間，讓應(yīng)用程序完成所有請求。 使用CronJob代替crontab服務(wù)設(shè)置定時(shí)任務(wù)不建議在容器中使用crontab服務(wù)設(shè)置定時(shí)任務(wù)，推薦通過CronJob資源對象來實(shí)現(xiàn)定時(shí)任務(wù)的功能。4.2.2 應(yīng)用部署規(guī)范 應(yīng)用容器通過使用PV/PVC進(jìn)行持久化數(shù)據(jù)容器本身并不帶有持久化存儲，被銷毀

43、時(shí)容器中存儲的數(shù)據(jù)也會被清理。容器中如果需要保存數(shù)據(jù)，需要通過PV（持久化卷）與PVC（持久化卷請求）資源，使用NAS存儲，實(shí)現(xiàn)數(shù)據(jù)持久化。 ConfigMap掛載到容器內(nèi)部的文件夾必須為空配置文件可以保存在ConfigMap中，ConfigMap掛載到容器內(nèi)部的目錄會把目錄下的原有文件覆蓋，所以需要注意掛載的目錄盡量為空目錄。 每個(gè)系統(tǒng)申請一個(gè)EgressIP，作為訪問外部服務(wù)的出口IP為了對系統(tǒng)網(wǎng)絡(luò)做更精細(xì)化的控制，容器云平臺每個(gè)系統(tǒng)必須申請并綁定一個(gè)EgressIP。該系統(tǒng)下的應(yīng)用Pod都以該IP為出口IP訪問外部服務(wù)，通過防火墻設(shè)置，可以對系統(tǒng)下的應(yīng)用訪問外部服務(wù)的網(wǎng)絡(luò)進(jìn)行控制。 為應(yīng)

44、用實(shí)例設(shè)置健康檢查為了更好地監(jiān)控應(yīng)用服務(wù)的狀態(tài)，充分發(fā)揮容器云平臺為應(yīng)用帶來的自愈能力，提高應(yīng)用的可靠性，應(yīng)用必須設(shè)置readinessProbe與livenessProbe。其中readinessProbe將檢測應(yīng)用容器是否已準(zhǔn)備好接受流量，livenessProbe將檢測應(yīng)用容器是否存活。 為應(yīng)用實(shí)例設(shè)置資源限制（cpu與memory）為了對資源進(jìn)行精細(xì)化管理與控制，減少底層資源的競爭，也可避免程序因Bug占用過多底層資源，以提高應(yīng)用的穩(wěn)定性，容器基礎(chǔ)平臺的應(yīng)用部署時(shí)必須為每個(gè)容器設(shè)置資源限制，包括：limits.cpu、limits.memory、requests.cpu、request

45、s.memory。其中l(wèi)imits.cpu、limits.memory為應(yīng)用運(yùn)行過程中占用CPU、Memory資源的上限值；requests.cpu、requests.memory為應(yīng)用運(yùn)行過程中請求的CPU、Memory資源值。4.3 應(yīng)用開發(fā)規(guī)范4.3.1 數(shù)據(jù)交互規(guī)范 接口格式通常每個(gè)URI網(wǎng)址代表一種資源接口，網(wǎng)址中不應(yīng)有動詞，盡量使用名詞（特殊情況可以使用動詞）；網(wǎng)址名稱不應(yīng)大寫，若需要分割時(shí)使用中杠-不用下杠 _ ；若URI中的名詞表示資源集合，使用復(fù)數(shù)形式。應(yīng)當(dāng)使用url來表達(dá)層級，用于按實(shí)體關(guān)聯(lián)關(guān)系進(jìn)行對象導(dǎo)航。層級不應(yīng)過深，復(fù)雜場景盡量使用查詢參數(shù)代替路徑中的實(shí)體導(dǎo)航。應(yīng)當(dāng)將

46、API的版本號放入到URI中。 HTTP方法應(yīng)使用標(biāo)準(zhǔn)的HTTP方法實(shí)現(xiàn)對資源的CRUD，包括：GET：查詢（從服務(wù)器取出資源一項(xiàng)或多項(xiàng)）；POST：創(chuàng)建單個(gè)新資源。POST向“資源集合”型uri發(fā)起；PUT：更新單個(gè)資源（全量），客戶端提供完整的更新后的資源；DELETE：刪除。其中GET、PUT、DELETE方法應(yīng)具備冪等性 ，也就是執(zhí)行1次和執(zhí)行N次，對資源狀態(tài)改變的效果應(yīng)是等價(jià)的。 HTTP狀態(tài)碼和提示信息正確設(shè)置http狀態(tài)碼，不要自定義http狀態(tài)碼。服務(wù)器返回的提示信息應(yīng)盡量簡潔，避免嵌套，采用信息代碼（用于日志/問題追查）+錯誤的描述文本（展示給用戶）的形式。 接口文檔數(shù)據(jù)交互

47、應(yīng)形成良好的接口文檔，包括但不限于以下內(nèi)容：(1) HTTP方法類型：也就是我們常寫的GET，POST，PUT，DELETE等。(2) url調(diào)用方法：從前端調(diào)后端的方法地址。(3) 請求參數(shù)：包括字段、說明、類型、備注、是否必填。(4) 返回參數(shù)：盡量使用JSON，避免使用XML。 異常處理異常應(yīng)包括業(yè)務(wù)異常和非業(yè)務(wù)異常。業(yè)務(wù)異常由自己的業(yè)務(wù)代碼拋出，表示一個(gè)用例的前置條件不滿足、業(yè)務(wù)規(guī)則沖突等，比如參數(shù)校驗(yàn)不通過、權(quán)限校驗(yàn)失敗。非業(yè)務(wù)類異常 表示不在預(yù)期內(nèi)的問題，通常由類庫、框架拋出，或由于自己的代碼邏輯錯誤導(dǎo)致，比如數(shù)據(jù)庫連接失敗、空指針異常、除0錯誤等等。業(yè)務(wù)異常應(yīng)返回200的HTTP

48、響應(yīng)狀態(tài)碼，并返回指定的錯誤文本提示信息。非業(yè)務(wù)異常應(yīng)返回500的HTTP響應(yīng)狀態(tài)碼，異常信息應(yīng)進(jìn)行統(tǒng)一封裝，如“服務(wù)器端錯誤，請稍后再試”，非必要情況不應(yīng)將錯誤類型展示給用戶。 安全對于API的使用應(yīng)當(dāng)有身份認(rèn)證，同時(shí)具備一定的安全手段用于預(yù)防常見的安全攻擊。4.3.2 應(yīng)用鏡像構(gòu)建規(guī)范 使用統(tǒng)一的基礎(chǔ)鏡像基礎(chǔ)鏡像涉及應(yīng)用運(yùn)行所需要的安全可靠的Linux操作系統(tǒng)。基礎(chǔ)鏡像由基礎(chǔ)架構(gòu)部門負(fù)責(zé)維護(hù)，定期打安全漏洞的補(bǔ)丁，并基于應(yīng)用要求構(gòu)建基礎(chǔ)環(huán)境鏡像，維護(hù)到公共鏡像倉庫。 公共依賴層主要是包括運(yùn)行時(shí)（如JDK）、中間件（如Web容器）、其它公共組件等。公共依賴層鏡像由基礎(chǔ)架構(gòu)部門負(fù)責(zé)維護(hù)，定期打

49、安全漏洞的補(bǔ)丁，并基于應(yīng)用要求構(gòu)建依賴層鏡像，維護(hù)到公共鏡像倉庫。 應(yīng)用層主要包括程序包（jar包、war包）、程序依賴包（jar lib）等。程序包基于代碼基線編譯打包，應(yīng)用層鏡像由開發(fā)部門負(fù)責(zé)構(gòu)建。 鏡像一次構(gòu)建，多環(huán)境部署為了保證應(yīng)用的運(yùn)行環(huán)境保持一致，應(yīng)用容器鏡像應(yīng)在研發(fā)環(huán)境下構(gòu)建，在其它環(huán)境下部署進(jìn)行測試與上線均使用同一個(gè)鏡像。 使用非root用戶啟動應(yīng)用容器為保障容器云平臺的安全性，禁止應(yīng)用容器中使用root用戶運(yùn)行應(yīng)用。4.3.3 DevOps指引 開發(fā)流程自動集成(1) 項(xiàng)目配置好CI/CD流水線后，開發(fā)人員提交代碼；(2) 自動觸發(fā)CI/CD流水線運(yùn)行，對項(xiàng)目代碼進(jìn)行代碼掃描

50、、單元測試；(3) 獲取私服Maven倉庫資源（非必須）進(jìn)行構(gòu)建；(4) 構(gòu)建完成后，生成最新的鏡像保存到鏡像倉庫。下圖為開發(fā)集成部署流程圖。圖 14 開發(fā)集成流程圖 開發(fā)提測流程(1) 開發(fā)人員用gitlab給代碼打上提測Tag；(2) 開發(fā)人員手動在Jenkins上提測，執(zhí)行提測任務(wù)；(3) 自動觸發(fā)工程指定版本代碼的構(gòu)建，并生成指定版本的鏡像；(4) 測試人員在測試環(huán)境部署指定版本鏡像，進(jìn)行測試。下圖為開發(fā)提測流程圖：圖 15 開發(fā)提測流程圖 集成測試流程測試人員在測試環(huán)境部署指定版本鏡像，進(jìn)行測試。下圖為集成測試流程圖：圖 16 集成測試流程圖說明：以上流程均可在開發(fā)測試PaaS集群操

51、作，如果要上生產(chǎn)部署，需搭為生產(chǎn)環(huán)境單獨(dú)部署另外一套PaaS集群，同時(shí)兩個(gè)集群網(wǎng)絡(luò)與資源隔離。 生產(chǎn)部署流程(1) 運(yùn)維人員從測試環(huán)境同步指定版本的鏡像；(2) 運(yùn)維人員在生產(chǎn)環(huán)境部署指定版本鏡像。下圖為生產(chǎn)部署流程圖：圖 17 生產(chǎn)部署流程圖4.4 運(yùn)維規(guī)范4.4.1 容器平臺運(yùn)維規(guī)范 定期巡檢將Openshfit集群重要組件的健康狀態(tài)檢查封裝在shell腳本中，設(shè)定定時(shí)任務(wù)，實(shí)現(xiàn)自動化巡檢，按時(shí)生成巡檢報(bào)告，以郵件形式發(fā)送至平臺運(yùn)維、研發(fā)單位。定期巡檢包括：master-api、master-controller、Etcd、router、es、prometheus等組件的狀態(tài)。 擴(kuò)容評估設(shè)

52、計(jì)Openshift集群資源預(yù)申請臺賬，結(jié)合集群管理門戶查詢到的集群資源實(shí)際使用情況，記錄Openshift集群當(dāng)前的資源總量和計(jì)劃上線的系統(tǒng)所需資源，根據(jù)臺賬的資源申請比例，安排計(jì)算、存儲資源擴(kuò)容。 應(yīng)急預(yù)案根據(jù)Openshift集群特點(diǎn)，制定應(yīng)急預(yù)案：一是記錄硬件資源、軟件資源、集群邏輯架構(gòu)、數(shù)據(jù)備份方案、關(guān)聯(lián)系統(tǒng)、應(yīng)急聯(lián)系人等信息；二是記錄系統(tǒng)節(jié)點(diǎn)及部署模式，便于故障發(fā)生時(shí)快速查閱節(jié)點(diǎn)信息；三是針對平臺層11個(gè)故障場景（硬件、網(wǎng)絡(luò)、平臺組件）、應(yīng)用層6個(gè)故障（管理門戶、sftp等）場景的處置方案，以及故障恢復(fù)后的驗(yàn)證方案。其中平臺層故障處置方案主要有以下三個(gè)層面：基礎(chǔ)設(shè)施故障：物理主機(jī)故

53、障、基礎(chǔ)網(wǎng)絡(luò)故障、存儲設(shè)備故障。平臺服務(wù)故障：管理節(jié)點(diǎn)集群組件服務(wù)異常（Master API、Master Controller、Etcd)，工作節(jié)點(diǎn)服務(wù)異常（atomic-Openshfit-node、Docker服務(wù)），集群間網(wǎng)絡(luò)異常（sdn、ovs服務(wù)）。運(yùn)維相關(guān)應(yīng)用故障：監(jiān)控服務(wù)異常（Prometheus服務(wù)），日志服務(wù)異常（Fluentd、ES服務(wù)）。4.4.2 應(yīng)用運(yùn)維規(guī)范 應(yīng)用發(fā)布Openshfit集群將部署文件和鏡像文件從制品庫拉取至本地，再通過oc命令進(jìn)行發(fā)布。該部署過程按場景編排成多個(gè)自動化流程，通過在管理端填寫發(fā)布相關(guān)的參數(shù)執(zhí)行。 應(yīng)用回退Openshfit集群將舊版本的

54、部署文件和鏡像文件從制品庫拉取至本地，再通過或oc命令進(jìn)行發(fā)布。該回退過程按場景編排成自動化流程，通過在管理端填寫版本tag相關(guān)的參數(shù)執(zhí)行。 應(yīng)用監(jiān)控設(shè)計(jì)每分鐘一次的定時(shí)任務(wù)，將影響應(yīng)用可用性的關(guān)鍵指標(biāo)，結(jié)合集群各宿主機(jī)節(jié)點(diǎn)的系統(tǒng)指標(biāo)數(shù)據(jù)統(tǒng)一發(fā)送至監(jiān)控平臺進(jìn)行集中管理、展示、和告警。 應(yīng)用伸縮管理根據(jù)特定的大流量業(yè)務(wù)場景需要，平臺允許在特定時(shí)間區(qū)間、在平臺可以容納的容量范圍內(nèi)，對應(yīng)用進(jìn)行擴(kuò)縮容處理，擴(kuò)縮容命令封裝后，編排成自動化運(yùn)維平臺的流程，通過填入擴(kuò)縮容副本數(shù)量等參數(shù)執(zhí)行。 日志管理容器應(yīng)用日志須落盤持久化卷存放，不同容器分不同文件進(jìn)行存儲。日志必須進(jìn)行合理分級，按時(shí)間或大小自動分割，并依據(jù)合理的壓縮和清理周期管理。容器應(yīng)用日志命名合理規(guī)范，日志內(nèi)容要素齊全：時(shí)間、日志級別（INFO、WARN、ERROR）、線程名稱、交易標(biāo)識、用戶id、日志消息體、異常堆棧等。容器日志訪問須提供兩種方式：一是由平臺自帶的EFK組件統(tǒng)一管理和展示，二是通過應(yīng)用系統(tǒng)相關(guān)虛擬機(jī)或物理機(jī)節(jié)點(diǎn)直接訪問。4.4.3 制品管理規(guī)范 鏡像準(zhǔn)入管理基礎(chǔ)鏡像使用RedH