前言

容器云項目是我司規劃建設的基礎設施云計算PaaS平臺的嘗試，希望通過容器化PaaS平臺的建設，支持正在建設的微服務架構應用，同時也為適應公司互聯網業務發展，滿足業務快速開發和迭代的需求，逐步建立標準化的開發、測試、運維環境，形成適用于公司的DevOps(開發運維一體化)過程，完善開發、測試、部署、運維監控工具鏈和自動化流程，提升自主敏捷研發、持續集成的能力;同時基于容器云平臺，逐步建立起企業級的服務中臺，實現大中臺-小前端的基礎架構，更好的支持公司業務應用的開發，專注于業務應用的研發，提升IT對業務變化需求的快速響應能力。解決傳統單體應用之間難以集成和共享的問題;通過采用標準化的容器技術和標準化的鏡像輸出，為開發測試生產提供一致性的環境;利用容器云的彈性伸縮能力實現對互聯網金融業務流量快速變化的支持。

一、背景和原因

目前我司已經完成IaaS(Infrastructure as a Service)虛擬化建設，采用了Vmware和超融合技術;IaaS虛擬化層提供了對存儲、網絡、計算資源的管理，但無法提供對公司軟件、工具、中間件等的管理。按照云計算的三種類型，建設PaaS( Platform as a Service)平臺將有助于我們實現這些目標，同時提升敏捷開發能力，自動化運維能力。但PaaS平臺技術一直不成熟，存在諸多技術難點。隨著以Docker為代表的容器技術的出現和發展并逐步成熟，使我們看到構建基于容器技術的輕量化PaaS平臺——容器云平臺的可行性。

1. 容器云定義、作用

容器云，是輕量化PaaS平臺的一種容器化實現方式。是基于容器技術、容器調度編排技術和支撐容器運行操作系統技術、分布式技術上構建的云計算平臺。

從PaaS功能來說，PaaS提供應用開發、應用托管、應用運維等能力。也就是說在PaaS上，客戶可以開發、測試應用，用戶可以托管應用到PaaS的運行時環境，同時PaaS提供給客戶應用服務運維的能力(比如應用管理、監控、日志、安全等)。

PaaS平臺是以應用開發為中心，以解決應用全生命周期管理、中間件云服務、基礎資源的高效利用。從應用的開發、部署，到運維的全流程生命周期管理，實現應用的自動伸縮、彈性擴展、灰度發布以及監控告警、故障分析、自動遷移、自動恢復;提供豐富的預集成服務, 把通用的軟件能力服務化，使得應用能快速擁有分布式的高可用性、高可擴展性;通過對底層資源的抽象和資源層的隔離，盡可能地共享或平攤資源，以提高資源整體使用率，從而降低基礎設施的投入。

要實現這么多能力，PaaS技術存在一些難點，比如如何把IaaS層的能力更無縫的融合到PaaS;如何把開發能力，特別是IDE工具部署到云上(eclipse 提供云上開發服務);數據存儲和動態遷移的問題等。容器技術提供了一種選擇，可以首先構建輕量化PaaS，實現應用托管、應用運維能力，同時可以建立持續集成的環境，無縫對接容器云平臺。

2. 容器云帶來什么新技術新思想

容器云是輕量化PaaS的一種實現方式，容器技術的發展促進了PaaS平臺的落地，部分的解決了PaaS平臺的技術難點問題。隨著容器技術和PaaS平臺技術的發展，容器云將會更加成熟。

容器技術特點又非常適合微服務架構，使微服務架構應用的部署和運維更加便利，并且可以很好的解決彈性伸縮、灰度發布等運維難點。

容器和容器云更促進了DevOps思想的發展成熟，并找到了落地的途徑。容器云為持續集成和持續部署提供了便利的方式，也提供了開發、測試、生產等環境一致性的途徑。

