企業(yè)云技術中臺建設方案

1、 企業(yè)云技術中臺建設方案 【導讀】本方案是“2020容器云職業(yè)技能大賽”團隊比賽季軍作品。以OpenShift Container Platform（簡稱OCP）為底座，OCP以Docker技術和kubernetes框架為基礎，在此之上擴展提供了軟件定義網絡、軟件定義存儲、基于角色的權限訪問管理、企業(yè)級鏡像倉庫、統(tǒng)一入口路由、持續(xù)集成流程（s2i/jenkins）、統(tǒng)一管理控制臺、監(jiān)控日志等功能，形成了覆蓋整個軟件生命周期的解決方案。1 平臺整體概要企業(yè)云計算架構演進歷程推進企業(yè)向共享架構轉型的邏輯架構2 平臺整體概要2.1 集群部署方案本次設計交付的容器云平臺包括兩個環(huán)境：開發(fā)測試環(huán)境、生產

2、環(huán)境，兩個OCP環(huán)境中的Master、Router、EFK、Metrics以高可用方式部署：開發(fā)環(huán)境節(jié)點分master（管理節(jié)點），infra（基礎設施節(jié)點），node（計算節(jié)點），配套設施節(jié)點。（1）mater節(jié)點部署在內網環(huán)境，master計算資源需根據(jù)業(yè)務需求進行評估，master節(jié)點上至少應滿足每管理1000個pod資源配置需要增加1VCPU 和1.5G 內存.（2）infra節(jié)點在內網環(huán)境和DMZ區(qū)分別部署節(jié)點，對于暴露外網的服務，走dmz節(jié)點通信（3）鏡像倉庫節(jié)點，統(tǒng)一采用高可用方案部署harbor鏡像倉庫，可同時作為外部ing下倉庫和集群內部鏡像倉庫使用（4）日志節(jié)點，因日志節(jié)點

3、存儲io較大，單獨部署3節(jié)點用于日志，并且存儲采用本地存儲，提高io性能（5）Yum服務器：為便于OCP集群離線部署，在內網環(huán)境中設置Yum服務器，以http協(xié)議提供服務；（6）在OCP中部署Jenkins服務，來支持CI/CD pipeline落地；（7）計算資源配置規(guī)范2.2 集群網絡設計方案2.2.1 負載均衡設計通過F5設備實現(xiàn)負載均衡，使用該方式的有開發(fā)測試環(huán)境Router、DMZ區(qū)開發(fā)測試環(huán)境Router、生產環(huán)境Router、DMZ區(qū)生產環(huán)境Router。F5負載均衡策略采用輪詢（Round Robin）策略或最小連接數(shù)策略，需提供http協(xié)議和https協(xié)議透傳，開放80/44

4、3端口轉發(fā)。2.2.2 操作系統(tǒng)網絡配置每個計算節(jié)點配置兩個萬兆網卡，分別用于業(yè)務流量和nas存儲流量。完成操作系統(tǒng)網卡IP、網關、DNS的配置，進行測試與網關連通性，再進行節(jié)點互通測試。2.2.3 SDN網絡規(guī)劃OCP集群節(jié)點規(guī)模規(guī)劃：2.3 存儲設計方案2.3.1 存儲方式：（1）容器云平臺自身存儲主要考慮數(shù)據(jù)讀寫的性能和數(shù)據(jù)安全，比如etcd，日志中心。綜合考慮，采用本地存儲提供最可靠的性能，同時etcd，日志中心等以分布式架構設計，采用=3副本，異步同步策略（2）應用數(shù)據(jù)持久化存儲采用ceph分部署存儲架構，生產環(huán)境掛載ceph存儲，默認采用3副本，根據(jù)業(yè)務需求分別提供塊存儲、對象存儲

