梅峰谷大數據資料整理小組云計算之PaaS經典案例匯總-中篇版本號V1.0日期2017-10-15來源梅峰谷大數據本文檔版權由梅峰谷大數據所有。未經書面許可，任何單位和個人不得以任何形式摘抄、復制本文檔的部分或全部，并以任何形式傳播。梅峰谷大數據資料整理小組2017年10月目錄TOC\o"1-3"\h\u15545梅峰谷大數據資料整理小組 127148目錄 23105第一章中國移動網狀網PaaS之路 9251911.建設說明 9148431.1建設背景 9133711.2.試點系統選擇 11209812.PaaS技術選型 12258692.1.Kubernetes 12291552.2.Mesos 1361982.3.產品對比 1384903.PAAS平臺解決方案 15110593.1.技術架構 1552113.2.功能框架 1685243.3技術方案亮點 16180894.PAAS應用效果 22168184.1.集群規模 22246174.2.應用效果 2290235.下一步計劃 2322268第二章中國公有云計算產品線 24316101.愿景 24273432.洞察 25293352.1產品競爭 25218462.2運營競爭 2532032.3客戶競爭 2681113.云商 26305243.1阿里云 27194113.2騰訊云 28207433.3百度開放云 30149633.4華為云 31197803.5網易云 33145923.6新浪云 3453593.7樂視云 35165563.8360云 36266343.9京東云 37303663.10美團云 39285553.11金山云 4016057第三章中聯通CU-DC/OS 41275201.研究背景 41321632.CU-DCOS發展 4219253.CU-DCOS技術創新 43194353.1創新的獨立式技術架構 43122303.2資源的統一管理 44111383.3創新的大數據服務 44212723.4持續集成/持續交付能力 4466313.5統一服務網關 4489553.6多實例持久化存儲 45278204.落地應用 45103654.1公共創新大數據能力開放平臺 4549394.2聯通PaaS平臺的基礎架構 45320834.3聯通牛人部落實驗室的基礎架構 4528759第四章開源PaaS初探 46129661PaaS平臺概述 46198602.主流的開源PaaS平臺 47315932.1CloudFoundry 47188142.2Cloudify 4877272.3Docker 49210552.4小結 5048233開源PaaS發展趨勢 5184893.1輕量化 5147543.2服務外化 518143.3大數據分析 51217654.結束語 5324046第五章傳統企業PaaS上云思考（薦） 53193541.背景說明 5377582.傳統架構與應用分類 54297582.1經典架構 54257842.2OLAP與OLTP 55263943.云化需求與分析 5693353.1OLTP類應用云化的要求 5679453.2OLAP型應用云化的需求 58222154.基于容器的PaaS平臺架構構建 61150705.PaaS平臺問題及上云注意點 64101315.1資源調度問題 6496545.2多租戶的問題 64289206.問答環節 6818146第六章Pivotal云原生應用和PaaS 69174111.Pivotal的探索 6977351.1pivotal介紹 70287431.2pivotal大牛 7160822.云原生架構與應用 73187502.1云原生架構 73312812.2云原生應用特征 7480823.PaaS的業務驅動力

75116344.PaaS的架構模型與業務價值

76219475.微服務監控鏈—SpringZipkin 7817235第七章基于k8s的PaaS平臺設計和思考 80293441.PaaS平臺的意義 80148952.為什么選擇Kubernetes 81271542.1主流容器框架 81291592.2容器設計理念 82210893.PaaS平臺上的微服務架構應用 82198934.PaaS平臺架構設計 83141744.1平臺建設原則 8345184.2平臺關鍵能力說明 84323754.3PaaS平臺功能組件 8516563第八章容器驅動的PaaS平臺實現（薦） 86114931.基于容器的PaaS是趨勢 87104492.企業選擇PaaS的關注點 88102302.1某世界500強保險集團 89298202.2某全國性股份制商業銀行 8922992.3某通訊解決方案提供商 9055012.4某省科技廳醫療大數據項目 90106003.PaaS平臺選型要素 91151034.CaaS構建：引擎還是汽車 92289635.容器服務CaaS框架示例 93218076.企業對容器訴求 95216.1對網絡訴求 95314816.2對存儲訴求 96218807.PaaS應用舉例 99273047.1基于Weblogic應用 99272657.2基于Mysql高可用數據服務 101257058.容器的日志和告警 10290359.容器的安全問題 10422018第九章YY互娛私有PaaS平臺實踐 105205331.運維價值體系 106187572.運維平臺化方式 10728302.1面向流程 107212442.2面向服務 108222102.3.拿來主義 109282673.YY互娛PaaS運維平臺實踐 110239203.1業務場景 110208833.2平臺理念 112184363.3實踐歷程 113268424.YY互娛PaaS運維平臺未來規化 13217354第十章PaaS關鍵技術點和難點 133237621.PaaS建設的意義何在 134116842.PaaS的主要技術有哪些 135233303.容器云的負載均衡如何選擇 135224584.PaaS的日志和監控如何進行處理 136255785.PaaS如何更好的實現CI/CD 136178886.PaaS鍵技術點和難點 13710009第十一章唯品會輕量級PaaS平臺 138240771.唯品會現狀 13965332.唯品會PaaS構建流程 139137113.唯品會PaaS功能點 143265764.PaaS網絡方案和定制 144104675.日志收集和監控 147238966.唯品會PaaS監控 14970077.問題總結 15018373第十二章運營商上PaaS遇到的問題 151255911.運營商IT系統現狀 152267222.IT系統集中一體化問題 15218823.硬件資源整合 153222023.1IaaS層面的硬件資源整合 15443343.2PaaS層面的硬件資源整合 15486494.關系型數據庫擴展性問題 155183105.構建跨域的PaaS平臺 161187716.能力開放 162140937.總結語 16428655第十三章新浪微博基于Docker的混合云架構 164278511.背景，挑戰與實現 164139872.混合云架構方案 166130592.112306混合云架構 16678332.2混合云DCP技術架構 167118802.3混合云功能模塊 169269393.基礎設施 16951674.彈性調度 173293085.編排與實現 17696796.春晚實戰&總結 181第一章中國移動網狀網PaaS之路1.建設說明中國移動一級業務支撐系統作為中國移動的管理中心和全網業務的核心系統，有內容計費、網狀網、BBOSS、統一電渠、一級營銷、一級客服等系統，業務模式涵蓋了交易、計費、服務等各種移動核心業務模式，系統功能各異復雜度高。1.1建設背景這些系統都是做為獨立項目單獨建設的。然而，近幾年隨著大數據、云計算、容器化、微服務、平臺戰略等新技術和新概念的層出不窮和快速發展，在業務支撐、架構能力、平臺擴展性等方面對舊有的煙囪式建設的業務支撐系統提出了巨大的挑戰。企業在IT平臺的建設、開發和維護的過程中，經常會被以下問題所困擾：開發環境管理復雜，開發、測試、生產環境無法進行有效隔離，無法實現自動化的安裝部署和應用維護，業務的環境和配置依賴問題常常會給系統遷移帶來很大的麻煩；X86化加大了系統的運維壓力，日常升級部署工作繁雜巨大，開發/測試/運維人員之間相互抱怨。特別是隨著移動X86化推進，資源數量急速膨脹。怎樣實現資源集中有效管理，資源動態靈活調配，提高對資源的可監控可管理能力對現有系統構架提出了挑戰。另一方面，隨著移動融合業務發展，尤其是互聯網業務的發展，對系統水平彈性動態擴展、業務連續性保障、故障迅速恢復提出高要求。因此，企業迫切需要引入新的技術和管理方式來應對云計算時代所帶來的變革，舊有的平臺技術架構亟待升級，開發管理流程亟待優化。做為一級業務支撐中心，怎么實現所有系統的統一資源分配和調度，怎么實現原有煙囪系統的資源共享，怎么實現開發/測試/生產部署的有效分離，怎么實現整個X86集群的統一監控是支撐中心亟待解決的問題。針對以上問題，中國移動業務支撐系統部業務支撐中心（以下簡稱業務支撐中心）在2015年開始了PAAS平臺的摸索，希望通過試點積累PAAS平臺的建設和運維經驗，為未來建設一級系統PAAS平臺打下基礎。1.2試點系統選擇