容器技術改變了應用部署和管理的方式。容器云平臺、微服務架構和DevOps方法論相輔相成，相互促進，帶來了應用開發、應用部署、應用運維等全生命周期管理的新方法和新手段，也為大數據應用、AI應用等在云計算平臺的大規模部署提供了便利。以云計算平臺為基礎設施，支撐基礎業務應用，大數據應用、AI應用等，建立全局的系統和服務體系，可以更好的服務于客戶，更好的贏得客戶的信任。

3.企業業面臨的問題和挑戰--現狀分析

互聯網金融的出現和迅速發展，給予傳統金融企業極大的壓力，被迫考慮轉型和調整。互聯網金融，關鍵點在于互聯網：互聯網思維、互聯網技術。先進的思想引進的技術，先進的技術支撐先進的架構，先進的架構提升先進的業務，先進的業務更好的服務客戶、更多的贏得客戶!

對于我們傳統的金融企業，還存在傳統的思維、落后的技術。一項新業務從提出需求到立項、招標、實施、上線，一年半載已經過去了。最最關鍵的是，開發出來的可能已經不是最初的樣子了，似是而非，一線員工不滿意，IT人員覺得委屈，客戶失望流失。這種傳統的IT研發方式已經無法適應新業務發展的要求。

我們提出建設容器云平臺也是基于現實的挑戰：

1) 受廠商影響，開發測試部署交付等環節各不相同，各Team有各異的環境、工具、方法、規范，團隊之間難以實現共享和高效合作。

2) 傳統單體應用各系統獨立，互連互通、共享難，雖有ESB可以實現集成，但對一些需求無法滿足性能、擴展、低延遲、快速上線等要求。

3) 自動化測試、自動化運維程度低;一個系統通常從立項到運維都是由一個人來負責，形成了大大小小上百個系統，占用大量的人力資源。在系統出現異常時定位問題慢，經常受到多個系統的影響，處理起來很慢。

4) 一臺PC一套環境，資源利用率低，而且PC有限;虛擬化后虛擬機OS消耗大量的計算、存儲資源;虛擬機OS實際運維管理成本等同于物理服務器，虛擬機數量增加導致管理成本增加。

5) 不易復制，搭建環境麻煩。生產與測試環境不一致，臟環境的問題，無法保證每次運行的環境完全一致。在測試環境可以，在生產環境可能怎么都不行。

6) 擴容慢，遇到突發流量，疲于奔命;遷移慢且比較繁瑣。

7) 系統重載，應用伸縮周期長，對VM做伸縮，系統負載大，APP的VM環境無法快速復制，無法滿足應用的大規模快速彈性部署需求。

8) 不支持快速迭代，業務上線效率低，不支持在線應用環境申請和配置及切換、頻繁發布、頻繁升級背后的人力投入巨大，缺少在線驗證機制、難以快速定位修復線上問題。出現問題后的解決問題的手段非常有限，且低效;

4.實施容器云項目的原因

為了解決面臨的問題和挑戰，重要的是在快速變化的時代生存下去，要變革，要與時俱進。

首先要改變思想，重視IT技術投入，認識到科學技術是第一生產力。已經不能靠人海戰術來贏得未來。IT系統和平臺是業務的基礎，可以極大的協助人來提高業務處理能力。互聯網、移動業務、物聯網的發展，必須靠強大的基礎設施來支撐，需要強大的互連互通能力、強大的運算分析能力、針對性的服務能力、瞬時的響應能力、舒適的客戶體驗能力等等，這些都需要IT系統和平臺的支撐。

業務建立在平臺之上!沒有好的平臺就難以推出好的業務。傳統單體應用彼此獨立，所采用的技術、開發語言、開發框架各不相同;數據分離，各自有自己的一套數據庫;數據冗余導致浪費，最重要的是數據不一致造成很多問題。數據是一個企業的核心資產，所以企業的重要數據不能輕易放到公有云，需要建設自己的私有云平臺、建設企業內的基礎設施平臺來支撐企業業務的運行和發展。從而實現基礎設施平臺為數據和業務服務;數據層建立通用數據模型，實現全局唯一數據源，解決數據不通、不一致、冗余等問題;業務層實現服務共享，在基礎服務的基礎上快速構建業務應用，快速部署發布投入運營。