5、、文件存儲接口，RWX類型優(yōu)先選擇掛載NFS文件存儲，RWO類型優(yōu)先選擇采用塊存儲，接口類型包括iscsi，rbd，對于存儲大規(guī)模非結構化數(shù)據(jù)，優(yōu)先選擇對象存儲接口（3）鏡像存儲，鏡像模塊采用高可用部署方案，存儲采用NFS文件存儲共享方式。2.3.2 存儲介質存儲介質分容量型和性能型兩種需求。容量型存儲特點大容量，高性價比。介質采用混合盤。性能規(guī)格：10ms時延，IOPS最大15k（4K隨機讀寫）。適合對時延要求不高的計算型業(yè)務。性能型存儲特點低時延，高吞吐。介質采用SSD，性能規(guī)格：毫秒級時延，IOPS大于30K(4k隨機讀寫)，適合對時延響應要求高的業(yè)務。2.3.3 存儲容量開發(fā)測試環(huán)境：

6、生產環(huán)境：2.3.4 存儲容量數(shù)據(jù)備份內容包括容器配置文件，持久化數(shù)據(jù)，鏡像文件備份，備份設備統(tǒng)一采用NBU專業(yè)備份設備。備份計劃如下2.4 監(jiān)控與日志運維設計2.4.1 監(jiān)控組件監(jiān)控分別基礎設施級監(jiān)控、容器云集群級監(jiān)控、應用級監(jiān)控。（1）基礎設施監(jiān)控采用H3C企業(yè)級監(jiān)控組件ucenter，監(jiān)控內容包括底層存儲硬件運行狀態(tài)，存儲網絡時延，服務器硬件運行狀態(tài)，操作系統(tǒng)cpu，內存使用情況，網絡，IAAS集群運行狀況的監(jiān)控。（2）容器云集群監(jiān)控采用prometheus+grafana監(jiān)控組合，prometheus負責監(jiān)控容器云集群狀態(tài)，容器的內存，CPU，網絡IO，磁盤IO等監(jiān)控，通過cAdvis

7、or可以直接獲取容器基礎監(jiān)控數(shù)據(jù)，通過ocp集群自帶的監(jiān)控組件（如下圖）kube-state-metrics可以直接獲取K8S的資源對象和對應監(jiān)控數(shù)據(jù)，因此我們在每個K8S集群上默認部署prometheus實現(xiàn)這部分監(jiān)控采集，然后通過grafana調用prometheus API來獲取數(shù)據(jù)，用于可視化展示，同時通過Alertmanager組件設置告警信息的發(fā)送。（3）應用級監(jiān)控采用skyworking開源工具，包括對應用系統(tǒng)的指標監(jiān)控，分布式追蹤，分布式系統(tǒng)性能診斷。2.4.2 日志組件采用EFK日志組合，Elasticsearch+Fluentd+Kibana的簡稱。ES負責數(shù)據(jù)的存儲和索引

8、，F(xiàn)luentd負責數(shù)據(jù)的調整、過濾、傳輸，Kibana負責數(shù)據(jù)的展示。Fluentd以DaemonSet方式部署，將收集宿主機中的docker和OCP日志，并發(fā)送到ES。OCP集群內的每個結點都會啟動一個Fluentd容器。ES用于日志存儲，會部署在計算結點，同時部署3個ES節(jié)點集群，并配置成data replicas=2，實現(xiàn)高可用。Kibana用于日志前臺展現(xiàn)，部署在計算結點，同時配置成replicas=2，實現(xiàn)高可用。2.5 多云管理設計2.5.1 跨地區(qū)多云設計對于跨地區(qū)（200KM）廠區(qū)設計方案，主要考慮網絡延時，為保障業(yè)務穩(wěn)定性，采用多集群部署（1）業(yè)務代碼的構建在中心區(qū)完成，并

9、通過中心區(qū)的鏡像倉庫同步到近場集群（邊緣集群）的鏡像倉庫，以便邊緣節(jié)點可以就近拉取鏡像。（2）由于有多個邊緣云，所以會有應用同時部署到多個邊緣云的需求，可以通過云平臺完成多集群同時部署、管理的需求，也可以基于流水線監(jiān)聽 鏡像同步后的事件，來觸發(fā)新版本應用的自動部署上線。2.5.2 聯(lián)邦集群對于網絡延時較小的環(huán)境，根據(jù)大型制造業(yè)跨廠區(qū)業(yè)務特性，利用聯(lián)邦集群實現(xiàn)多云管理。通過OpenShift內置的Kubefed Operator，在OpenShift之上運行聯(lián)邦集群。在Kubefed中通過Controller Manager維護聯(lián)邦集群中每個Kubernetes集群成員的資源狀態(tài)。3 平臺應用交