中國移動一級業務支撐系統做為中國移動的管理中心和全網業務的核心系統，有內容計費，網狀網，BBOSS，統一電渠，一級營銷，一級客服等系統，業務模式涵蓋了交易、計費、服務等各種移動核心業務模式，系統功能各異復雜度高。這些系統都是做為獨立項目單獨建設的。然而，近幾年隨著大數據、云計算、容器化、微服務、平臺戰略等新技術和新概念的層出不窮和快速發展，在業務支撐、架構能力、平臺擴展性等方面對舊有的煙囪式建設的業務支撐系統提出了巨大的挑戰。企業在IT平臺的建設、開發和維護的過程中，經常會被以下問題所困擾：開發環境管理復雜，開發、測試、生產環境無法進行有效隔離，無法實現自動化的安裝部署和應用維護，業務的環境和配置依賴問題常常會給系統遷移帶來很大的麻煩；X86化加大了系統的運維壓力，日常升級部署工作繁雜巨大，開發/測試/運維人員之間相互抱怨。特別是隨著移動X86化推進，資源數量急速膨脹。怎樣實現資源集中有效管理，資源動態靈活調配，提高對資源的可監控可管理能力對現有系統構架提出了挑戰。另一方面，隨著移動融合業務發展，尤其是互聯網業務的發展，對系統水平彈性動態擴展、業務連續性保障、故障迅速恢復提出高要求。因此，企業迫切需要引入新的技術和管理方式來應對云計算時代所帶來的變革，舊有的平臺技術架構亟待升級，開發管理流程亟待優化。做為一級業務支撐中心，怎么實現所有系統的統一資源分配和調度，怎么實現原有煙囪系統的資源共享，怎么實現開發/測試/生產部署的有效分離，怎么實現整個X86集群的統一監控是支撐中心亟待解決的問題。針對以上問題，中國移動業務支撐系統部業務支撐中心（以下簡稱業務支撐中心）在2015年開始了PAAS平臺的摸索，希望通過試點積累PAAS平臺的建設和運維經驗，為未來建設一級系統PAAS平臺打下基礎。1.2.試點系統選擇網狀網做為整個一級業務支撐系統的核心系統，是中國移動內外部信息傳輸交換、服務管控、數據處理、業務支撐、運營開放為一體的綜合信息交換樞紐，是連接中國移動集團、31個省公司、各一級業務平臺、服務公司、合作伙伴等內外部各應用系統，并對外提供服務的橋梁，是中國移動的企業數字神經網絡。目前承載200多個平臺的接入，支撐業務達到2000多個，包含金融，客服，業務訂購，互聯網等各類的業務。峰值業務量目前達到10億筆/每天，每月結算金額在60多億。系統承載業務具有容量大，實時性強，波動劇烈，增長迅速，重要性強，客戶影響大，無狀態業務居多等特點。非常適合做PAAS平臺的試點。業務支撐中心和網狀網項目技術團隊經過大量的研討，創新的提出了APU（ApplicationProcessUnit）的概念，把資源和應用有效的結合在一起，解決未來的系統的發展和管理瓶頸，并申請了專利。而且通過深入的技術研究和實踐探索，在Docker基礎上通過增強接口和管理功能，實現了APU概念的落地。結合Kunbernet做為集群管理平臺，搭建了能夠承載網狀網系統的PAAS平臺試點。實現了整個平臺的容器化改造和集群的部署，管理和監控。2015年3月，搭建群，選Kubernetes+Docker集取部分業務進行POC。2015年5月，開始逐步大規模進行業務的開發改造。2015年7月，基于Kubernetes+Docker的網狀網PAAS平臺上線，第一步遷移了移動商城業務。2015年9月，建立生產+容災兩個集群，共120個節點，遷移60%的業務。2015年12月，開始逐步遷移全部的業務到PAAS.PaaS技術選型目前適用于容器集群管理和大規模部署的，并且得到大規模生產驗證的開源產品有：Kubernetes、ApacheMesos。這兩個平臺各有特點：2.1.Kubernetes2015年，谷歌公布多年以來的容器集群方面的秘密：Google早些年構建了一個管理系統，它可以用來管理集群、容器、網絡以及命名系統。第一個版本被稱為Brog，后續版本稱為Omega。目前每秒會啟動大約7000個容器，每周可能會超過20億個容器。利用在容器技術上的實踐經驗和技術積累，Google構建了Kubernetes(簡寫K8s)。Kubernetes是一個全新的基于容器技術的分布式架構的集群管理解決方案，Kubernetes具有完備的集群管理能力，包括多層次的安全防護和準入機制、多租戶應用支撐能力、透明的服務注冊和服務發現機制、內建智能負載均衡器、強大的故障發現和自我修復能力、服務滾動升級和在線擴容能力、可擴展的資源自動調度機制，以及多粒度的資源配額管理能力。有了Kubernetes，你可以告訴系統，你的應用程序需要一個數據庫、三個服務器、X量的存儲等等。Kubernetes主要關注的是對服務級別的控制而并非僅僅對容器級別的控制，Kubernetes提供了一種“機智”的管理方式，它將服務看成一個整體。在Kubernetes的解決方案中，一個服務甚至可以自我擴展，自我診斷，并且容易升級。在Kubernetes的設計理念中，第一次將Service的高度提升到超過Machine，第一次將服務自動化提升到平臺高度（監控、部署、擴容）。目前Kubernetes生態環境熱度很高，發展很快。2.2.MesosMesos最早由美國加州大學伯克利分校AMPLab實驗室開發，Mesos是分布式系統內核，它可以將不同的機器整合在一個邏輯計算機上面。當你擁有很多的物理資源并想構建一個巨大的靜態的計算集群的時候，Mesos就派上用場了。有很多的現代化可擴展性的數據處理應用都可以在Mesos上運行，包括Hadoop、Kafka、Spark等，同時你可以通過容器技術將所有的數據處理應都運行在一個基礎的資源池中。如果你擁有已經存在的多個工作任務（Hadoop、Spark、Kafka等），那Mesos提供了一個將不同工作任務相互交錯的框架。Mesos目前做為DCOS（DataCenterOperationSystem）理念的實現者，也得到了很多企業的關注。但是Mesos如果做為容器集群的管理者，需要通過Marathon框架支撐，另外還需要另外增加很多Kubernetes內置的一些功能，如proxy，serviceDNS，以及集群的動態伸縮要求的和proxy負載策略的數據同步，應用的監控等等。因為，如果企業只是想實現容器集群實現PAAS平臺搭建的話，Mesos過于復雜，但是如果企業想實現DCOS平臺的話，Mesos是個不錯的選擇。另外，一個針對Mesos+kubernetes的框架正在開發中，來替換Marathon，提供最理想的方式以構建基于微服務架構的應用程序實現對容器集群的更有效的管理。總的趨勢是兩者不斷的借鑒和融合。2.3.產品對比相關技術在核心特點、量級、復雜性、穩定性、擴展性，二次開發工作量等方面的比較如下表所示：