SOA技術的發展，微服務被大家接受并受到推崇。其解決了單體應用系統大而重的問題，也很好的避免了ESB集成存在的瓶頸。其采用組件服務化、分布式的部署方式，非常貼合容器技術的特點，小而輕量，以小拼大。

具體的，為了配合正在進行中的客戶中心、賬戶中心、產品中心等的建設，適應公司互聯網業務發展，滿足業務應用快速開發及迭代的需求，采用微服務架構，逐步建立標準化的開發、測試、運維環境，形成適用于公司的DevOps(開發和運維一體化)過程，完善開發、測試、部署、運維監控工具鏈，提升自主開發技術和管理水平。

5.項目可能帶來的好處

實現了共享，適應快速的業務變化，企業能生存、能發展、員工能有高收入，為社會公眾帶來便利和利益：

1) 技術上，初步搭建容器云平臺，建立統一的服務托管、部署、運維平臺，逐步建立并完善統一的權限管理體系、授權認證體系、服務配置治理體系、日志收集分析體系、監控告警預警體系等，實現公司內統一的應用服務部署運維監控生態系統。

2) 管理上，通過引入DevOps理念，根據公司實際逐步建立開發、測試、運維等適合自身發展需要的流程，定義相關數據、業務、技術等標準、規范，實現開發、測試、生產環境的一致性，提升敏捷開發的能力，提升自動化運維的水平。

3) 業務上，提供快速業務原型的開發以支持業務變化需求，讓業務人員更早的介入，熟悉使用并有效持續反饋，形成業務和開發的良性循環。

總的來說，容器輕量化PaaS平臺可以利用容器技術的特點，其技術特點非常適合互聯網化應用的快速迭代開發、彈性伸縮部署、基于標簽體系的灰度發布機制等需求。我們同時考慮采用目前分布式的微服務架構，結合容器云平臺，實現提高開發端的響應能力，自主開發;統一技術路線，逐步實現技術積累和共享;實現持續集成，開發測試與生產環境一致;持續部署能力，提高發布速度;實現彈性伸縮能力，快速的實現擴容和縮容;解放運維、實行自動化運維等以滿足公司互聯網應用業務發展的需要以及傳統應用改造和集成的需求。

6.行業內應用情況現狀調查及趨勢預測--市場調研

目前公司的業務系統開發、測試、部署及運維還以傳統模式為主，開發人員在應用開發測試及部署階段還需要準備操作系統、中間件、Web服務等軟件運行環境并進行配置，業務應用的上線及變更周期較長，不能滿足近幾年興起的互聯網化應用所要求的快速、彈性、敏捷要求，缺少整合、高效的基礎平臺支持。

為此，項目組對行業內容器云的建設情況進行了廣泛調研。

國內銀行采用容器云技術的相對比較多，證券公司目前大多數還在調研和PoC測試階段。也有幾家已應用到生產環境。

某證券從2013年開始研究容器技術，2014年嘗試在生產環境使用，2015年開始大規模使用，根據2017年現場調研情況，某證券在生產環境使用的容器實例個數行情云4000多個容器實例，分布在6個機房。承載實時并發超過30萬，整個行情云每秒的吞吐在1.5Gbps左右,服務客戶超過200萬;

上海證交所也已實施容器云平臺，自身從頂層規劃，多廠商參與，應用采用微服務架構，平臺實現了容器云、持續集成持續部署等，并獲得了2016“開源云計算﹒實效應用”獎。