10、付3.1 平臺應用運營設計方案業(yè)務需求：作為業(yè)務部門，綜合著眼關注業(yè)務進度，不關注需求之外的其它交付內容解決方案：作為制造業(yè)，貫穿生產全過程的各個環(huán)節(jié)，都依賴于信息化系統(tǒng)的有力支撐，而這些系統(tǒng)或者業(yè)務模塊，即具有獨立性，又具有前后連貫性。跟隨生產需要，流程不斷優(yōu)化，各業(yè)務之間協(xié)作關系也在動態(tài)調整，新的業(yè)務加進來，廢棄的業(yè)務逐漸被替代。為了適應業(yè)務快速開發(fā)、交付，各服務之間通力協(xié)作。我們將整個生產服務系統(tǒng)進行業(yè)務劃分，分為基礎類服務，各業(yè)務服務（如訂單、排班，物料采購等等）?；A服務提供基礎的權限認證，統(tǒng)一網關，注冊中心，配置中心，監(jiān)控中心，日志中心，調度中心，為業(yè)務服務提供微服務（spring

11、 cloud）運行環(huán)境，各業(yè)務服務作為核心業(yè)務，以微服務方式、具有獨立的數(shù)據(jù)庫作為服務支撐，注冊到統(tǒng)一注冊中心，通過統(tǒng)一網關進行訪問，各服務之間通過統(tǒng)一網關進行調用協(xié)同，以實現(xiàn)數(shù)據(jù)信息傳遞。平臺應用運營設計分別包括項目需求分析、持續(xù)集成和交付、連續(xù)性服務運營、運維監(jiān)控和分析等環(huán)節(jié)，流程圖如下：3.2 項目需求分析3.2.1 原始需求管理原始需求管理流程業(yè)務用戶，是需求的來源方，不同類型的業(yè)務用戶，往往關注的問題和需求是不同的，建議對用戶及性能分類，例如S類用戶（strategy）、M類用戶(management)、O類用戶（operation）；不同的業(yè)務用戶，其需求的不同決定了對接需求的IT

12、人員所需要具備的能力也要不同，例如對接S類、M類、O類的IT人員角色與能力是不同的。用戶所提的需求，可以從兩個維度進行分類：1、需求所關注的問題分類（體驗型、流程型、功能型）；2、是否屬于現(xiàn)有信息化系統(tǒng)所支撐范疇?；谠夹枨笮畔⑹占?，記錄收集和澄清的需求所友信息需要業(yè)務用戶和IT人員都認可。需求管理的三個粒度層次：Epic：史詩，指公司的關鍵舉措，可以是重大的業(yè)務舉措。Epic的粒度比較大，需要分解為Feature，并通過Feature繼續(xù)分解細化為User Story來完成最終的開發(fā)和交付。Feature：特性，代表可以給客戶帶來價值的產品功能或特性。User story：用戶故事，是從

13、用戶角度對產品需求的詳細描述，更小粒度的功能。由Feature分解而成。3.2.2 項目需求管理業(yè)務系統(tǒng)項目以微服務的方式進行快速迭代交付，針對項目的需求分析處理要求快速迭代，并能夠打通工具鏈，減少人的依賴因素，確保過程質量，提高部署效率。海信需求分析采用confluence統(tǒng)一管理。按照項目劃分項目空間，進行需求編寫、評審、基線。然后將需求進行用戶故事拆分，并與jira工具打通，將需求拆分的用戶故事分配到jira項目空間下，分配到人。用以跟蹤需求的開發(fā)完成進度。如果需求有所變更，需要進行需求變更處理。將過程數(shù)據(jù)在線上呈現(xiàn)，為度量做數(shù)據(jù)支撐。3.3 DevOps流程與角色設計概念階段-需求收集