KubernetesApacheMesos定位專注于容器Docker的集群管理以service的角度定義容器的應用，產生微服務整個框架考慮了很多生產中需要的功能，比如proxy，serviceDNS，livenessProbe等，基本不用二次開發就能應用到生產Mesos是一個分布式系統內核，編織不同類型的主機放在一起當一臺邏輯計算電腦。它專注資源的管理和任務調度，并不是針對容器管理的。Mesos上所有的應用部署都需要有專門的框架支撐，如支撐Docker必須安裝Marathon。安裝spark和hadoop都需要不同的框架。對容器支撐天生就是針對的容器，和應用的云化，通過微服務的理念對容器的進行服務化包裝支撐Docker必須安裝Marathon框架。Mesos只關注應用層資源的管理。其余由框架完成。對資源的控制Kubernets本身具備資源管控能力，可以控制容器對資源的調用Mesos對所有的主機虛擬成一個大的CPU，內存池，可以定義資源分配，也可以動態調配是否可以分區Kubernetes能通過namespace和node進行集群分區，能控制到主機，CPU和內存可以，可以定義到cpu，內存，磁盤等開發成本原生集成了serviceproxy，serviceDNS，集群動態擴展對proxy的實時更新?；緵]有二次開發成本。而且便于多集群的集成要實現生產應用需要增加很多功能，如HAPROXY，SERVICEDNS等，需要自己實現集群擴展和proxy的集成，二次開發成本高。需要專業的實施團隊非docker應用的集成對于不能實現docker化的應用，通過外部service方式集成進集群必須自行開發framework來集成到mesos里面通過對以上技術體系的研究和評估，我們認為如果企業只是搭建基于容器的PAAS平臺的話，Kubernetes是比較好的選擇,如果是要搭建數據中心DCOS的話Mesos+Kubernetes是最優的選擇。在技術選型中我們最終選擇以Kubernetes+Docker為基礎的搭建PAAS平臺方案。其優點是已經過Google十多年的生產驗證，成熟度高，支持裸機、VM等混合部署，適合多種應用場景，Kubernetes可以用最快的、最簡單的、最輕量級的方式來解決目前存在的問題，并幫助進行面向集群的開發。而且很多廠商已經開始支持Kubernetes，例如微軟、IBM、RedHat、CoreOS、MesoSphere、VMWare等。社區的熱度很高，功能也在快速的增強中。在PAAS平臺穩定之后，逐步開始考慮一級業務支撐系統的DCOS平臺的建設，整合Mesos和Kubernetes，構建一個穩定性強，支持復雜業務場景，強大彈性擴展能力的電信行業DCOS+Paas平臺，為未來的業務快速發展打下堅實的基礎。PAAS平臺解決方案本方案規劃以網狀網為先行實踐范例，盡可能考慮其通用性和普適性，根據業務特點，對業務類型和架構模型進行抽象，歸類出典型的應用場景和架構模型進行方案設計，為其他系統的快速遷移提供參考和最佳實踐。PAAS平臺建議架構視圖如下圖所示：3.1.技術架構承載網狀網系統的PAAS平臺總體技術架構如下：Ku8Manager可視化管理平臺負責安裝，部署，監控，運維，分析。Kubernetes集群由兩類節點組成，Master和Node。Master上運行etcd、APIServer、ControllerManager和Scheduler四個組件，后三個組件構成了Kubernetes的總控中心，負責對集群中所有資源進行管控和調度。Node上運行Kubelet、Proxy和DockerDaemon三個組件，負責對本節點上的Pod的生命周期進行管理。3.2.功能框架以開源技術Docker、Kubernetes為核心引擎，在其基礎上自主開發了Ku8Manager可視化管理控制臺，Ku8Manager可視化管理平臺提供簡便的一鍵式自動化安裝、部署配置、基于容器、應用、服務、資源等不同視角的綜合監控、系統管理和安全管理。PAAS的功能框架如下圖所示：3.3技術方案亮點針對電信行業的特點，我們對Kubernetes做了很多的功能改造和增強，以適用于大規模的生產部署和管理。1）高可用多數據中心之間的服務動態擴展場景一：多集群的統一服務部署：由Kubernetes管理平臺自動化部署模塊統一對各數據中心進行服務自動化安裝部署?？梢远x同一個服務在不同數據中心的Kubernetes集群統一部署，并且可以定義在每個cluster部署服務的容器實例的比例。比如按6:4的比例在clusterA和ClusterB上部署服務。場景二：灰度升級：由Kubernetes管理平臺自動化部署模塊統一對各數據中心自動化進行服務升級?？梢詫崿F先在一部分集群部署新版本，穩定之后再平滑升級全部的節點。場景三：動態集群間業務調整：業務高峰期當一個數據中心容量不足時，由Kubernetes管理平臺自動進行服務動態擴展，啟動容災數據中心的部分服務來支撐業務。場景四：業務高可用：當主數據中心發生故障（如網絡故障）時，由Kubernetes管理平臺自動進行容災切換，由容災數據中心自動接管所有業務服務。實現高可用的數據中心。2）集群的Master節點高可用缺省的Kubernetes集群只有一個master節點，當Master節點崩潰的時候將會造成整個集群無法管理，因此在生產中我們實現了三節點的高可用master集群，保證了整個集群的高可用：3）網絡方案的改造標準Kubernetes+Docker的組網方案是通過軟負載均衡+flannel。該類型方案會帶來30%以上的網絡性能損耗，在高吞吐量的應用中不可接受。因此對標準方案做了如下的改造提升系統性能：增加硬負載均衡器，替代service，提升負載均衡能力和穩定性。實現集群節點狀態變化實時與負載均衡器同步，保證集群擴張和節點狀態變化實時反應到負載均衡器的策略上。采用直接路由降低跨node間的pod訪問網絡損耗。跳過IptablesNAT轉發提升網絡傳輸效率。4）先進的DockerIMAGE全生命周期管理對DockerIMAGE進行統一管理，提供DockerIMAGE的參考模型和流程指導，DockerIMAGE模板規劃、設計、生成及Pod生成的管理流程如下圖所示：5）先進的持續集成和灰度發布全過程管理持續集成可以讓團隊在持續集成的基礎上收到反饋并加以改進，不必等到開發的后期才尋找和修復缺陷。通過持續集成工具Jenkins，持續、自動地構建/測試軟件項目，監控定時執行的任務。實現持續集成和灰度發布的全過程管理，核心工作流程如下：6）Ku8Manager可視化管理平臺提供一鍵式自動化安裝、部署和配置功能集群自動化安裝主界面如下圖所示，可以幾分鐘完成幾十臺機器的集群安裝：7）應用視角的服務部署發布在Kubernetes集群中，以Service、Pod、容器的分級視圖進行綜合管理。新Node加入非常簡單，通過相應的參數調整，即可在秒級實現容量的動態調整，如下圖所示：8）基于基于服務的的立體化綜合監控傳統的網管系統，因為一臺機器上部署很多應用和實例，所以很難把資源的占用和業務有效匹配起來。但是實現容器化改造之后，每個業務的容器占用的資源能一目了然的看出來，有效的解決了對業務-》資源占用的有效監控。分兩種視圖：1）主機視圖：從設備的角度，查看總體上主機CPU、內存的占用情況，保證每臺主機是可用的：2）服務視圖：從業務的角度，查看每個業務的Docker容器對CPU、內存關鍵性能指標，從而能很輕松的看出每個業務對總體資源的占用情況。監控指標如下圖所示：(點擊放大圖像)4.PAAS應用效果4.1.集群規模中國移動一級業務支撐系統PAAS平臺所承載的網狀網系統應用集群包括移動總部和31省公司，網狀網四期之后由1200臺X86服務器組成的多個集群，分布在全國。中國移動網狀網應用集群架構如下圖所示：4.2.應用效果采用Kubernetes+Docker承載網狀網的PAAS平臺，在2015年底的業務高峰中有力支持中國移動統一認證平臺及移動商城等電子渠道業務，同時支撐1億多活躍用戶，交易額日均達10億人民幣，且系統運行穩定。實現業務的灰度發布管理，如：為移動商城平臺應用建立兩個集群組ummp1和ummp2，兩個組的業務中斷互不影響，當集群組ummp1業務升級時，由ummp2支撐業務；Ummp1完成業務升級后轉為生產支撐業務，再對ummp2進行業務升級。通過輪換的迭代發布，實現快速的灰度發布和應用上線，實現系統上線業務不中斷。通過該PAAS平臺，極大提高了大規模應用快速部署的靈活性和系統快捷的水平擴展能力。如針對2015年12月1日業務高峰的劇烈波動，實現了對移動商城和統一支付業務節點的動態負載均衡和容器的彈性伸縮，在秒級快速增加了50個容器實例支撐峰值業務量，很好地支撐了業務的波動。同時通過PAAS平臺也可構建高可用多數據中心，并實現服務的動態擴展，業務高峰期當主數據中心容量不足或發生故障時，由Ku8Manager可視化管理平臺自動進行服務動態擴展和自動進行容災切換，實現高可用的數據中心。通過采用Kubernetes+Docker的PAAS平臺，實現了開發、測試、生產環境的有效隔離和應用的一次構建、隨處運行，有效提升了開發和運維管理的效率。通過采用相應的持續集成工具，在開發過程中實現持續/自動地構建項目，自動化測試軟件代碼，并監控定時執行的任務，實現了持續集成的全過程管理。5.下一步計劃繼續優化承載網狀網系統的PAAS平臺，擴展規模，滿足2016年業務50億筆/天的需求。摸索構建統一化的服務組件，如數據庫即服務、中間件即服務、消息服務、流程服務、搜索引擎服務、移動化服務、安全服務等。逐步實現對中國移動總部一級業務支撐系統的資源和服務進行統一的監控和管理。。形成云平臺標準化技術規范，建立一套符合管理思路、適應性強、易于應用、易于推廣的云平臺標準化框架、模型和規范，為一級業務支撐系統的云化奠定技術基礎。推動其他一級業務支撐系統依據上述平臺標準進行系統重構，加強應用系統業務無關性及業務能力化改造，加快業務支撐中心系統由煙囪煙囪型向平臺型轉變。在此基礎上探索Mesos和Kubernetes平臺的集成，為下一步建設一級系統DCOS平臺做好準備。第二章中國公有云計算產品線1.愿景為啥要談愿景？就是要大家放開了想：云計算到底能干嘛。我希望未來的應用是：1、開發基礎在微信上，可以利用微信的ID登錄、通訊錄、群組、掃碼識別、消息推送、社交分享、支付等功能2、原型設計在云上、代碼托管在云上、測試環境在云上3、各種互聯網應用、社交應用、電商應用、物聯設備應用、SaaS應用，全都開放OpenAPI，開發是基于OpenAPI的組合而成4、云計算服務商提供：AB測試、灰度發布、大流量分流5、云計算服務商提供：虛擬主機和應用容器、分布式存儲、分布式數據庫、開源中間件，讓我不用部署、不用擔心版本、不用擔心組件依賴6、云計算服務商提供：安全防護、自動備份/轉移/恢復、監控預警、在線圖形化操作擴容管理、中間件自動補丁升級那我們看看中國的云計算服務商誰更接近這個愿景，誰能把應用開發與測試、應用部署、運維管理與安全防護、大數據分析都一站搞定。這是我今天這篇文章的寫作出發點。我們選擇了中國一線互聯網公司：阿里、騰訊、百度；華為、360；小米、金山、樂視；京東、美團、滴滴；新浪、網易?？纯催@些排頭兵正在做什么、成熟度進展如何。我們看到：小米、滴滴還沒有開展公有開放云服務。注意：1、我并沒有把外國云含入：amazon、google、微軟、IBM、VMWare、Oracle2、我并沒有把老牌中國IT商含入：中國電信、世紀互聯、浪潮、太極...3、我并沒有把新貴含入：如七牛、UCloud、青云...4、我更沒有把創業含入：類OpenStack公司、類Docker公司、類DevOps公司2.洞察2.1產品競爭1、產品線競爭發現阿里云在產品線方面確實處于領頭位置，其他的云都尚有一段差距。不過騰訊云從產品線研發來看追的非?？?。百度云和百度大腦在產品結果層面呈現的不多。2、特色競爭按說：華為偏通信、360偏安全、樂視偏視頻、京東偏零售電商、美團偏服務電商，那我們看看是不是這樣。但發現，他們的云，和他們的主業關系并不密切，算單獨發展。這也意味著，大家是在同一條起跑線，只不過有人跑的比較早而已。華為云在DaaS層面提供了唯一的研發管理云，這個有點特殊，不知道華為是有布局還是能整合什么就整合什么。另外，記得百度也發布了自己的研發管理云，但不是百度開放云事業部搞的。整合自己的原有主干技術優勢，看來每家都是一個壁壘啊。事業部制之間老死不相往來。倒是網易云、樂視云做的比較有調調。網易云發揮自己一貫的小精品優勢，做的克制，但做一個亮眼一個。樂視云是完全從自己長處出發，圍繞視頻這個領域猛打，也算一批黑馬。去年呢，大家一窩蜂扎到大數據產品商。大家今年都扎堆到視頻云產品上了，這就不算特色了。估計下一步，大家都要扎到區塊鏈、人工智能產品。2.2運營競爭1、運維產品線都差不多利用開源軟件搭起來了。下一步就是運維的競爭。我看云廠商普遍在：DevOps、運維監控與管理、安全防護方面還需要比較大的進展。這也是下一步產品夯實的重點。2、運營呼叫中心服務、技術論壇/知識庫、技術支持工程師的建設，發現各家建設也都比較欠缺。中國的云看似已經進展了5年，但其實連運維層戰爭都還沒有打。今年騰訊、百度、網易、華為高調發布會，表明大佬們都才正式進場了。中國云戰爭，其實才剛剛開始。2.3客戶競爭1、市場格局現在云市場天下三分：創業公司長尾、高速成長的互聯網公司/電商公司、傳統大型企業大量O2O公司死亡、SaaS公司回歸私有部署是個暗點。但今年新成立許多視頻公司是熱點，讓大家紛紛開展云視頻產品業務。不少巨頭云廠商扎入大客戶模式：金融、電信、央企、政府?？此茊巫雍艽螅直簧钌罾p繞在業務需求解決方案、多廠商協同配合打單、長周期招標投標講標的泥潭中。2、解決方案意外居然發生在大數據領域。上半年，做通用大數據技術平臺的紛紛再下一層，開始做分析應用，否則客戶買了一套大數據技術平臺也不知道干什么用，這就阻礙了大數據廠商的銷售。但是大家又對行業業務不熟悉，所以大家又都一窩蜂扎到移動App流量行為分析這個領域。雖然巨頭云廠商甚至創業云廠商都在嘗試扎大客戶，但目前仍然沒有一家提供有行業特點的領域解決方案。單獨買云來干什么，這個問題仍然深深困擾著云廠商。就如同買大數據技術平臺干什么，這個問題也同樣深深困然著大數據廠商。而現在的SaaS呢，也在探索著：公有租用（中小/小/小微/創業企業）、專有公有部署（中型及中大企業）、私有部署（大型企業）。這和咱們現在的公有云面臨的策略一樣。需要行業業務專家、SaaS廠商、大數據技術平臺廠商、云廠商、云遷移和云運維服務廠商共同努力才能推開這種三模式。而行業業務專家和行業IT專家，成為推進的關鍵資源要素。3.云商3.1阿里云一、云計算1、基礎云：移動解析HttpDNS、域名服務（域名注冊與備案、云解析、SSL證書管理）2、云服務器：云服務器ECS、容器服務、高性能計算服務器HPC、計算資源彈性伸縮管理3、云存儲：對象存儲OSS、塊存儲、文件存儲、表格存儲、歸檔存儲4、云網絡：內容分發網絡CDN、負載均衡CLB、私有網絡VPC、專線接入高速通道、NAT網關5、視頻云：媒體轉碼、視頻直播、視頻點播二、云運維1、監控：云監控、業務實時監控服務ARMS（RPC調用、數據庫binlog、消息、終端日志、業務定制日志）2、管理：資源編排、訪問控制、操作審計、密鑰管理服務三、安全1、服務器安全：安騎士、安全管家2、應用安全：Web應用防火墻3、APP加固：無4、防DDos攻擊（DDos高防IP）、防刷（無）5、內容安全：綠網6、數據安全：數據加密服務、CA證書服務、數據風控、數據安全險四、DaaS1、開發：移動開發框架Weex、IM框架（悟空）、日志服務、API網關2、中間件服務：企業級分布式應用服務PaaS、消息隊列、云服務總線CSB3、測試：性能測試4、消息推送：郵件推送/短信推送五、大數據1、云數據庫：云數據庫、云數據Redis、云數據庫OceanBase、云數據庫MongoDB、云數據庫Memcache、云數據庫GreenPlum、云數據庫PetaData2、大數據處理套件：E-MapReduce、大數據開發套件、大數據計算服務、分析型數據庫3、大數據應用引擎：開放搜索、推薦引擎4、可視化工具：QuickBI、DataV數據可視化5、分析應用：公眾趨勢分析、郡縣圖治、畫像分析六、人工智能1、自然語言處理：印刷文字識別2、機器學習：機器學習3、圖片識別：無4、人臉識別：人臉識別5、語音識別：智能語音交互6、圖像分析：電商圖像分析、通用圖像分析7、機器翻譯：機器翻譯七、物聯網八、通用企業軟件1、網站建設：官網、商城2、通信：企業郵箱3.2騰訊云一、云計算1、基礎云：移動解析HttpDNS、無線網絡接入（維納斯WNS）、域名服務（域名注冊與備案、云解析、SSL證書管理）2、云服務器：云服務器CVM、黑市物理服務器CPM、計算資源彈性伸縮管理AS3、云存儲：云硬盤CBS、對象存儲服務COS4、云網絡：內容分發網絡CDN、負載均衡CLB、私有網絡VPC、專線接入DC5、視頻云：點播VOD、直播LVB、互動直播ILVB、微視頻MVS二、云運維1、監控：云監控CM、云撥測CAT2、管理：藍鯨平臺BLUEKING三、安全1、主機與網站安全：HS2、應用安全：無3、APP加固：（樂固CR）4、防DDos攻擊（DAYU）、防刷（天御BSP）5、內容安全：無6、數據安全：無四、DaaS1、開發：移動開發工具（TAB）2、中間件服務：消息服務CMQ3、測試：手游兼容性測試MGCT4、消息推送：信鴿XGPush五、大數據1、數據庫：云數據庫CDB、云存儲redis、云數據庫MongoDB、云數據庫Hbase、云緩存Memcached、分布式云數據庫DCDB2、大數據處理套件：TBDS3、大數據應用引擎：結構化數據搜索托管（云搜）4、可視化工具：無5、分析應用：用戶洞察分析、區域人流分析六、人工智能1、自然語言處理：OpenAPI開放語義分析平臺2、機器學習：機智TML3、圖片識別：萬象優圖CI4、人臉識別：優圖FR5、語音識別：無6、圖像分析：無7、機器翻譯：無七、物聯網八、通用企業軟件1、智能機器人客服：微金小云客服ICS2、通信：云通信IM、PSTN多方通話PMC、短信SMS3.3百度開放云一、云計算1、基礎云：移動解析HttpDNS、域名服務（云解析、SSL證書管理）2、云服務器：云服務器BCC、專屬服務器DCC、物理服務器BBC、應用引擎BAE3、云存儲：云硬盤CDS、對象存儲服務BOS4、云網絡：內容分發網絡CDN、負載均衡BLB、私有網絡VPC、專線接入ET5、視頻云：音視頻直播LSS、音視頻點播VOD、音視頻轉碼MCT二、云運維1、監控：云監控BCM2、管理：無三、安全1、主機安全：云安全BSS2、網站安全：無3、App加固：無4、防刷、防DDos：無5、內容安全：無6、數據安全：無四、DaaS1、開發：百度云API市場2、中間件服務：消息服務Kafka、規則引擎RuleEngine3、測試：應用性能管理服務APM、移動App測試服務4、消息推送：簡單消息服務SMS、簡單郵件服務SES五、大數據1、云數據庫：時序數據庫TSDB2、大數據處理套件：百度MapReduce、百度OLAP引擎Palo、百度批量計算3、大數據應用引擎：百度ElasticSearch、百度日志服務BLS、百度結構化數據即席查詢BigSQL4、可視化工具：無5、分析應用：六、人工智能1、自然語言處理：文字識別OCR2、機器學習：百度機器學習BML、百度深度學習Paddle3、圖片識別：無4、人臉識別：人臉識別BFR5、語音識別：無6、圖像分析：無7、機器翻譯：無七、物聯網1、物聯管理：物聯接入IoTHub、解析（IoTParser）、管理（IoTDevice）八、通用企業軟件1、文檔瀏覽展示服務2、問卷調研服務3.4華為云一、云計算1、基礎云：無2、云主機：彈性云服務器、云容器引擎、裸金屬服務器、彈性伸縮服務、鏡像服務、專屬云3、云存儲：云硬盤、云硬盤備份、對象存儲服務、數據快遞服務、數據傳輸加速、彈性文件服務4、云網絡：彈性負載均衡、云專線、VPN5、視頻云：無二、云運維1、云監控：云監控服務2、云管理：統一身份認證服務、云審計服務、密鑰管理服務、安全指數服務三、安全1、主機安全：主機入侵檢測2、網站安全：Web應用防火墻、Web漏洞掃描3、App加固：無4、反DDos、反刷：Anti-DDoS流量清洗5、內容安全：無6、數據安全：無四、DaaS1、開發：無2、中間件服務：云應用引擎、分布式消息服務3、測試：無4、消息推送：消息通知服務5、研發管理：項目管理、配置管理、代碼檢查、編譯構建、測試管理、發布管理五、大數據1、云數據庫：關系型數據庫、分布式緩存服務2、大數據處理套件：數據接入服務、MapReduce服務、數據調度服務3、大數據應用引擎：無4、可視化工具：多維交互分析服務5、分析應用：無六、人工智能1、自然語言處理：無2、機器學習：機器學習服務3、圖片識別：無4、人臉識別：無5、語音識別：無6、圖像分析：無7、機器翻譯：無七、物聯網八、通用企業軟件1、云桌面2、通信平臺云3.5網易云一、云計算1、基礎云：無2、云主機：容器云（網易蜂巢）3、云存儲：無4、云網絡：無5、視頻云：網易視頻云二、云運維1、云監控：無2、云資源管理：無三、安全1、主機安全：無2、網站安全：無3、App加固：無4、防DDos、防刷：無5、內容安全：網易易盾6、數據安全：無四、DaaS1、開發：無2、中間件服務：無3、測試：網易易測、App性能監測：網易云捕4、消息服務：無五、大數據六、人工智能七、物聯網八、通用企業軟件1、通信：網易云信2、客服：網易七魚3.6新浪云一、云計算1、基礎云：無2、云主機：云應用引擎SAE3、云存儲：對象存儲4、云網絡：無5、視頻云：云直播二、云運維無三、安全無五、大數據無六、人工智能無七、物聯網八、通用企業軟件1、云郵箱2、云應用商店3.7樂視云一、云計算1、基礎云：無2、云主機：無3、云存儲：對象存儲4、云網絡：直播加速、點播加速、下載加速5、視頻云：標準點播、標準直播、移動直播、VR直播二、云運維無三、安全1、主機安全：無2、網站安全：無3、App加固：無4、防DDos、防刷：無5、內容安全：云版權6、數據安全：無四、DaaS無五、大數據1、云數據庫：無2、大數據處理套件：無3、大數據應用引擎：無4、可視化工具：無5、分析應用：Data+視頻分析、Data+人群洞察六、人工智能1、自然語言處理：無2、機器學習：無3、圖片識別：無4、人臉識別：無5、語音識別：無6、圖像分析：視頻鑒黃7、機器翻譯：無七、物聯網八、通用企業軟件1、云媒體、云新聞2、視頻發行平臺、互動直播運營平臺3、商業化直播服務、一站式視頻營銷服務、場館大屏營銷服務3.8360云一、云計算1、基礎云：高防DNS2、云主機：云主機3、云存儲：對象存儲4、云網絡：云加速、負載均衡5、視頻云：無二、云運維1、云監控：無2、云資源管理：無三、安全1、主機安全：云安全2、網站安全：網站衛士3、App加固：無4、防DDos：DDos基礎防護5、內容安全：無6、數據安全：無四、DaaS無五、大數據1、云數據庫：關系型數據庫MySQL、高速緩存服務memcached2、大數據處理套件：無3、大數據應用引擎：無4、可視化工具：無5、分析應用：無六、人工智能無七、物聯網無八、通用企業軟件無3.9京東云一、云計算1、基礎云：無2、云主機：云主機、云鏡像3、云存儲：云硬盤、對象存儲4、云網絡：子網、路由器、公網IP、負載均衡、CDN5、視頻云：無二、云運維1、云監控2、云管理：子賬號管理三、安全1、主機安全：監控報警2、網站安全：防火墻3、App加固：無4、防DDos：DDos基礎防護5、內容安全：無6、數據安全：無四、DaaS無五、大數據1、云數據庫：關系型數據庫、KV存儲2、大數據處理套件：數據地圖、數據探索、作業調度3、大數據應用引擎：無4、數據可視化工具：無5、分析應用：無六、人工智能1、自然語言處理：自然語言處理2、機器學習：機器學習、深度學習3、圖片識別：無4、人臉識別：無5、語音識別：無6、圖像分析：無7、機器翻譯：無七、物聯網無八、通用企業軟件無3.10美團云一、云計算1、基礎云：SSHKey管理2、云主機：虛擬主機、機械硬盤主機、SSD主機、物理主機3、云存儲：對象存儲4、云網絡：負載均衡5、視頻云：無二、云運維無三、安全無四、DaaS無五、大數據1、云數據庫：關系型數據庫MySQL、MongoDB、Redis、Memcached2、大數據處理套件：大數據計算（Hadoop、Hive、Spark、HBase）、流計算（Storm,Kafka,Flume）3、大數據應用引擎：無4、可視化工具：無5、分析應用：無六、人工智能無七、物聯網無八、通用企業軟件無3.11金山云一、云計算1、基礎云：云解析2、云主機：云服務器、云物理主機3、云存儲：對象存儲、云硬盤4、云網絡：負載均衡、虛擬專有網絡、彈性IP、內容分發網絡5、視頻云：云直播、云點播、云轉碼二、云運維無三、安全1、主機安全：服務器安全2、應用安全：漏洞掃描3、App加固：4、防DDos：防攻擊中心5、內容安全：無6、數據安全：無四、DaaS無五、大數據1、云數據庫：關系型數據庫MySQL、MongoDB、Redis、Memcached2、大數據處理套件：托管Hadoop3、大數據應用引擎：無4、可視化工具：無5、分析應用：無六、人工智能無七、物聯網無八、通用企業軟件1、企業云盤第三章中聯通CU-DC/OS1.研究背景中國聯通作為一個有IT歷史背景的公司，和現今其他靠IT驅動的服務業公司一樣有一定的歷史包袱。由于整個IT系統漸進發展，產生了新老系統并存、資源分散、設備異構、軟件環境異構等諸多問題。孤島式的IT資源和IT能力服務制約了企業轉型現代化服務業發展之路。隨著云計算出現，一定程度上解決了資源孤島、共享的問題，但是依然存在物理機資源調度的缺位，且現今虛擬機顆粒度的資源也收到了一定程度的挑戰，從業務發展上來說今后的IT資源一定是物理、虛擬、容器（進程級）資源相互并存的。IT業務驅動的企業需要尋找一條IT向I3能力，即創新性、信息化、集成化的IT能力的IT綜合治理轉型之路。近年來隨著中國聯通IT系統的大數據應用的不斷上升，聯通自身的IT資源在現在大數據應用發展的強大需求下面臨極大壓力。大數據中心3000余臺服務器設備中有77%是純物理機使用，傳統的IT資源管理方式造成了物理集群之間無法共享資源，從而造成有限資源的浪費。聯通IT系統集中化進程中，能力開放、服務能力供給側不足也成為了隨之而來的問題。所以，在聯通資源共享、服務化、開放化層面，需要一個統一的解決方案。2.CU-DCOS發展因此在2016年4月啟動了CU-DCOS項目，旨在解決聯通IT治理和能力開放等問題。經過初期的技術方案設計，在驗證了多種開源技術和商業化產品后，完成了技術路線的選擇，確定了CU-DCOS的基礎架構。2016年8月份啟動了CU-DCOS平臺開發，經過近6個月的研發和測試，突破了關鍵技術43項，完成了9大功能、56小功能的門戶開發，通過了技術測試和業務測試共59項。在2017年1月推出了CU-DCOS1.0平臺。之后在多個業務系統嘗試落地使用，并仍在持續進行產品化迭代研發?，F今，CU-DCOS平臺已能夠面向企業用戶提供40余種服務能力，其中包括大數據、數據庫、中間件以及技術、應用等服務，已能夠面向開發運維流程提供DevOps服務。為中國聯通公共創新大數據能力開放平臺、中國聯通PaaS平臺以及中國聯通牛人部落實驗室提供架構支撐和資源優化，大幅提升IT資源應用效率。CU-DCOS能力平臺利用其架構特質，對以下IT環節進行了優化：低運營成本：用戶能夠通過共享網絡、存儲、CPU內存等計算資源，在業務高峰期通過彈性擴容方式有效的應對業務峰值，在業務波谷期將資源分享給其他用戶，有效的節約了成本。簡化設備運維：在原有的IT體系中，研發團隊既需要維護應用程序，同時還要維護基礎設施。在CU-DCOS平臺架構中，開發人員面對的將是第三方開發或自定義的API和URL，底層硬件對于開發人員透明化了，技術團隊無需再關注運維工作，能夠更加專注于應用系統開發。提升可維護性：微服務應用將調用多種平臺的能力服務，組成最終的應用邏輯。目前，例如登陸鑒權服務，云數據庫服務等，在安全性、可用性、性能方面都進行了大量優化，通過直接集成平臺提供的服務，能夠有效的降低開發成本，同時使得應用的運維過程變得更加清晰，有效的提升了應用的可維護性。更快的開發速度：創新項目由于人員與資金等問題，不可能每個產品線都同時進行，通過CU-DCOS平臺，能夠很快進行產品開發的速度，把工作重點放在業務實現上，把產品更快的推向市場。3.CU-DCOS技術創新CU-DCOS平臺旨在通過新一代的云計算架構——容器技術，解決IT面臨的實際問題，完成IT資源的集中管理的新一代平臺系統。該平臺不僅驗證了以容器為基礎的PaaS平臺從模式、到技術的可行性，同時在行業內首次實現了面向大數據、物理資源彈性調度、多租戶管理的“資源+數據+能力“的平臺架構，在滿足公司數據管控要求前提下，實現了大數據能力的開放。3.1創新的獨立式技術架構使用Kubernets+Mesos+Docker的架構模式，集成了該領域領先開源技術，發揮了每個開源模塊的先天優勢，相較單獨開源軟件更適用于聯通生產業務。在有效管理容器化應用的同時，通過Mesos的框架資源調度功能，解決了物理資源完全按需共享的技術難題。