某證券在測試環境和生產環境部署了超過360個容器實例，應用在用戶中心——某e賬通、任務中心流數據處理、支付中心——某內部支付服務等業務場景。

某證券容器技術主要使用在應用開發持續集成流程方面，實現自己的研發流程平臺，目前在開發測試環境部署有上百容器，20多個項目開發及測試流程。

7.建設目標

容器云的建設目標是建設一個以容器技術為基礎，支持微服務架構應用軟件運行的基礎平臺，以降低應用開發、測試、部署和運維過程中軟件基礎環境的復雜度，使開發人員更關注業務實現，提高開發、測試、運維效率，提升技術對業務需求的相應速度。

容器云的建設以服務應用開發為中心，將業務應用中的功能性需求如高可用、彈性伸縮、灰度發布、監控告警、日志存儲等，通過容器云平臺統一實現，并解決應用全生命周期管理、中間件云服務、基礎資源利用率等問題，從而降低基礎設施的投入，容器云平臺主要對應用開發及運維提供以下支持：

? 開發環境支持：即開發人員使用提容器云平臺供的快速部署能力，建立開發應用所需的技術環境、編程語言框架、中間件服務等，實現開發環境的快速準備。

? 應用部署服務：即開發人員創建的應用可通過鏡像方式快速部署到容器云上，在測試環境和生產環境實現應用快速部署及更新。

? 微服務架構支持：提供微服務應用的應用注冊中心、日志中心、監控中心、容器調度及編排服務，為客戶中心、服務中心等這類按照微服務架構開發的應用提供基礎環境支持。

應用運維支持：應用運維人員無需管理底層硬件資源、操作系統及中間件等，可以按照統一的鏡像方式部署和變更應用，大幅降低應用運維的復雜度，逐步實現應用運維管理(伸縮、配置、升級等)自動化。

我司容器云平臺建設的基本目標是：提供應用托管、應用運維的統一平臺，通過容器云提供的配置中心、注冊發現中心、日志中心、監控告警中心等為所有業務應用提供基礎服務，研發人員專注于業務應用的研發而不用關注應用的部署和運維。基于云計算的多租戶體系和權限管理體系，可以很好的實現應用之間的隔離，提供安全的訪問控制體系。

以建設容器化PaaS平臺為契機，搭建基礎的統一監控、告警、日志、配置、認證、API管理等服務能力，同時結合大數據平臺建設，預研機器學習、深度學習等人工智能應用場景，融合各系統的優點和能力，避免各個系統的獨立建設導致的系統隔離、數據分散、數據冗余、數據不一致等問題，逐步建設形成統一認證中心、監控告警中心、服務注冊中心、服務配置中心、日志管理中心、API網關和API管理等能力。

8.PoC測試情況分析--廠家評估

項目組根據前期調研和國內容器云產品廠商的技術能力和項目實施情況，選取了A、B、C、D、E、F、G七家廠商的產品進行了PoC測試，目前測試已經完成，我們選擇了以下幾個方面作為評估維度：

? 多租戶：考察租戶隔離能力，對組織架構、用戶、權限、角色的支持能力。

? 資源管理：集群、主機、計算、存儲、網絡資源的管理分配能力。

? DevOps：敏捷研發運維的能力。持續集成、持續部署能力。

? 應用管理：包括應用發布(灰度發布)、部署、應用模板、彈性伸縮、應用運維、服務、實例、Pods、容器等管理功能。

? 微服務支持：包括支持的微服務框架、服務編排、服務治理能力等。

? 鏡像倉庫/中間件支持：鏡像倉庫能力和公用中間件支持能力。

? 基礎組件：日志、監控、調度、權限、健康檢查等基礎組件的能力。

? 易用性：操作、理解的便捷程度。主要是考慮客戶使用體驗。包括安裝配置、部署操作、更新升級、高可用等。命名定義是否貼切、操作是否便利、配置是否復雜化、是否符合人的習慣等。

