在大型數(shù)據(jù)中心IT基礎架構(gòu)的演進和容器在微服務時代大型數(shù)據(jù)中心中的應用實踐

在大型數(shù)據(jù)中心IT基礎架構(gòu)的演進和容器在微服務時代大型數(shù)據(jù)中心中的應用實踐目錄一、 大型數(shù)據(jù)中心IT架構(gòu)和演進 3(一) 大型數(shù)據(jù)中心的定義、流行架構(gòu)的發(fā)展歷程 3(二) 小架構(gòu)到大集中——傳統(tǒng)大型數(shù)據(jù)中心IT架構(gòu)形成 3(三) 數(shù)據(jù)安全、業(yè)務連續(xù)性需求引發(fā)的多中心架構(gòu) 5(四) 后“IOE”時代——虛擬化資源池 5(五) 云計算熱潮——基于openstack的云計算管理平臺架構(gòu) 6(六) 微服務興起——基于容器的云計算架構(gòu) 8二、 從虛擬化到容器云架構(gòu) 11(一) 物理機、虛擬機、容器的演化 11(二) 虛擬化Vs容器云 111. 虛擬機是什么 112. 容器是什么 123. 容器技術(shù)主要有4個特點： 134. 虛擬機vs容器 145. 集中式vs分布式 14(三) Doker和Kunbernetes 151. 什么是Doker 152. 什么是Kubernetes 173. Kubernetes的特點： 174. Kubernetes結(jié)構(gòu) 17(四) 基于kubernetes的容器云平臺 191. 容器云平臺功能介紹 192. 容器云架構(gòu)解析 20(五) 容器云的業(yè)務場景和建設方法 221. 適用的業(yè)務場景 222. 應用容器化改造過程 223. 應用容器化主要改造點 234. 容器云平臺集成方法論 245. 容器云平臺的應用發(fā)布 24三、 某運營商容器云管平臺的應用和運維實例 25作者版本號更新日期描述郭凱V1.02019-10-20創(chuàng)建、概要郭凱V1.1、V1.22019-10-30修訂、完善郭凱V1.32019-11-3修訂、完善郭凱V1.42019-11-4校對大型數(shù)據(jù)中心IT架構(gòu)和演進數(shù)據(jù)中心（DataCenter）是企業(yè)IT系統(tǒng)的核心，海量數(shù)據(jù)運算、交換、存儲的中心，關鍵信息業(yè)務應用的計算環(huán)境，集中管控各種基礎設施、平臺環(huán)境。而在金融、安全、公共事業(yè)、通訊、IT服務、云服務等行業(yè)都需要依賴龐大的數(shù)據(jù)中心架構(gòu)體系來支撐。大型數(shù)據(jù)中心的定義、流行架構(gòu)的發(fā)展歷程1.大型數(shù)據(jù)中心一般企業(yè)數(shù)據(jù)中心具備基礎CT網(wǎng)絡、計算資源、存儲資源，為企業(yè)提供IT支持。數(shù)據(jù)中心由設備規(guī)模、業(yè)務規(guī)模和架構(gòu)復雜度區(qū)分，我們可以人為定義為小型數(shù)據(jù)中心和大型數(shù)據(jù)中心。企業(yè)IT業(yè)務的支撐系統(tǒng)根據(jù)業(yè)務量大小就有所區(qū)別，小到一兩臺物理服務器，或者幾臺云主機，大道多個地域集中機房。在這里我們將體量相對較大，架構(gòu)相對復雜的IT環(huán)境稱之為大型數(shù)據(jù)中心。而多個數(shù)據(jù)中心之間可以形成互聯(lián)關系，為企業(yè)提供高可用、分布式架構(gòu)的IT解決方案。2.主要架構(gòu)發(fā)展歷程多年來的數(shù)據(jù)中心經(jīng)歷了獨立環(huán)境-集中建設—虛擬化+多中心-云化-微服務的演化進程。小架構(gòu)到大集中——傳統(tǒng)大型數(shù)據(jù)中心IT架構(gòu)形成獨立環(huán)境時代2000年前后，各大型企業(yè)的IT是由分支部門或分公司獨立建設，獨立交付本地化服務的。分散化IT建設是一個顯著的特點：每個局點都是一個局域網(wǎng)架構(gòu)，屬于小型數(shù)據(jù)中心，其中分別承擔了本地化的幾個業(yè)務。這就造成了一些不必要的投資和運維壓力：重復的基礎設施建設；重復的業(yè)務部署，但標準化不高，各地不統(tǒng)一；計算存儲資源浪費；集中數(shù)據(jù)傳輸成本，各局點之間數(shù)據(jù)消費困難；各局點都需要有專業(yè)的運維人員和業(yè)務開發(fā)人員，運維成本高。插入拓撲集中建設時代大家都意識到了資源和投資的浪費，IT企業(yè)開始嘗試實踐數(shù)據(jù)集中化的解決方案。恰逢傳輸網(wǎng)絡有了明顯的速率提升，省內(nèi)乃至國內(nèi)數(shù)據(jù)短時差傳輸不再是難以企及的了，此時有眾多解決方案咨詢公司以集中化改造為需求，提供IT咨詢、支持、實施服務。進入2005年前后，由各大運營商、央企開始，陸續(xù)完成核心業(yè)務的改造。集中化架構(gòu)的業(yè)務模式特點是，核心業(yè)務后臺服務部署于集中域，分支機構(gòu)僅使用業(yè)務平臺。集中域處理數(shù)據(jù)請求、分析數(shù)據(jù)、提供業(yè)務服務；前端業(yè)務話單僅提供數(shù)據(jù)采集和上傳。集中化架構(gòu)的IT架構(gòu)特點是體量龐大，資源調(diào)度靈活。企業(yè)集中建設了能滿足區(qū)域內(nèi)的所有業(yè)務的IT設施，包括計算資源（X86服務器、小型機、大型機）、存儲資源（大體量集中式存儲）、網(wǎng)絡資源（本地數(shù)通網(wǎng)絡和異地傳輸網(wǎng)絡）、中間件軟件（軟負載均衡、web服務、代理服務等）、數(shù)據(jù)庫資源（oracle、DB2等大型數(shù)據(jù)庫）插入拓撲此時，由于需要滿足集中化帶來的龐大計算和存儲壓力，企業(yè)通常曹勇小型機+FC集中存儲+大型數(shù)據(jù)庫的架構(gòu)。這也就是我們后來所說的“IOE”——IBM小型機+EMC存儲+Oracle數(shù)據(jù)庫。數(shù)據(jù)安全、業(yè)務連續(xù)性需求引發(fā)的多中心架構(gòu)2001年9月11日，爆發(fā)了舉世震驚的9·11事件，異地容災，業(yè)務可持續(xù)訪問的概念再次被提及，并提升到一個新的高度。此前雖已有此類的概念提出，但是迫于龐大的投資和閑置資源的維護成本，企業(yè)和機構(gòu)僅處于觀望研究狀態(tài)。隨著國內(nèi)數(shù)據(jù)集中的演進，核心業(yè)務和核心數(shù)據(jù)大多存在于一個大型數(shù)據(jù)中心，這就對數(shù)據(jù)安全和業(yè)務持續(xù)性提出了重大挑戰(zhàn)，備份、容災、雙活被提上建設日程。備份原則：多種備份手段復合，熱備冷備兼顧。存儲快照—在集中式存儲上進行快照策略配置，用于滿足測試開發(fā)環(huán)境的需求，以及對人為誤操作造成的邏輯錯誤的故障恢復。集中備份—在一個數(shù)據(jù)中心內(nèi)，采用NBU等統(tǒng)一備份平臺和軟件，對數(shù)據(jù)中心內(nèi)所有對象進行周期性備份，包括系統(tǒng)、數(shù)據(jù)庫數(shù)據(jù)、數(shù)據(jù)庫結(jié)構(gòu)、文件系統(tǒng)數(shù)據(jù)等。用于面臨某個資源故障造成數(shù)據(jù)破壞時的數(shù)據(jù)恢復。異地復制備份—將數(shù)據(jù)備份至異地的數(shù)據(jù)中心，有同步和異步兩種模式，通常用于大面積數(shù)據(jù)破壞和數(shù)據(jù)中心級別故障的恢復。冷備份—通常指磁帶庫等可拆卸存儲介質(zhì)的備份手段。備份磁帶被檢測有效后存放于特殊環(huán)境保障的儲存點，是數(shù)據(jù)保障的最后一道屏障。容災和高可用原則：分級對待，分標準建設。基礎業(yè)務：本地高可用重要業(yè)務：本地雙活高可用核心業(yè)務：本地雙活高可用+異地容災數(shù)據(jù)中心：兩地三中心，基于同城雙活+異城災備的ICT解決方案插入兩地三中心拓撲后“IOE”時代——虛擬化資源池去“IOE”背景：自2013年棱鏡門事件之后，我國政府已經(jīng)意識到政府數(shù)據(jù)安全的重要性，也加強了政府數(shù)據(jù)安全方面的工作，有報道稱，思科、IBM、谷歌、高通、英特爾、蘋果、甲骨文、微軟并稱為美國的“八大金剛”，他們一方面與美國政府、軍隊保持著緊密的聯(lián)系；另一方面在中國長驅(qū)直入，占據(jù)眾多關鍵領域，導致美國情報部門通過這些設備、軟件、網(wǎng)絡獲取信息，給中國的信息安全帶來巨大威脅?！叭OE”與設備采購國產(chǎn)化、自主研發(fā)等口號掛鉤，帶有一定的政治色彩。如去年win8也未進入中央機關政府采購名單。在去“IOE”浪潮下，小型機、集中存儲、大型核心數(shù)據(jù)庫逐步退出舞臺，機關和企業(yè)面臨的是X86化、分布式存儲、大型庫拆分的改造之路。此時x86虛擬化架構(gòu)（kvm、阿里ECS、vmware等）+分布式存儲解決方案（CephSDS）+輕量級數(shù)據(jù)庫（mysql等）+核心數(shù)據(jù)庫一體機的解決方案占了較大的比例。同時業(yè)務改造也呈現(xiàn)出龐大的需求和緊鑼密鼓的工程狀態(tài)。虛擬化技術(shù)在此時進入成熟期，眾多機構(gòu)和企業(yè)以虛擬化為主要的IaaS層架構(gòu)模式。其優(yōu)勢是：能夠出色的協(xié)調(diào)各業(yè)務之間的資源需求，避免資源浪費；能夠滿足高可用集群需求，保障業(yè)務持續(xù)性；能夠快速擴容、部署、回收，提升維護效率；系統(tǒng)硬件解耦，開源工具支持，減弱對供應廠商的依賴性；全球IT社區(qū)化，技術(shù)演進提升快。云計算熱潮——基于openstack的云計算管理平臺架構(gòu)隨著虛擬化資源池的越來越龐大，原生的管理平臺已經(jīng)無法納管過多的虛擬化節(jié)點，此時需要一個管理平臺來實現(xiàn)統(tǒng)一納管、統(tǒng)一配置分發(fā)、統(tǒng)一資源計費、統(tǒng)一告警分析等一些列的管理功能和服務功能。且該平臺必須是開放的，可維護更新的，多接口的，兼容性強的，它就是openstack。同時，在初創(chuàng)型和小型企業(yè)乃至IT愛好者中，有對少量計算資源的需求，或者數(shù)據(jù)庫、應用軟件等PaaS、SaaS層的實際需求。公有云的出現(xiàn)解決的這一些的需求。2010年Openstack項目成立，此后逐漸有眾多IT廠商和解決方案廠商參與共同建設，形成了openstack社區(qū)。由于其開源的技術(shù)結(jié)構(gòu)，在互聯(lián)網(wǎng)、政務管理、運營商中開始實踐基于openstack架構(gòu)的云管理平臺，用于納管已有的虛擬化資源池，這就是我們所說的私有云。同時公有云環(huán)境在阿里、騰訊、電信等領軍企業(yè)的帶領下走向繁榮。Openstack是一個云管操作平臺，用于編排云資源。其是由控制節(jié)點，計算節(jié)點，網(wǎng)絡節(jié)點，存儲節(jié)點四大部分組成?？刂乒?jié)點負責對其余節(jié)點的控制，包含虛擬機建立，遷移，網(wǎng)絡分配，存儲分配等等。計算節(jié)點負責虛擬機運行網(wǎng)絡節(jié)點負責對外網(wǎng)絡與內(nèi)網(wǎng)絡之間的通信存儲節(jié)點負責對虛擬機的額外存儲管理等等Openstack包含了眾多的組件模塊，來實現(xiàn)一系列的服務功能，最終實現(xiàn)對底層資源的同意調(diào)度和對外交付。模塊名稱提供服務功能描述HorizonDashboard提供了一個基于web的自服務門戶，與OpenStack底層服務交互，諸如啟動一個實例，分配IP地址以及配置訪問控制NovaCompute在OpenStack環(huán)境中計算實例的生命周期管理。按需響應包括生成、調(diào)度、回收虛擬機等操作。NeutronNetworking確保為其它OpenStack服務提供網(wǎng)絡連接即服務“Quantum”–>NeutronKeystoneIdentityManagement為其他OpenStack服務提供認證和授權(quán)服務，為所有的OpenStack服務提供一個端點目錄。SwiftObjectStorage通過一個RESTful,基于HTTP的應用程序接口存儲和任意檢索的非結(jié)構(gòu)化數(shù)據(jù)對象。它擁有高容錯機制，基于數(shù)據(jù)復制和可擴展架構(gòu)。它的實現(xiàn)并像是一個文件服務器需要掛載目錄。在此種方式下，它寫入對象和文件到多個硬盤中，以確保數(shù)據(jù)是在集群內(nèi)跨服務器的多份復制TroveDatabaseService提供管理數(shù)據(jù)庫即服務配置關系和非關系數(shù)據(jù)庫引擎節(jié)點的Trove相關，同時提供Trove在Horizon中的管理面板IronicBareMetalProvisioning提供裸金屬管理服務，NovaBaremetal驅(qū)動程序HeatOrchestration提供了基于模板來實現(xiàn)云環(huán)境中資源的初始化，依賴關系處理，部署等基本操作，也可以解決自動收縮,負載均衡等高級特性。SaharaDataProcessingService使用用戶能夠在Openstack平臺上便于創(chuàng)建和管理Hadoop以及其他計算框架集群，微服務興起——基于容器的云計算架構(gòu)在openstack云管平臺下，運行的業(yè)務本質(zhì)沒有變化，仍然是集中式的應用架構(gòu)。然而市場和業(yè)務需求的變化日新月異，這就造成了后端應用系統(tǒng)開發(fā)部署跟不上市場需求，于是敏捷開發(fā)的概念被提出。同時業(yè)務模塊之間的關聯(lián)關系時有依賴性的，強耦合的，一旦某個業(yè)務模塊的故障，可能造成整個業(yè)務的崩潰。此時容器技術(shù)日趨成熟，為業(yè)務解耦帶來新的方向。那么怎么才能把業(yè)務部署快起來，業(yè)務依賴性弱下來？我們從業(yè)務維度找到了解決方案，將集中式的中大型業(yè)務應用拆分成多個微型服務，各個微服務可被獨立部署，各個微服務之間是松耦合的。什么是微服務簡單的說，微服務架構(gòu)就是以業(yè)務域或業(yè)務功能為邊界，將一個大而全的應用拆分為可以獨立開發(fā)，獨立部署，獨立測試，獨立運行的一組小的應用，應用之間使用輕量級通信機制互聯(lián)，并且他們可以通過自動化方式部署。微服務特征單一負載小職責少，輕量級通訊，業(yè)務數(shù)據(jù)獨立，技術(shù)多樣性。正是因為小，所以每個微服務的邏輯相對簡單，代碼量也小很多，進而修復問題及修改變更會快很多；而多個微服務可以并行演進，從而可以縮短測試，部署和發(fā)布的時間；同樣是因為獨立，每個微服務都可以根據(jù)實際情況，單獨的橫向拓展；因為輕量級通訊，每個微服務才可以獨立起來，貫徹高內(nèi)聚低耦合的架構(gòu)思想。單體服務架構(gòu)圖微服務架構(gòu)圖微服務的優(yōu)點每個微服務都很小，這樣能聚焦一個指定的業(yè)務功能或業(yè)務需求。微服務能夠被小團隊單獨開發(fā)，這個小團隊可以是2到5人的開發(fā)人員組成。微服務是松耦合的，是有功能意義的服務，無論是在開發(fā)階段或部署階段都是獨立的。微服務能使用不同的語言開發(fā)。微服務允許容易且靈活的方式集成自動部署，通過持續(xù)集成工具，如Jenkins,bamboo。微服務易于被一個開發(fā)人員理解，修改和維護，這樣小團隊能夠更關注自己的工作成果。無需通過合作才能體現(xiàn)價值。微服務允許你利用融合最新技術(shù)。微服務能夠即時被要求擴展。微服務能部署中低端配置的服務器上。易于和第三方集成。每個微服務都有自己的存儲能力，可以有自己的數(shù)據(jù)庫。也可以有統(tǒng)一數(shù)據(jù)庫。微服務的缺點運維開銷及成本增加：單體服務可能只需部署至一小片應用服務區(qū)集群，而微服務架構(gòu)可能變成需要構(gòu)建/測試/部署/運行數(shù)十個獨立的服務，并可能需要支持多種語言和環(huán)境。隱式接口及接口匹配問題：把系統(tǒng)分為多個協(xié)作組件后會產(chǎn)生新的接口，這意味著簡單的交叉變化可能需要改變許多組件，并需協(xié)調(diào)一起發(fā)布。分布式系統(tǒng)的復雜性：作為一種分布式系統(tǒng)，微服務引入了復雜性和其他若干問題，例如網(wǎng)絡延遲、容錯性、消息序列化、不可靠的網(wǎng)絡、異步機制、版本化、差異化的工作負載等，開發(fā)人員需要考慮以上的分布式系統(tǒng)問題。異步機制：微服務往往使用異步編程、消息與并行機制，如果應用存在跨微服務的事務性處理，其實現(xiàn)機制會變得復雜化?？蓽y性的挑戰(zhàn)：在動態(tài)環(huán)境下服務間的交互會產(chǎn)生非常微妙的行為，難以可視化及全面測試。微服務的IT解決方案各個微服務運行的環(huán)境就是容器。我們通過容器管理平臺對容器進行編排，來實現(xiàn)服務的負載均衡和高可用，來優(yōu)化服務間的關聯(lián)關系。目前的主流容器引擎是docker，容器管理平臺中kunbernetes則獨樹一幟。由于Kubernetes本身就是微服務架構(gòu)，而且相較更加適合微服務和DevOps的設計，目前主流的解決方案為X86服務器（+VM虛擬機）+Doker+Kunbernetes的架構(gòu)，我們將在下文進行展開論述。從虛擬化到容器云架構(gòu)物理機、虛擬機、容器的演化物理機->虛擬機：以前構(gòu)建應用程序時使用的是宿主操作系統(tǒng)提供的資源，在部署應用程序時也使用了相同的模式。但如果想擴展應用程序可能需要另一臺硬件服務器。而隨著數(shù)量不斷增加，成本和其他資源（如硬件和能源消耗）也會隨之增加。隨著基礎設施的不斷增加、硬件資源使用效率低、操作系統(tǒng)復雜多樣這些問題促成了硬件虛擬化的發(fā)展，于是虛擬機（VM）出現(xiàn)了，我們通過虛擬機來優(yōu)化IT基礎設施。虛擬機具有自己的客戶操作系統(tǒng)，運行在單個物理機或宿主操作系統(tǒng)中。我們因此能夠運行多個應用程序，而無需安裝大量物理機。虛擬機->容器：宿主操作系統(tǒng)可以確保在不同虛擬機之間進行系統(tǒng)性的資源分配和負載均衡。虛擬機降低了軟件維護的難度和成本，不過仍然可以進一步優(yōu)化。例如，并非所有的應用程序在客戶操作系統(tǒng)環(huán)境中都會按預期運行。此外，即使是運行簡單的進程，客戶操作系統(tǒng)也需要大量資源。這些問題促成了下一個創(chuàng)新：容器化。與特定于操作系統(tǒng)的虛擬機不同，容器特定于應用程序，因為更加輕量級。此外，虛擬機可以運行多個進程，而容器作為單個進程運行。虛擬化Vs容器云虛擬機是什么虛擬機是物理機的抽象，其中每個VM都有自己的客戶操作系統(tǒng)。這意味著初始化每個虛擬機需要創(chuàng)建物理機的虛擬抽象層，然后設置完整的OS啟動。因此，就存儲，RAM和CPU而言，每個VM將消耗大量系統(tǒng)資源。PhysicalHardware：基礎硬件，包括CPU、內(nèi)存、磁盤、IO設備等。Hypervisor：虛擬化技術(shù)的核心,負責虛擬化硬件設備，分配資源，并加載所有虛擬機的客戶操作系統(tǒng)PhysicalHardware：基礎硬件，包括CPU、內(nèi)存、磁盤、IO設備等。Hypervisor：虛擬化技術(shù)的核心,負責虛擬化硬件設備，分配資源，并加載所有虛擬機的客戶操作系統(tǒng)VirtualHardware：由Hypervisor虛擬出來的硬件設備，提供給虛擬機使用，對于虛擬機而言它就是真實的物理設備VirtualMachines：根據(jù)虛擬出來的設備創(chuàng)建的邏輯計算機，相互獨立的OS和應用容器是什么容器是英文單詞Container的直譯。LinuxContainer它是一種內(nèi)核輕量級的操作系統(tǒng)層虛擬化技術(shù)。LinuxContainer主要由Namespace和Cgroup兩大機制來保證實現(xiàn)。容器是應用層的抽象，它將代碼和依賴關系打包在一起。多個容器可以在同一臺機器上運行，并與其他容器共享操作系統(tǒng)內(nèi)核，每個容器在用戶空間中作為獨立進程運行，相互之間不會有任何接口（類似iPhone的app）。容器占用的空間比VM少（容器鏡像的大小通常為幾十MB），可以處理更多的應用程序，并且需要更少的硬件資源。Infrastructure：基礎硬件設備OperationgSystem：操作系統(tǒng)DockerEngine：使用Docker的組件和服務構(gòu)建和運行容器，包括Dockerdaemon、CLI和RESTAPI等Bins/Libs:各種依賴系統(tǒng)文件以及庫文件，應用的所有依賴都打包在Docker鏡像中APP：應用的源代碼與它的依賴都打包在Docker鏡像中容器技術(shù)主要有4個特點：極其輕量：只打包了必要的Bin/Lib；秒級部署：根據(jù)鏡像的不同，容器的部署大概在毫秒與秒之間（比虛擬機強很多）；易于移植：一次構(gòu)建，隨處部署；彈性伸縮：Kubernetes、Swam、Mesos這類開源、方便、好使的容器管理平臺有著非常強大的彈性管理能力。虛擬機vs容器容器和虛擬機具有類似的資源隔離和分配優(yōu)勢，但功能不同，因為容器是虛擬化操作系統(tǒng)而不是虛擬化硬件。相對虛擬機而言，容器不攜帶操作系統(tǒng)，只包含應用相關的依賴，共享操作系統(tǒng)的內(nèi)核，直接運行在物理設備上，體積更小，更便攜高效，啟動速度更快。Docker的理念是隔離單個應用程序，而不是整個系統(tǒng)，還是運行在同一個系統(tǒng)上。而VM則是整個系統(tǒng)的之間的隔離，所以相對來說Docker的隔離性要差一點。優(yōu)點：同樣都是提高資源的使用率，docker相對虛擬機來說，體積更小，更便攜高效，啟動速度更快，并且遷移更方便，容器內(nèi)有完整的應用相關的環(huán)境和依賴。缺點:隔離性較差，容器共享內(nèi)核，如果需要調(diào)整內(nèi)核參數(shù)可能會影響到當前運行的所有容器，虛擬機則是獨立運行的。集中式vs分布式集中式部署的問題：依賴服務器環(huán)境，需要各服務器資源統(tǒng)一。無法充分利用服務器等資源，使用率一般僅能達到70%。無法或很難做到容災恢復。需要人工進行服務擴容，修改服務配置。服務資源散亂(域名，服務器，負載，數(shù)據(jù)庫)，無法做集中管理。時間消耗較多，增加運維成本。需要借助第三方工具進行資源監(jiān)控，較為麻煩。需要對開發(fā)、測試、生產(chǎn)環(huán)境進行區(qū)別管理。分布式部署的好處：增大了系統(tǒng)的容量，可以將分布在各處的資源綜合利用。而這種利用對用戶而言是透明的；可以將負載由單個節(jié)點轉(zhuǎn)移到多個，從而提高效率；分布式技術(shù)可以避免由于單個節(jié)點失效而使整個系統(tǒng)崩潰的危險，加強了系統(tǒng)的可用性；使系統(tǒng)模塊化，可以提高模塊的重用度，同時系統(tǒng)的擴展性也更高了；提高了開發(fā)和發(fā)布速度，因為軟件服務模塊被拆分，開發(fā)和發(fā)布都可以并行。Doker和Kunbernetes什么是DokerDocker是PaaS提供商dotCloud開源的高級容器引擎，Docker自2013年以來日益熱門，至今已經(jīng)是業(yè)界主要選擇。Docker快速敏捷（啟動、停止都是以秒或毫秒為單位的），隔離輕量級（不添加額外的操作系統(tǒng)），這些實際上是Linux內(nèi)核提供的能力，Docker是沿用了這些特性，Docker最大的創(chuàng)新點在于Docker鏡像的設計，下面是張Docker鏡像的層次圖，分層的文件系統(tǒng)，一層層地搭建出一個完整的容器運行環(huán)境。一個docker鏡像由多個可讀的鏡像層組成，然后運行的容器會在這個docker的鏡像上面多加一層可寫的容器層，任何的對文件的更改都只存在此容器層。因此任何對容器的操作均不會影響到鏡像。這樣一來，我們可以像樂高玩具一樣搭建各式各樣的鏡像，同時Docker提供了一整套鏡像存儲方案（DockerRegistry），可以非常方便地獲取想要的鏡像，然后快速地啟動運行，而不必像以前那樣安裝各種麻煩的軟件依賴。Docker解決了應用的發(fā)布、構(gòu)建和運行，創(chuàng)建了很多想象空間，所以基于Docker衍生出了很多新的解決方案，特別是PaaS容器管理平臺，這些PaaS平臺更加靈活，更加適應企業(yè)，Kubernetes是其中最具代表性的一員。什么是KubernetesKubernetes一個用于容器集群的自動化部署、擴容以及運維的開源平臺。通過Kubernetes,你可以快速有效地響應用戶需求;快速而有預期地部署你的應用;極速地擴展你的應用;無縫對接新應用功能;節(jié)省資源，優(yōu)化硬件資源的使用。為容器編排管理提供了完整的開源方案。Kubernetes的特點：網(wǎng)絡模型kubernetes采用了三層網(wǎng)絡模型，分為PodIP,ClusterIP,NodeIP。用簡單的話來說，kubernetes在內(nèi)部使用自己的網(wǎng)絡進行通訊，這樣做一個最直接的好處是我們不用再擔心端口沖突的問題。對象在kubernetes中，萬物皆對象。路由(Ingress)、服務(Service)、部署(Deployment)、存儲(Storage/PV/PVC)、容器(Pod)、角色(Role)、賬戶(Accoutn)、配置(ConfigMap)等等。通過管理這些對象來管理整個kubernetes集群。聲名式管理Kubernetes不在使用命令式語言，轉(zhuǎn)為采用聲名式進行資源管理。Kubernetes結(jié)構(gòu)Kubernetes由Master節(jié)點和Worker節(jié)點組成。master節(jié)點是Kubernetes的大腦，而woker節(jié)點則是kubernetes中實際運行服務的勞動者。Master主要由ETCD/ControllerManager/ApiServer/Schedular能成，ETCD主要負責存儲各個woker節(jié)點的狀態(tài)和其它相關數(shù)據(jù)，可以理解為kubernetes的數(shù)據(jù)庫。ControllerManager負責維護集群的狀態(tài)，比如故障檢測、自動擴展、滾動更新等Scheduler負責資源的調(diào)度，按照預定的調(diào)度策略將Pod調(diào)度到相應的機器上Worker主要由kubelet和kube-proxy組成，一般還會安裝kube-dns組件。kubelet負責維護容器的生命周期，同時也負責Volume（CVI）和網(wǎng)絡（CNI）的管理；kube-proxy負責為Service提供cluster內(nèi)部的服務發(fā)現(xiàn)和負載均衡；kube-dns負責為整個集群提供DNS服務，通過Service名稱訪問相應的服務基于kubernetes的容器云平臺容器云平臺功能介紹容器云平臺，是一個基于docker容器，借助Kubernetes進行容器編排調(diào)度，提高資源利用率，并通過自研系統(tǒng)實現(xiàn)業(yè)務劃分、應用操作、彈性擴縮、實例自愈、服務監(jiān)控等功能的Paas容器云平臺。借助容器云平臺，租戶無需登錄后端實例主機可以進行應用發(fā)布，應用暫停、啟動、重啟、參數(shù)修改，代碼包下載等操作。并且配置健康檢測之后，平臺可以直觀反應出應用各實例的運行狀態(tài)。同時，容器云平臺也提供性能監(jiān)控圖線，讓業(yè)務維護人員更加方便的查看和分析業(yè)務的實時運行情況。容器云平臺是為整個數(shù)據(jù)中心提供分布式調(diào)度與協(xié)調(diào)功能，實現(xiàn)數(shù)據(jù)中心級彈性伸縮能力的軟件堆棧，它將所有數(shù)據(jù)中心的資源當做一臺計算機來調(diào)度。容器云平臺提供網(wǎng)頁界面和CLI，實現(xiàn)資源自動化管理、進程調(diào)度、內(nèi)部進程通訊、簡化分布式服務的安裝和管理，方便對集群和其中的服務遠程地管理和監(jiān)控，使企業(yè)像使用一臺主機一樣使用分布式數(shù)據(jù)中心的多個集群資源，進行應用的創(chuàng)建、發(fā)布和資源的彈性擴容與縮容。容器云架構(gòu)解析功能模塊架構(gòu)系統(tǒng)環(huán)境：搭建在Linux基礎上，擁有企業(yè)級的安全性、穩(wěn)定性和可靠性容器API：Docker編排管理：Kubernetes容器云平臺核心功能樹管理平臺：定制自主開發(fā)，運維和開發(fā)的統(tǒng)一入口Dashboard