自動化細粒度擴縮容管理：獨創的根據資源使用率閾值自動觸發和根據時間周期性觸發的自動擴縮容能力，搭配業務量越大占資源越多、無業務不占資源的細粒度資源調度模式，將傳統的物理節點業務部署方式轉變為容器集群管理模式，根據業務需求“一鍵式”增減服務節點數量。3.2資源的統一管理面向中國聯通“兩地三中心”的跨地域、跨網絡的物理節點，CU-DCOS平臺可以實現統一管理調度，各應用能力“按需、按時”自動化資源分配，提高IT資源利用率，降低運營成本。3.3創新的大數據服務CU-DCOS團隊為了滿足對Hadoop生態體系需求，創新性的研發了基于Myriad的自動化多集群多租戶的Hadoop框架。經測試性能穩定，支持多種Yarn生態軟件如Hive、Spark等，并能夠做到計算存儲分離，本地計算，細顆粒度調度，資源預留、超售、搶占等計算資源的多元分配方案。

3.4持續集成/持續交付能力CU-DCOS平臺具有的DevOps能力支持快速迭代開發，從源代碼到上線全部在系統內流轉，當完成迭代上線時，業務應用已經封裝為容器鏡像并推送到私庫，用戶可實現不同版本應用的灰度發布，滾動升級。有效降低了業務割接和升級過程中出現的故障率，同時為服務供給側提供了便捷的研發環境和供給通道。3.5統一服務網關以Gateway方式實現統一服務路由功能，針對不同的租戶，實現服務能力化，需求差異化，針對不同需求，提供服務發現功能，讓應用之間無縫實現業務上下游串聯，真正的做到全流程自動化能力部署。同時優化了現有技術大大提高了服務發現和路由轉送的流程，縮短了56%的有效響應時間。