? 廠商情況：背景、技術實力、運維支持、項目經驗等。

根據評估綜合結果來選擇進入招標階段廠商。

9.實施規劃

按照試點先行、分步推進的原則，容器云平臺建設計劃分為兩個階段：

第一階段：容器云基礎平臺建設。部署容器引擎和容器管理調度系統，支持客戶中心、服務中心系統的上線部署，為客戶中心、賬戶中心、產品中心等應用和用到的中間件服務提供托管和運行管理平臺;同步搭建微服務架構支撐體系，建立服務配置中心、服務注冊中心、服務日志處理中心、服務監控告警中心等組件，以更好的支持服務運維要求。基于微服務架構設計的服務可以很好的跟容器云結合，實現服務的彈性伸縮、灰度發布、路由配置、熔斷保護、應用監控等能力。同時嘗試在容器云平臺提供公共的中間件服務，如負載均衡服務、消息中間件服務、Redis緩存集群服務、應用服務器服務等。第一階段預計工期N個月。

第二階段：已有服務開發遷移及DevOps流程實現階段。本階段遷移部分適合容器化部署的部分已有應用如企業服務總線、大數據應用、OTC、產品中心等，使上述業務應用具備彈性伸縮能力以及日志收集、日志分析、監控告警等運維能力;實現開發、測試、生產環境的一致性，完成持續集成、持續發布流程和標準規范，逐步形成適合公司自身的DevOps體系并持續改進，并逐步推廣到其他團隊。預計工期N個月。

二、容器云項目本期工程實施的預期具體應用效果

前面我們提到，容器云項目實施采用試點先行、分步實施的方式，第一階段先建設容器云基礎平臺，并同步支持微服務架構的應用。第二階段實現DevOps持續集成、持續部署、持續反饋閉環流程，完成整個工具鏈選擇和集成，同時遷移已有的服務化應用，以及需要改造的單體應用等。這些工作完成之后，將對企業、IT系統建設、運維和開發人員帶來極大收益。

1.對于企業的價值

容器云是基礎設施平臺，就像我們建樓房的地基，樓房結不結實、抗不抗震，地基是關鍵。對企業來說，建設一套企業應用系統的開發運維基礎設施平臺，將是企業實現敏捷應用開發和快速業務響應的基礎。

傳統單體應用的開發周期基本上都是以半年、年來計算，采用SOA/ESB集成服務化之后，受制于ESB的設計思想，雖然可以提高響應能力，將應用功能解耦合，縮短應用開發周期為月、周甚至天，但性能和低延遲方面常常無法滿足需求。ESB是基于系統的集成，受制于底層各系統的能力，無法自由擴展。微服務架構強調組件從下到上的服務化，對應用系統做徹底的改造，實現應用系統微服務化。容器云平臺為微服務應用提供環境，可以方便的建設企業的服務中臺。這是一個企業的關鍵能力。有了服務中臺，才能真正的實現快速的業務響應能力和應用快速構建部署運營能力。

容器云彈性伸縮能力，讓基礎的、共用的組件可以真正的解耦出來，不再受制于單臺機器資源的限制，可以支撐整個企業的需求。比如日志中心，就可以實現整個公司所有應用系統、應用服務的日志的歸集、分析。容器云多租戶能力有可以很好的滿足不同業務、不同部門或團隊的隔離需求。

有了這些能力，在響應業務需求時，將只專注于業務的實現，不再考慮平臺、存儲、框架等，服務中臺的服務組合和編排可以迅速的實現業務服務，使業務人員能抓住業務時機，及時為客戶提供合適業務服務，留住老客戶，贏得新客戶。

2.對于IT系統的好處