主機性能展示、容器性能展示、應用性能展示、集成指標展示、事件指標展示等監(jiān)控告警模塊

監(jiān)控數(shù)據(jù)采集、日志管理、告警管理和事件管理編排調(diào)度模塊

基于CPU使用率、內(nèi)存使用率、服務并發(fā)數(shù)、響應時間等容量數(shù)據(jù)，通過定制的調(diào)度算法實現(xiàn)服務的自動彈性擴縮容和遷移。日志中心

采用Elasticsearch、Logstash、Graylog構(gòu)建，實現(xiàn)對容器日志的統(tǒng)一存儲及檢索資源管理模塊

及時發(fā)現(xiàn)容器云內(nèi)的資源、服務的變更，動態(tài)實現(xiàn)配置中心數(shù)據(jù)實時更新，為平臺調(diào)度提供數(shù)據(jù)支持。服務目錄管理、規(guī)則管理、CMDB信息安全管理

用戶管理、權(quán)限策略管理和統(tǒng)一認證接口持續(xù)集成

鏡像構(gòu)建、集成測試、流程管理和上線管理技術(shù)架構(gòu)：開發(fā)人員上傳代碼到git或SVN上，jenkins會自動發(fā)現(xiàn)代碼更新并構(gòu)建為docker鏡像包，上傳到鏡像倉庫，同時把版本信息同步到容器管理平臺；應用管理用戶通過容器管理平臺手動或者自動的方式發(fā)布更新后的版本，由kubernetes的master節(jié)點調(diào)度相應容器到最優(yōu)的node節(jié)點中，被調(diào)度的node節(jié)點收到任務后，由node節(jié)點中的kubelet組件啟動相應的容器；外部用戶訪問業(yè)務時通過我們的硬負載均衡器（array或者F5）做代理，路由到NODE節(jié)點，在由kubernetes的proxy組件作為為軟負載到達最終要訪問的容器上，保證業(yè)務的持續(xù)可用，避免了容器隨機漂移，IP地址變化的問題容器云的業(yè)務場景和建設方法適用的業(yè)務場景容器云平臺支持各類應用（包括前端無狀態(tài)、前端有狀態(tài)應用和后臺進程類系統(tǒng)）的快速集成上云。無狀態(tài)的應用（所謂無狀態(tài)指的是應用實例中無session信息或者無特定的配置信息）；（強烈推薦）有狀態(tài)的應用：前端類WEB應用，依然需要會話保持等負載均衡策略，session、共享文件等存放在本地。后臺進程類系統(tǒng)：后臺進程類應用，進程服務間的調(diào)用通過配置中心的方式實現(xiàn)。目前適合上云的應用類型：純java應用、tomcat應用、weblogic應用、nginx、php、apache、python類應用。應用容器化改造過程POC測試通常我們嘗試做業(yè)務改造前，要進行POC測試。我們建議挑選應用結(jié)構(gòu)分布式、無狀態(tài)；業(yè)務類型面向互聯(lián)網(wǎng)，訪問集中，突發(fā)量大，業(yè)務更新快的。注：無狀態(tài)應用意思是在應用的訪問中沒有必然的上下文關系，即這個應用不會保存任何信息，當前會話訪問的服務器如果宕機不會影響任何應用以及下一次的訪問一般對于有狀態(tài)的應用的做法是讓sessionid保存在客戶端cookies，通過redis內(nèi)存數(shù)據(jù)庫保存會話狀態(tài)信息達到即使每次訪問請求的不是同一個web服務器也不會需要用戶重新登錄等操作。應用容器化改造過程(tomcat)應用容器化主要改造點熱點數(shù)據(jù)緩存建議應用在設計時將熱點數(shù)據(jù)存放到緩存服務器（如Redis、Memcached）中，在啟動時避免執(zhí)行加載緩存動作，提高應用系統(tǒng)啟動速度。無狀態(tài)化改造建議應用開發(fā)設計時將用戶的會話信息保存到緩存服務器（如Redis、Memcached）中，根據(jù)用戶的唯一標識session_id來對緩存服務器進行存取用戶的會話信息，會話信息與應用實例分離，實現(xiàn)應用無狀態(tài)化。定時任務與應用分離建議將定時任務與應用分開，不要封裝到一個應用包中。數(shù)據(jù)庫連接池設置如果連接池的初始值設置過大會造成數(shù)據(jù)庫無法及時響應大量并發(fā)連接而導致數(shù)據(jù)異常，建議初始值設置不宜太大。不要在容器中存儲數(shù)據(jù)容器是一次性的，當容器被停止、銷毀或替換時，應用在容器中存儲的數(shù)據(jù)同樣會被銷毀。不要依賴IP地址容器IP是不固定的，如果應用或微服務需要與其他容器通訊，可以選擇更合適的方式與其他容器進行通訊。容器云平臺集成方法論調(diào)研及需求分析了解系統(tǒng)現(xiàn)狀明確業(yè)務影響范圍理解運營現(xiàn)狀風險評估需求分析平臺集成規(guī)劃與設計平臺架構(gòu)設計平臺資源規(guī)劃業(yè)務系統(tǒng)部署規(guī)劃系統(tǒng)割接規(guī)劃系統(tǒng)演進規(guī)劃平臺集成實施與測試平臺部署平臺能力測試配合應用改造聯(lián)調(diào)測試割接、上線平臺優(yōu)化及維護平臺監(jiān)控平臺性能分析評估平臺優(yōu)化調(diào)整平臺維護容器云平臺的應用發(fā)布發(fā)布流程：業(yè)務提供符合上云標準的應用代碼包；選擇容器云平臺提供的基礎鏡像及中間件版本；租戶通過平臺發(fā)布，自動創(chuàng)建業(yè)務鏡像，通過發(fā)布業(yè)務鏡像后替換當前鏡像，完成業(yè)務的發(fā)布或滾動升級；某運營商容器云管平臺的應用和運維實例近年來，**移動一直致力于網(wǎng)管支撐系統(tǒng)能力中心化改造，以公司大IT中臺戰(zhàn)略為背景，推進業(yè)務中臺O域支撐能力的建設，實現(xiàn)架構(gòu)的云化、微服務化、中心化。8月7日，**移動云計算支撐中心和網(wǎng)管中心共同協(xié)作，推進性能中心業(yè)務實現(xiàn)了異構(gòu)雙平面的部署架構(gòu)，至此浙江首個OSS4.0系統(tǒng)在容器云平臺ARM架構(gòu)和X86架構(gòu)下正式商用落地。基于ARM的容器云平臺架構(gòu)相對于X86架構(gòu)，ARM架構(gòu)下的計算平臺能夠使用精簡指令和縱核架構(gòu)帶來更強的整體性能、單核面積小可以取得較高的能耗比、擁有開放架構(gòu)和靈活的IP授權(quán)機制容易實現(xiàn)自主可控；在ARM架構(gòu)授權(quán)上，通過優(yōu)化分支預測算法、提升運算單元數(shù)量、改進內(nèi)存子系統(tǒng)架構(gòu)等一系列微架構(gòu)設計，大幅提高處理器核性能。本次系統(tǒng)上線硬件采用了華為Taishan系列2280V2（2個鯤鵬920處理器，64核，2.6Ghz）均衡型ARM服務器，OS選用CentOS7.6.1810-aarch64位操作系統(tǒng)，中間件k8s版本選用1.13.5，借助鯤鵬ARM處理器整機方式的對外提供服務，實現(xiàn)容器云管理平臺對X86和ARM架構(gòu)的同時納管，支持IT系統(tǒng)國產(chǎn)化演進。OSS4.0及性能中心介紹面向OSS4.0架構(gòu)，**移動啟動了網(wǎng)管能力中心化改造，并將微服務平臺管控延伸到了O域。啟動了性能中心和編排中心的建設，其中性能中心業(yè)務系統(tǒng)為滿足集團四輪驅(qū)動業(yè)務全覆蓋需求，圍繞移動業(yè)務、家庭業(yè)務、政企業(yè)務和新業(yè)務的設備管理、業(yè)務管理和流程管理展開，主要包括：移動業(yè)務子中心，無線網(wǎng)優(yōu)子中心，有線業(yè)務子中心。為充分驗證ARM架構(gòu)下服務的可用性，本次ARM商用選用性能中心的家客業(yè)務的3個應用模塊和5個能力模塊做功能調(diào)測。業(yè)務改造適配上云為配合性能中心業(yè)務的遷移上線，**移動云計算支撐中心容器云平臺對平臺適配性、引擎調(diào)度、基礎鏡像等方面進行了改造。容器云平臺適配性改造容器云管理平臺具備統(tǒng)一管理“多”運行平面的能力，因此可在不影響現(xiàn)有x86運行平面承載業(yè)務的基礎上增加一個ARM運行平面，借助容器云管理平臺的快速擴展能力，納管ARM運行平面，使平臺應用實例在異構(gòu)雙平面平滑切換調(diào)度引擎和基礎鏡像改造**移動云計算支撐中心容器云平臺采用K8S開源調(diào)度引擎，介于ARM服務器指令集不同，需要對K8S組件以及docker等組件進行ARM服務器集群適配部署集成?；A鏡像中包含了應用運行的依賴環(huán)境。由于x86和ARM的指令集的差異，需要重新在ARM服務器上通過Docker