3.6多實例持久化存儲CU-DCOS平臺提供了多副本、高可用、可共享的分布式存儲，為容器增加了持久化存儲的能力，解決了容器長期以來有狀態部分的問題。在保證數據安全的前提下實現了容器調度的自動化管理，優化了代碼保證多個實例都能成功掛載并穩定運行。4.落地應用聯通研究院的CU-DCOS平臺面向企業內部，已服務支撐以下系統：4.1公共創新大數據能力開放平臺支撐了中國聯通公共創新大數據能力開放平臺，為平臺提供底層IT資源的整體調度、集群的動態擴縮容部署、大數據應用的容器化管理和編排以及統一的大數據服務開放等。實現了快速部署、秒級停啟各類應用，支持多種大數據服務的集群部署、負載均衡、災難恢復和彈性伸縮，為公共、專業、創新等各類應用的快速部署提供快速支撐。目前已成為公司開源技術與業務轉型相結合的創新型示范項目，相比于傳統的分配方式部署時間節省了80%以上，集群間資源利用率之差不超過10%，可靠性大幅度提升。4.2聯通PaaS平臺的基礎架構支撐中國聯通PaaS平臺的基礎架構，支撐整體PaaS平臺的資源調度和整合以及容器化封裝PaaS能力和編排調度等能力。目前已完成了全部15種PaaS能力的封裝，可對外提供服務。PaaS平臺上的數十個O域、M域應用已經完成CU-DCOS整體遷移，并且運行穩定。4.3聯通牛人部落實驗室的基礎架構支撐中國聯通牛人部落實驗室的基礎架構，目前已應用于百余臺設備并利用CU－DCOS進行統一的部署和資源調度。實現了大規模集群資源的動態管理、靈活的資源控制策略和應用安裝部署。成功搭建了開放式實驗環境，滿足中國聯通IT實驗室的需要。CU-DCOS的投入應用，將以其創新的技術架構，全面支持中國聯通實際管理、生產流程，并在中國聯通首次實現以物理資源統一管理調度，各應用能力“按需、按時”分配資源，大幅提高IT資源利用率，降低運營成本。第四章開源PaaS初探1PaaS平臺概述PaaS（Platform-as-a-Service,平臺即服務）是云計算領域的三個主要組成部分之一，是指將軟件研發平臺作為一種服務，以SaaS的模式提交給用戶。PaaS平臺的兩類主要客戶是開發人員、運維人員。PaaS平臺一方面連接IaaS為應用的提供云計算環境，一方面通過SaaS為應用提供平臺基礎設施服務，因此要求PaaS平臺在為應用提供業務功能的同時具備彈性伸縮的能力和智能化運維功能。綜上所述，PaaS平臺功能架構主要由以下部分構成：(1)支撐應用的基礎軟件和中間件支撐（如數據庫、Web服務、應用框架和消息服務等）(2)基于云計算的應用部署運行環境和開發環境，包括共享應用資源庫和開發社區支持等(3)多租戶支持與管理PaaS平臺邏輯架構主要包括基于上述功能映射形成的各種類型的服務插件，以及服務間隔離設施來保障服務的相互獨立性。PaaS平臺從云計算框架建立之初就開始發展，初期主要是國內外大型互聯網企業，比如Google、SalesForce等，構建了自己的PaaS平臺，是獨有產權的封閉PaaS平臺，未對外公開發布其架構。傳統的封閉的PaaS平臺主要有三類提供商，一類是互聯網企業提供的PaaS平臺，典型代表是GoogleAppEngine；一類是原有的SaaS提供商，典型代表是SalesForce的Heroku；一類是以Amazon為代表的從IaaS虛擬化實施起步而逐步擴展出PaaS層平臺的提供商。這三類平臺以實現其自身的商業價值為主要目標明確了初期PaaS平臺的功能范疇和架構要素。隨著開源PaaS平臺的崛起，新的技術趨勢逐步明朗，改變了原有PaaS平臺產業鏈的競爭格局和發展方向。2.主流的開源PaaS平臺2011年4月，第一個開源PaaS項目CloudFoundry誕生。隨后，開源PaaS平臺層出不窮，得到了各大廠家和大量開發者的支持，版本的更新和新思路出現的頻率遠高于原有封閉的PaaS平臺，也推動了PaaS平臺架構設計理念的發展演化。2.1CloudFoundryCloudFoundry是VMware公司推出的業界第一個開源PaaS平臺，并于2013年發布了最新的2.0版本。CloudFoundry作為基于云環境的PaaS平臺，核心是一套消息系統，通過CloudFoundry消息總線組件（NATS）實現了一套模塊自注冊、自發現的松耦合消息發布訂閱機制，并將各種功能抽象為模版、服務通過消息總線連接起來[2]。其最新版本的邏輯架構如圖1：對比CloudFoundry的早期版本，新版的主要變化如下：(1)加強了服務總線，統一規范了服務的處理模式。新版的CloudFoundry中內置服務數量大幅減少，新增的DB、存儲、消息隊列服務，比如Neo4j圖形數據庫、RabbitMQ消息隊列等，均作為標準服務與外部服務和框架一起作為標準服務接入ServiceBroker并提供給應用使用。(2)引入大數據處理。CloudFoundry在DEAPool中提供了日志管理組件Loggregator，支持應用以日志流的方式將日志數據接入到CloudFoundry完成大數據分析，這樣就使得大數據庫分析服務成為新版PaaS平臺對外提供的服務。2.2CloudifyCloudify是Gigaspaces公司推出的基于java實現的PaaS平臺。Gigaspaces是業界知名的PaaS提供商，也是高端Java應用服務器產品XAP（eXtremeApplicationPlatform）的提供廠家。Cloudify實現PaaS的主要思路是把云資源以及業務功能單元看作獨立的計算節點，通過編排技術分別去關聯計算節點，形成可定制的PaaS平臺服務。這一設計思想與其早期產品XAP的設計理念一脈相承。這種方式使得Cloudify很輕薄，但也具有相當的服務提供能力，是從另一種角度闡述了PaaS最核心的本質，即將軟件研發的平臺作為一種服務交付給用戶。新版的邏輯架構如圖2：對比新舊版本的架構，我們發現的新變化如下：(1)秉承了輕薄化的線路并對功能架構做了增強，如客戶端支持從原有的一種接入模式擴展到了三種類型的接入模式。(2)新增了日志數據管理，開始提供大數據分析支撐。通過日志數據管理工具，Cloudify實現了對其自身的日志分析、查詢、匯總和存儲的支持，遺憾的是還不能對其平臺上加載的應用提供類似日志分析的大數據支撐。2.3Docker如果要列舉2013年至今開源PaaS平臺發展的主要事件，Docker的發布應算其一。Docker是PaaS提供商dotCloud開源的一個基于LXC的高級容器引擎。短短時間內，Redhat在RHEL6.5中集成對Docker的支持,GoogleComputeEngine也支持Docker在其之上運行。Docker平臺主要由DockerEngine、DockerHub兩部分組成。DockerEngine是應用的運行環境和打包工具，DockerHub則主要包括平臺功能的應用開放API。Docker在技術模式上最大的創新在于其改變了PaaS平臺實現虛擬化的技術路線，并將一個更加輕量、簡潔的可實現PaaS平臺模式展示給大眾。Docker不是基于傳統的Hypervisor技術來構建多個相互獨立的虛擬操作系統，而是直接對操作系統本身的功能進行擴展來實現虛擬化，從而使得實現虛擬化的技術層次從操作系統層降低到了操作系統容器內，從而實現了PaaS的輕量化。上述思路的具體的實現主要是：基于Linux的LXC，通過Linuxnamespaces機制做權限的控制和隔離，用Linuxcgroups來進行資源的調度和分配，并通過Linuxaufs文件管理機制實現應用復制、重建、移動，從而實現大規模部署和更新。在其他PaaS平臺中作為服務提供給應用的各項基礎設施，比如數據庫等，在Docker中是以鏡像加容器的形式來實現的。Docker鏡像、容器及其與Linux的關系如圖3：Docker鏡像（Images）是基于Linuxaufs機制來實現的。首先建立基礎根文件系統（Bootfs），并在其之上建立分層的、與服務對應的Docker鏡像，鏡像之間是有繼承（父子）關系的，每一層鏡像的下面一層稱為父鏡像，最后在鏡像之上針對每個應用的實例化就是容器。2.4小結基于上述的分析，上述開源PaaS平臺的特征概況小結如表1：3開源PaaS發展趨勢我們可以看到以下這些技術趨勢在各個開源PaaS平臺的架構升級中都有體現：3.1輕量化無論是CloudFoundry對內置服務的縮減，還是Cloudify對輕量化設計思路的堅持，以及Docker的火熱，都折射出的PaaS產業鏈各方對輕量化的認同，都反應了PaaS平臺輕量化的發展趨勢。降低客戶端的難度，讓更多的現有應用接入到PaaS平臺，讓更多的開發人員參與到PaaS平臺中，將為PaaS平臺的后續發展帶來無盡的可能性，也許這就是新時代信息技術的魅力吧。3.2服務外化原有的PaaS平臺希望為給用戶提供一個集成的開發環境，內置了諸多系統服務，以期降低開發者的門檻，但是卻帶來了部署繁瑣、移植難度大的問題。為了兼顧運營維護的便利性，PaaS平臺開始剝離內置的系統服務，將系統服務與第三方服務一視同仁，將包括Mysql等基礎數據庫的系統服務與第三方服務都作為標準的服務接入到統一的服務框架中，服務框架自身也推動了PaaS平臺走向更加開放與分布式。同時，為了支持服務的相對獨立，PaaS平臺通過服務總線、應用編排、消息總線的組合來支持服務與應用間的互聯互通。上述趨勢無論在Cloudify、CloudFoundry還是新興的Dokcer中都可以看到，一方面，PaaS架構變得清晰明確而更加易于大規模部署，一方面也給了應用更加明確的可為空間，只要應用足夠便利和廣泛，就可以作為服務接入到平臺中提供給其他應用。3.3大數據分析隨著PaaS平臺承載的應用類型越來越多樣，面向的用戶越來越廣泛，PaaS平臺上的各種業務數據、客戶數據也越來越具有統計分析價值。大數據分析既可以作為PaaS平臺自身的資源動態分配的依據，對應用推廣和引導應用研發也具有重要的參考價值。目前，越來越多企業、供應商已經認識到大數據需要作為PaaS平臺的核心要素為平臺運營和應用研發提供支持。無論是CloudFoundry引入數據分析工具，還是Cloudify加強自身平臺對大數據分析的支持，我們都能深切的體會到這種趨勢。4.結束語開源PaaS平臺帶動了整個PaaS領域的技術進步，在開源平臺具有技術優勢的背景下，更多的商業企業采用了開源平臺作為基于互聯網的新信息平臺的基礎框架。在互聯網信息化的浪潮中，作為原有企業信息化的主要建設者的電信運營商需要抓住機遇，在變革中結合自身的業務、技術發展需要與新技術趨勢，調整自身的平臺建設和發展策略，為未來的競爭奠定優勢。第五章傳統企業PaaS上云思考（薦）1.背景說明伴隨著Docker技術的興起，以及容器集群管理平臺Mesos、Kubernetes、Swarm、Rancher等的大行其道，仿佛PaaS平臺及其相關技術一下進入了黃金時期，各種各樣的技術組合，各種各樣的技術驗證，以及伴隨著容器相關的創業公司布道，仿佛只要有了PaaS平臺及其相關的技術，就能解決一切的企業IT問題。但是，企業IT，尤其是非互聯網傳統企業，PaaS平臺的構建與業務上云是一個長期化的過程，絕不是一個Docker+kubernetes/Mesos/Swarm構建完以后就是完成了的，IaaS年代是這樣，PaaS年代也是這樣。