在建設容器云之后，我們關注的將是一個個業務應用，不再是一個個IT系統。所有的業務應用構成一個企業級的IT系統，是一個整體，一個生態系統。公共的服務、公共的組件是共享的，不再有重復的建設。比如日志，傳統單體應用每個系統都需要有日志模塊，導致重復和冗余，也造成很多的不一致和數據隔離，給綜合的長期的業務分析造成麻煩。基于容器云的IT生態系統，只有一套日志組件服務，它可能有很多個日志服務實例，基于分布式部署在容器云平臺。其他組件服務和業務應用服務也是一樣。比如消息服務，為整個企業提供消息的發布、訂閱提供支持，對接不同的渠道，如手機App、微信、短信、網站應用等。任何一個業務應用或者新的業務需求需要用到消息服務，直接就可以通過消息服務API實現快速集成，不用再開發自己的消息服務。這將節省大量的工作量，從而提高響應速度和節約成本。

3.對于運維人員的好處

采用容器云平臺之后，運維人員職責可能劃分為資源運維和應用運維。資源運維人員專注于IT基礎設施資源的運營維護，為應用服務提供計算、存儲、網絡等資源。應用運維人員也可能由應用開發人員兼任，實現業務應用的自動化運維監控。健康檢查、日志、監控、告警、反饋自動化。通過自動化流程和工具來解放運維，幫助快速定位異常、快速反饋、快速的解決問題。

這樣各司其職，資源運維人員不會因為應用的缺陷被抱怨，應用運維人員對自己開發的業務應用熟悉，又可利用自身的技術能力選擇、開發合適的運維工具來支持應用運維。

4.對研發人員的好處

容器云平臺為研發人員提供了持續集成的平臺和一致性的環境，不用再花時間去搭建基礎開發環境、測試環境，可能幾天的準備工作可以在分鐘級內完成。開發人員可以專注于業務應用的開發，不用考慮底層數據的存儲、模型、系統的架構、部署方式等等，只需要考慮如何使用服務中臺的服務來構建業務應用。不但簡化了開發、提高了對業務響應能力，而且標準化、規范化、一致性的接口服務對普通開發人員的能力要求降低，學習成本減少。

三、重大風險揭示與管理

風險總是無處不在。容器云有諸多好處，但采用和實施容器云也存在不少風險。容器技術是新興開源技術，發展變化快，首先存在技術風險。發展變化快意味著很多人可能跟不上技術的變化，技能和經驗不足，缺乏深入的認知。這是人力風險。對于新的開源技術，企業往往認識和投入不足，缺乏好的實踐案例，從技術成熟到真正落地，往往需要一到幾年的時間。

1. 技術風險

容器技術出現也就短短幾年時間，仍在不斷的發展變化。開源的技術容易凝聚大家的智慧，但同時也由于考慮問題的角度不同，也造成開源技術的大雜燴，為技術選型帶來紛擾。

去年我們考慮采用容器技術并開始選型時，面臨著Mesos、Docker Swarm、Kubernetes等容器調度管理框架的選擇。但等我們完成PoC測試、Mesos和Docker Swarm已經沒落，國內所有的容器廠商都轉向Kubernetes。快速的技術變化，為項目的選型和建設帶來一些問題。錯誤的選型可能為后期的運維帶來難題。

容器技術是開源技術，開源社區和商業企業關注點不同，社區開源版本相對于商業企業版本往往缺乏強力的支持。

容器云技術又涉及眾多的組件，眾多的技術，不僅僅是Docker + Kubernetes，網絡、存儲、日志、監控、安全、微服務等等，要想一下子全部掌握很難，存在技術風險。

2. 人力風險

容器云是一個基礎設施平臺，需要相應的基礎組件服務支撐才能真正的實現輕量化PaaS，如果僅僅是Docker + Kubernetes，其不足以支撐企業的業務應用開發和運維等需求。但目前國內整個一個容器云市場的認識還大多停留在Docker + Kubernetes，甚至把Kubernetes等同于容器云。認知和技術的不成熟可能是容器云建設失敗的主要原因。