14、分析流程概念階段-產品立項評審會流程迭代0階段-系統(tǒng)總體架構設計流程1.迭代需求分析階段-迭代需求收集流程1.迭代需求分析階段-迭代需求列表輸出1.迭代需求分析階段-用戶故事編寫流程2.迭代應用設計階段-原型設計和評審流程3.開發(fā)-4.測試-5.發(fā)布-持續(xù)交付概念流程3.4-開發(fā)和SIT測試流程4.UAT測試流程4.預投產測試流程4.測試-缺陷管理流程5.發(fā)布-版本發(fā)布評審流程5.生產部署上線流程6.回顧-迭代回顧會議流程3.4 持續(xù)集成與交付3.4.1 jenkinsCI/CD采用ocp集群自帶的jenkins解決方案。為保障用戶交付的便利性，我們針對每個業(yè)務服務提供了流水線，從代碼檢查，單

15、元測試，編譯構建，鏡像構建，到觸發(fā)鏡像部署，通過流水線，一鍵完成，實現(xiàn)從代碼到運行鏡像的UAT環(huán)境的持續(xù)化交付。同時，我們充分利用Http協(xié)議，請求-響應的特點，我們充分利用ocp平臺，graceterminate的特征，合理設置服務參數(shù)，保障服務可以平滑切換升級，用戶無感知。當UAT測試驗證一切ok后，我們將鏡像直接交付生產，從而保證交付都是可靠的?？紤]到開發(fā)過程中需要重復驗證功能，我們采納了基于配置驅動的開發(fā)模式，我們將服務運行配置與統(tǒng)一配置中心相結合，使得用戶可以通過配置中心實時調整配置，靈活控制新功能是否上線，是否只在部分服務上線。這給開發(fā)團隊帶來極大的靈活性，來方便應對功能完善及新功

16、能上線。3.4.2 高并發(fā)設計業(yè)務需求：高并發(fā)設計解決方案：在公司生產、營銷系統(tǒng)中，數(shù)據(jù)都是按照一定順序流轉并處理。有的系統(tǒng)需要高并發(fā)設計，有的系統(tǒng)對并發(fā)性，處理實時性要求較低。為保障各系統(tǒng)解耦，并讓不同處理能力的系統(tǒng)能夠合理匹配，正常運行。每個業(yè)務系統(tǒng)內入口，盡量提供異步能力，提供了消息隊列機制，具體表現(xiàn)為業(yè)務系統(tǒng)api接收請求，將請求消息，送入消息隊列，并立即響應。業(yè)務系統(tǒng)內存處理系統(tǒng)，根據(jù)處理能力要求，啟動多服務，高并發(fā)消費消息處理，處理結果異步調用方。對于不能異步調用的服務，保障不存在gridlock問題，使之能夠通過擴展服務擴展服務并發(fā)能力，結合skywalking監(jiān)控流量及響應時間

17、分布，合理調整服務副本數(shù)。在每個服務內，對于讀多寫少的場景，我們充分利用緩存來加速請求的響應時間，以提高并發(fā)能力，同時降低對于數(shù)據(jù)庫的負載壓力。而對于幾乎不變化的產品、配件等型號及參數(shù)等產品庫信息，為了提高查詢效率，我們采用的是NoSQL方案，通過ES來實現(xiàn)數(shù)據(jù)查詢服務。3.5 連續(xù)性運營3.5.1 應用服務擴縮容以微服務架構部署的容器應用，在單個實例對業(yè)務的支撐能力不足時，應通過水平擴展的方式進行多實例部署，以支撐更多的業(yè)務請求。同時，為了減少系統(tǒng)資源的浪費，在業(yè)務量減少時，也應減少應用的實例數(shù)量，釋放出系統(tǒng)資源以供其他系統(tǒng)使用。（1）自動擴縮容基于CPU使用率的自動擴縮容可應用于CPU密集型的應用程序，在CPU使用率提高時能夠通過水平擴展來完成更多的計算工作?；谧远x業(yè)務指標的自動擴縮容可用于需要根據(jù)業(yè)務指標完成自動擴縮容