在互聯網公司或者自研發型的應用，開發環境與部署運行環境非常的類似，這也是Docker或者容器相關技術在應用上的一個很大的優勢（比如構建開發、測試、部署的DevOps流水線），但是在傳統企業便不一定能行得通，比如某個企業的IT應用開發維護是外包的，標準軟件需要采購、應用開發需要在應用開發商完成、硬件是另外的硬件提供商，到貨后需要硬件系統集成、標準軟件部署、應用開發部署調試，需要很多供貨商來完成，往往以項目經理統籌完成，很難由一套DevOps之類的平臺來解決所有問題。那么傳統企業PaaS平臺設計需要什么樣的功能？上云時又需要進行如何改造，這是我們探討的一些重點。2.傳統架構與應用分類2.1經典架構

大家對這種架構耳熟能詳，但也請做云計算或者容器技術的同事不要對這種架構嗤之以鼻，但是這種架構在也包含很多的對我們有學習借鑒意義的技術模塊：SAN存儲：包括高、低、中不同的存儲，存儲中磁盤的RAID配置、存儲池配置、存儲的集群配置、存儲的容災備份、數據的熱點遷移、數據的緩存、存儲之間的SAN交換機配置（劃分Zoning，連接主機）等都需要專業的存儲工程師（衍生出來了很多的認證），這種存儲可以做到高IOPS、低延遲、高可靠性，是目前大多數的分布式存儲難以匹敵的，且目前存儲廠商在SAN上也做到了虛擬化；主機：小型機、x86服務器，小型機以IBM小型機為例，小型機虛擬化比x86虛擬化出現的年代早了幾十年，當時是硬分區技術，后來發展到邏輯分區+IO虛擬化，邏輯分區可以做到分配0.1個CPU的細粒度，同時也在2007年就推出了類似于容器的技術，做到了進程級別的隔離，但因為不開源、不方便打包、鏡像管理沒有Docker方便，最終只在少數客戶處進行了部署使用；DB：傳統的數據庫廠商比如Oracle為例，很早就推出了RAC技術，同時，2012年左右Oracle研發中心內部就開始使用Container技術搭建DBasaService（這比我們目前大多數的Docker相關的創業公司還早）；APP：以IBMWebSphere為例，十年之前就有WAS集群的概念，可以部分做到橫向擴展。