人員技能和經驗不足，使容器云項目實施存在諸多變量。大部分人都是一知半解，缺少實踐經驗。在實際的項目中，如果沒有一個在過往經驗上、技術上和管理上掌控全局的人員，容器云項目是不會成功的。

IT項目上，人是大的不可控因素。項目人員的技能是否匹配、主觀能動性能否發揮、責任心是否具備、人員的流動、對項目的理解、認知、把控是否到位等等都影響著項目的質量。

3. 資金投入不足風險

目前大部分企業對新技術存在懷疑，投入與支持不足。很多企業都是在做PoC測試驗證，或者實施一個小項目做個試點。這限制了容器云基礎設施平臺的完整搭建，也無法真正體現出容器云平臺的優勢。只有在有一定規模的基礎上，實現了或者部分實現了服務中臺的能力，才能真正表現出其價值和能力。

4. 如何避免這些風險

為避免上述風險，我司建議采用購買或者合作研發容器云產品的方式來實施容器云項目。我們可以提供產品研發的詳細需求、使用場景、架構設計和詳細設計，支持容器云廠商基于這些需求、場景、設計來實現，如果最終產品滿足要求則進入招標候選廠商。這樣對容器云廠商來說是一個完善產品，同行的機會，對我司來說，可以避免一定的風險和節省成本。

1) 產品要求

我們要求廠商提供的產品能基本滿足我們的需求，對于不滿足的部分在后期必須實現并交付使用。對于我們在使用過程中可能需要做一些定制化更改需求，可以友好協商，支付一定的額外報酬，后續分期完善。對產品的缺陷，要及時修正，不能影響到我們業務的正常運行。對于超出能力不能及時修復的缺陷，要找到相應的解決辦法。另外要求產品各組件之間是松耦合的架構，方便更新替換。

2) 產品安裝、部署、升級、遷移

容器技術屬于新興技術，雖然已經逐步成熟，但仍在迅速發展變化之中，各種組件不斷的涌現，所以我們要求產品必須能支持不同系統平臺之上的安裝、部署，支持物理機、虛擬機等系統;容器云容器引擎及容器管理調度系統能夠及時的提供無縫升級、遷移能力;提供升級、遷移預案，識別潛在風險并能規避這些風險。

3) 后期需求及新特性開發，定制開發

產品不可能滿足我們所有需求，因此在我們使用一段時候后會根據各團隊使用情況的反饋意見提出新的修改及新特性的需求。對于非缺陷性的新功能需求，我們可以基于協商的基礎上支付一定的合理的研發費用。

4) 技術支持

產品使用初期可能需要提供現場服務支持，后期可提供遠程服務支持。在產品使用過程中如果有重大缺陷引起的重大事故，廠商必須安排技術人員在2小時內達到現場解決問題。并需要在24小時內修復缺陷，完成部署。

5) 高可用要求

對于產品的關鍵組件實現高可用部署，同時提供潛在風險點的備份機制。

支持平臺控制節點高可用;

支持應用服務高可用部署;

支持鏡像倉庫高可用;

支持負載均衡高可用;

平臺控制節點宕機不能影響容器中服務的正常運行

四、預算評估

本項目預算XX萬元，用于購置服務器硬件、容器云軟件產品授權及實施服務，詳見下表：

如前所述，我們建議選擇相對成熟的產品，避免項目形式交付，人是大的變量，大的不可控因素，所以盡可能減少人的變量，減小風險，從而使成本可控。

經過2次詢價和多次溝通交流，容器云產品軟件一套約XX萬元，另外按節點數量產生授權使用費用，每節點約XX萬元，根據節點數的量提供一定的折扣比例。容器云產品部署、配置、測試、調試等實施費用約XX萬元。服務器硬件根據應用部署需求確定，目前需要X臺PC服務器，XXXG內存和XX顆Xeon 6150 CPU，以及硬盤、網卡等(如上表)。容器云廠商后期服務費首年免費，后期約按項目總額的10%-20%收取。經過總的測算，以目前的需求，實施容器云項目總預算包含軟硬件、實施和3年維保服務大概在XX萬。不同的廠商價格會有差別。