傳統企業這種架構統治了企業IT數十年之久，在大的行業，通常以商用中間件、商用DB、小型機、SAN存儲部署。這種架構存在擴展性不足的問題，但是在傳統企業架構中大量存在。

2.2OLAP與OLTP我們部署一個IT系統，最終的目的是為了解決傳統的問題，所謂把線下業務線上化，這些業務最終的服務對象是數據，而數據處理大致可以分成兩大類：聯機事務處理OLTP（on-linetransactionprocessing）、聯機分析處理OLAP（On-LineAnalyticalProcessing）。

當然還有其他的業務類型，比如銀行或者運營商的每月出賬系統，這種系統為也是一種批處理系統，但是實時性很強，跟HadoopMR所謂的批處理不是一個概念，也不在一個層級。這種應用我們暫時不考慮。

OLTP，也叫聯機事務處理（OnlineTransactionProcessing），表示事務性非常高的系統，一般都是高可用的在線系統，評估其系統的時候，一般看其每秒執行的Transaction以及ExecuteSQL的數量。典型的OLTP系統有客戶關系管理系統、電子商務系統、銀行、證券等。

要求：一致性、高可用性。

OLAP，也叫聯機分析處理（OnlineAnalyticalProcessing）系統，有的時候也叫決策支持系統，就是我們說的數據倉庫。在這樣的系統中，語句的執行量不是考核標準，因為一條語句的執行時間可能會非常長，讀取的數據也非常多。所以，在這樣的系統中，考核的標準往往是磁盤子系統的吞吐量（帶寬），如能達到多少MB/s的流量。3.云化需求與分析下面我們分別分析一下這兩類應用的云化需求與云化的分析。注意：這些要求分析與要求是在Docker與各類容器管理平臺火起來之前總結與做的，不是依據Docker或者容器相關技術的要求做的。所