五、關鍵技術路線選型

在規劃容器云項目的時候面對多個技術路線選擇，首先是容器引擎技術，容器編排調度技術、微服務框架等。

1. 容器引擎

容器引擎技術主要有Docker公司的docker引擎和CentOs的rkt引擎，rkt理論上在安全性和兼容性方面更好，但缺乏生產實踐，目前用戶大部分使用Docker。Docker社區也更活躍，這可能跟Docker發布比較早和參與的人更多有關。目前大部分容器廠商都選Docker支持，rkt的成熟度仍顯不足，因此容器引擎我們選擇Docker引擎。

2. 容器編排調度框架

容器編排調度框架主要有Mesos、Docker Swarm、Kubernetes、Openshift等。

Docker Swarm簡單易用。原生支持Docker，安裝Docker后開啟Swarm模式即可使用。比較適合小型的集群管理。

Kubernetes除支持主流Docker容器(需單獨安裝Docker組件)以外也支持CoreOS rkt等容器技術，目前社區最活躍，受廠商支持也最多，基本上所有的容器云廠商都已轉向支持Kubernetes。

Mesos上無需安裝docker程序也可以運行docker容器，mesos可以自己解析docker鏡像來啟動容器。Mesos應該來說更成熟，Kubernetes已經測試了數千個節點，而Mesos已經測試了成千上萬的節點。Mesos社區不再活躍，對超大集群的支持Mesos更合適。

Openshift是Redhat基于Docker和Kubernetes之上做了封裝的開源容器應用平臺。RedHat增加了很多新的特性以支持應用的快速開發、部署、擴展等生命周期管理能力。Openshift的實施一般是由RedHat合作伙伴執行。合作伙伴的能力決定著項目的質量。

考慮到技術的快速變化，為了后期升級維護的需要，適合選擇社區活躍、支持度高的容器編排調度框架，綜合考慮，Kubernetes或者Openshift是目前比較好的選擇。

3. 微服務框架

目前比較流行的微服務框架是SpringCloud和Dubbo。SpringCloud是Pivotal公司基于SpringBoot框架的基礎上推出的微服務開發開源框架，它提供相對完善的服務配置、注冊發現、服務網關、服務消息總線、熔斷、日志收集等能力。Dubbo是阿里公司的開源產品，相對簡單，國內用的較多，但中斷了一段時間維護，缺乏Pivotal公司系統的支持能力。阿里的產品總的來說是阿里自身需求的結果，所以往往缺乏標準化規范化的考慮，只是為了追求某方面的性能。綜合來看，選擇SpringCloud來開發微服務是比較好的選擇。

六、可行性評估結果及建議

基于以上的分析評估，我們建議可以盡快采用容器云技術實施容器云。以盡快搭建公司私有容器云基礎設施平臺，建設持續集成、持續部署、持續反饋的閉環應用研發流程。提升公司自主研發能力，提高對業務需求的響應能力。采用購買產品的方式來建設公司容器云平臺，避免項目周期長帶來的技術風險和人力風險。

分享題目：容器云平臺如何進行風險管理和關鍵技術路線選型？
文章位置：http://m.newbst.com/news19/201469.html

成都網站建設公司_創新互聯，為您提供做網站、外貿建站、網站排名、商城網站、App設計、手機網站建設

廣告

聲明：本網站發布的內容（圖片、視頻和文字）以用戶投稿、用戶轉載內容為主，如果涉及侵權請盡快告知，我們將會在第一時間刪除。文章觀點不代表本網站立場，如需處理請聯系客服。電話：028-86922220；郵箱：631063699@qq.com。內容未經允許不得轉載，或轉載時需注明來源： 創新互聯