伴隨著Docker技術的興起，以及容器叢集管理平臺Mesos、Kubernetes、Swarm、Rancher等的大行其道，彷彿PaaS平臺及其相關技術一下進入了黃金時期，各種各樣的技術組合，各種各樣的技術驗證，以及伴隨著容器相關的創業公司佈道，彷彿只要有了PaaS平臺及其相關的技術，就能解決一切的企業IT問題。但是，企業IT，尤其是非網際網路傳統企業，PaaS平臺的構建與業務上雲是一個長期的過程，絕不是一個Docker+kubernetes/Mesos/Swarm構建完以後就能完成的，IaaS年代是這樣，PaaS年代也是這樣。

在網際網路公司或者自研發型的應用，開發環境與部署執行環境非常的類似，這也是Docker或者容器相關技術在應用上的一個很大的優勢（比如構建開發、測試、部署的DevOps流水線），但是在傳統企業便不一定能行得通，比如某個企業的IT應用開發維護是外包的，標準軟體需要採購、應用開發需要在應用開發商完成、硬體是另外的硬體提供商，到貨後需要硬體系統整合、標準軟體部署、應用開發部署除錯，需要很多供貨商來完成，往往以專案經理統籌完成，很難由一套DevOps之類的平臺來解決所有問題。

那麼傳統企業PaaS平臺設計需要什麼樣的功能？上雲時又需要進行如何改造？這是本文探討的重點。

一、傳統企業的應用架構與應用分類

大家對這種架構耳熟能詳，但也請做雲端計算或者容器技術的同事不要對這種架構嗤之以鼻，因為這種架構也包含很多對我們有學習借鑑意義的技術模組：

• SAN儲存：包括高、低、中不同的儲存，儲存中磁碟的RAID配置、儲存池配置、儲存的叢集配置、儲存的容災備份、資料的熱點遷移、資料的快取、儲存之間的SAN交換機配置（劃分Zoning，連線主機）等都需要專業的儲存工程師（衍生出來了很多的認證），這種儲存可以做到高IOPS、低延遲、高可靠性，是目前大多數的分散式儲存難以匹敵的，且目前儲存廠商在SAN上也做到了虛擬化；
• 主機：小型機、x86伺服器，小型機以IBM小型機為例，小型機虛擬化比x86虛擬化出現的年代早了幾十年，當時是硬分割槽技術，後來發展到邏輯分割槽+IO虛擬化，邏輯分割槽可以做到分配0.1個CPU的細粒度，同時也在2007年就推出了類似於容器的技術，做到了程序級別的隔離，但因為不開源、不方便打包、映象管理沒有Docker方便，最終只在少數客戶處進行了部署使用；
• DB：傳統的資料庫廠商比如Oracle為例，很早就推出了RAC技術，同時，2012年左右Oracle研發中心內部就開始使用Container技術搭建DB as a Service（這比我們目前大多數的Docker相關的創業公司還早）；
• APP：以IBM WebSphere為例，十年之前就有WAS叢集的概念，可以部分做到橫向擴充套件。

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

我們部署一個IT系統，最終的目的是為了解決傳統的問題，所謂把線下業務線上化，這些業務最終的服務物件是資料，而資料處理大致可以分成兩大類：聯機事務處理OLTP（on-line transaction processing）、聯機分析處理OLAP（On-Line Analytical Processing）。

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

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

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

OLAP，也叫聯機分析處理（Online Analytical Processing）系統，有的時候也叫決策支援系統，就是我們說的資料倉庫。在這樣的系統中，語句的執行量不是考核標準，因為一條語句的執行時間可能會非常長，讀取的資料也非常多。所以，在這樣的系統中，考核的標準往往是磁碟子系統的吞吐量（頻寬），如能達到多少MB/s的流量。

下面我們分別分析一下這兩類應用的雲化需求與雲化的分析。

注意：這些要求分析與要求是在Docker與各類容器管理平臺火起來之前總結與做的，不是依據Docker或者容器相關技術的要求做的。所以，對我們跳出容器的慣性思維，構建一個適合傳統企業的PaaS雲平臺有很強的指導意義。

二、傳統企業的應用雲化改造需求

（一）OLTP類應用雲化的要求

雲化關鍵點1：系統彈性伸縮

通過應用與資料分離和叢集化部署，實現系統快速擴容、處理能力靈活水平線性擴充套件、故障自動隔離。對於獨立的應用主機可以進行靈活彈性伸縮。

彈性伸縮特點：

1. 線上快速擴容：系統擴容操作低耗時、無資料遷移、服務不間斷；
2. 處理能力線性擴充套件：系統處理能力可以通過新增節點近線性提升，實現高吞吐、高併發處理能力，應對業務爆發式增長；
3. 故障自動接管：叢集可以自動發現故障節點並調整任務排程策略，在不影響處理的同時接管故障節點，保持系統高可用。

雲化關鍵點2：應用叢集化部署

將緊密耦合的大應用模組化拆分為多個模組化小應用，通過資源池提供系統資源的整體利用率，並將拆分後的子模組部署於資源池（後來我們搞Docker的稱之為微服務化）。當硬體資源實施池化後，才具備了支撐應用的彈性伸縮，實現硬體的按需分配的基本需求，充分提高資源利用率。

雲化關鍵點3：通過資料分級分類實現應用與資料分離

根據資料實時性、重要性、敏感性等因素，將資料分成數個級別，各個級別的資料對系統的作用、採用儲存、保護方式也都有所不同。

通過對應用提供資料的透明訪問，遮蔽資料的位置差異、資料分佈差異、資料儲存等差異：

1. 位置無關性：資料在遠端還是本地儲存，對應用最好透明。
2. 分佈無關性：資料分佈在多個數據節點，對應用透明。比如查詢某個客戶的所有相關資料，雖然同一個使用者資訊分佈在多個數據節點上，但對應用來說就好像一個集中資料庫進行查詢。
3. 儲存無關性：資料儲存在記憶體庫、物理庫（關係型資料庫、NoSQL資料庫）、File還是快取等介質，對應用透明。

雲化關鍵點4：合理規劃實現資料分散式部署

對不同業務的資料、不同型別的資料進行有效規劃部署。通過某種特定的條件，將存放在同一個資料庫中的資料分散存放到多個數據庫上，實現資料分佈儲存，通過路由規則路由訪問特定的資料庫。

資料庫拆分方式包括：

• 垂直（縱向）拆分：將資料庫表按業務、功能拆分到不同的資料庫表，比如分為客戶資料庫、訂單庫、資源庫、資料庫等，這種方式多個數據庫之間的表結構不同；目的是降低業務之間的影響，減少系統承載壓力。
• 水平（橫向）拆分：將同一個表的資料進行分塊儲存到不同的資料表中，這些資料庫中的表結構完全相同。

拆分以後，帶來的問題，需要做到：對外提供統一訪問，對應用遮蔽資料訪問複雜度。資料訪問層提供資料互訪能力，拆分訪問合併返回。

所以需要構建統一資料訪問引擎，或者資料路由層（Data layer層）。開源的比如有Hibernate Shards、Ibatis-Sharding、淘寶TDDL等。

雲化關鍵點5：資料平臺化

資料平臺化是指通過應用架構和資料架構的重新梳理、規劃與調整，將業務處理中的業務資料和狀態資料與應用分離，實現應用的輕量化、無狀態；構建統一的資料訪問層，實現資料的共享訪問。資料平臺化是資料處理水平線性擴充套件的前提和基礎。

資料平臺化特點：

• 應用輕量化：縮短開發週期，提升新業務響應速度；
• 應用無狀態：實現應用的同質化，應用層處理能力的獨立擴充套件，實現應用靈活排程和分配；
• 資料共享訪問：逐步實現資料集中訪問，跨地市的流量共享、流量統付、流量轉移業務能夠更高效支撐。

（二）OLAP型應用雲化的需求

首先看一下傳統的資料倉庫典型架構：

這種架構以處理結構化資料為主，基本部署於Oracle、小型機、SAN儲存之上，擴充套件性不足，難以處理海量資料。大資料處理技術的興起讓這類應用的雲化找到了思路。雲化時總體推薦混搭架構，即採用多種技術架構建設大資料中心：

1. 垂直混搭架構：

這種架構比較容易部署，但會形成多個相互獨立的資訊孤島；未來缺乏可行的系統演進路；

2. 水平混搭架構：

• 企業級資料雲平臺：逐漸實現企業內資料的統一儲存，承載資料的加工計算；未來提供企業資料的統一儲存和計算能力；
• 資料倉庫、集市和挖掘庫：計算逐漸遷移到雲平臺實現輕載化；直接從雲平臺載入應用結果資料，實現上層應用的相容性；
• 流處理平臺：實時計算結果儲存到雲資料平臺，可通過能力開放平臺的訊息中介軟體直接供應用訪問。

OLAP雲化關鍵點1：資料計算引擎開源化

M/R計算引擎：用HDFS檔案保證每一步計算結果，避免硬體故障導致重頭執行。

• 優點：可靠性高；
• 缺點：資料處理任務是一系列M/R任務的序列執行，輸入和輸出都是HDFS檔案，導致頻繁的磁碟I/O，執行速度慢；
• 侷限性：原始單一的程式設計模型和資料結構，導致開發效率低，限制更多應用的產生。

Spark計算引擎：RDD是分散式記憶體的抽象。

• 優點：執行效率比起M/R提升100倍以上；提供豐富的操作運算元增強程式設計能力，簡化應用開發；
• 缺點：對記憶體等資源要求高；可靠性不如M/R；
• Yarn實現資源排程和分配：一個節點上可同時執行M/R和Spark任務，資源相互隔離、執行互不干擾。

OLAP雲化建設關鍵點2：資料集市雲化建設

建設現狀：傳統小機+Oracle資料庫和新建的MPP資料庫兩種建設模式。

• 演進策略一：用MPP資料庫來取代小機+Oracle資料庫；
• 演進策略二：用資料雲平臺+開源MYSQL/PGSQL叢集來代替小機+Oracle資料庫。

資料雲平臺完成所有的後臺計算。

OLAP雲化關鍵點3：資料ETL雲化建設

• 傳輸的實時化：支援MQ等分散式實時訊息傳輸機制；
• 基於記憶體的計算：資料不落地，避免海量資料的兩次重複載入；
• 計算的輕量化：清單級的過濾、排重、規則化，更多的計算任務由大資料儲存和計算平臺來完成；
• 分散式並行執行：高可用性、分散式排程、資源分配；
• 技術實現：Kafka+HDFS+MR/Spark。

三、基於容器的PaaS平臺架構的構建

我們提到了傳統企業中兩類核心的應用，並且在Docker流行之前便規劃了一些雲化的關鍵點，並形成了PaaS平臺，使之運行於IaaS平臺與Hadoop YARN叢集之上。

基於此架構有以下幾個主要問題：

1. 可以實現應用編排與部署，但是編排的基礎單元是虛擬機器模板，模板比較重，而且映象很難修改，編排、分發、執行、持續整合等都有很大的困難，因此構建在模板上的應用形成的服務很難用；
2. 基於虛擬機器的彈性伸縮相應時間也比較慢，我們嘗試做過基於Cloudwatch+Autoscaling的虛擬機器彈性伸縮功能，發現彈性伸縮對業務的響應時間有一個偏差，這個偏差大約在十幾分鍾，在搶購、秒殺等業務中基本不可接受；
3. 很難在企業內部形成一個統一的私有云叢集來同時執行這兩類業務，因此兩個PAAS叢集實際上是兩個獨立的叢集，都是按照業務最高峰配置，存在資源浪費的現象，運維也是分開運維。

Docker及其相關技術興起之後，我們基於容器的相關生態圈技術，構建了新一代PaaS平臺。

使用容器+容器映象管理替代服務目錄管理+虛擬機器模板管理。

在Instance PaaS（iPaaS）平臺上除了基於Kubernetes的容器管理、映象管理、應用管理等功能，還構建瞭如下子系統：

• 日誌子系統：基於ELK實現；
• 計算子系統：整合OpenStack與自研的Skyform CMP；
• 儲存子系統：通過Cinder，支援ISCSI、NFS、Ceph三類儲存，與IaaS打通；
• 網路子系統：我們選用了Netron+OVS的SDN解決方案；
• 監控子系統：通過Ceilometer+MongoDB進行實施資料的監控、Phoenix+Hadoop進行歷史資料分析；
• 使用者互動子系統：基於Node.js開發。

整體的PaaS平臺構建基於Kubernetes、Hadoop、Spark on Mesos，構建完整的DCOS平臺。

需要說明的是，在傳統企業在雲平臺還需要對接大量的系統，比如ITIL、4A/3A、人力資源系統、審計系統等，這些系統與雲平臺的介面整合不在本次討論範圍內。

下面說一下基於以上的PaaS平臺對傳統應用雲化關鍵點的解決。

針對OLTP類應用雲化的5個關鍵點的解決：

1. 系統彈性伸縮：通過Kubernetes RC+service實現；
2. 應用叢集化部署：通過Mesos/Kubernetes構建x86叢集，將應用分散式改造以後部署與叢集；
3. 通過資料分級分類實現應用與資料分離：通過Big data PaaS的HDFS服務與Instance PaaS的DB服務可以提供部分資料分級服務的基礎，但是資料分級與儲存，以及訪問透明性未能完全實現，需要在業務層面進行適配；
4. 合理規劃實現資料分散式部署：通過在Instance PaaS提供資料庫服務，以及開開源資料路由服務，實現，注：需要DBA規劃資料的儲存；
5. 資料平臺化：應用改造後即可實現。

OLAP雲化的3個關鍵點的解決：

1. 資料計算引擎開源化：可由Bigdata PAAS直接提供MR、Spark服務；
2. 資料集市雲化建設：可由Instance PaaS平臺提供開源MySQL+TDDL實現；
3. 資料ETL雲化建設：可由Instance PaaS提供Kafka、Big data PaaS提供MR、SPARK實現。

四、PaaS平臺問題及傳統應用上雲改造的一些注意點

（一）基於Kubernetes、Hadoop、Spark on Mesos的問題

這種排程實際上是兩級的排程框架，Mesos本身只管資源（主要是CPU與MEM），提供offer給上層的排程框架使用。一級排程即Mesos層有兩種排程模式：

1. Mesos粗粒度，這種模式下，一旦一臺機器（一個Node）分配給某個框架，其他框架便不能使用；
2. Mesos細粒度，這種模式下，多個框架可以共享一臺機器（一個Node）。

粗粒度存在資源還是不能完全共享的問題，因此仍然有資源浪費的問題，細粒度模式可以改變這種問題，但是又帶來新的問題：

1. Mesos叢集執行多種框架，包括Spark，也執行著很多Web、中介軟體、資料庫等服務，但是Mesos不支援搶佔，無法設定任務優先順序，而Spark預設是貪婪模式，這樣就會出現Spark執行時無法釋出其他Web任務到Mesos叢集上的情況。
2. Hadoop與Spark在執行時，Shuffle階段資料會互動寫HDFS磁碟，這時網路資源會被大量佔用（我們稱之為東西向流量），導致Web服務基本不能響應（我們稱之為南北向流量）。

（二）多租戶的問題

目前多個框架之間每個都有自己的使用者管理模式，預設情況下，如果多個框架之間有交叉使用，需要在多個框架之間租戶互相打通，涉及到Mesos、Hadoop、Kubernetes的賬號打通問題，需要開發獨立的賬戶中心，並且完成同步。

最後討論一下應用上雲時的考慮點，並給出一個例子：

1. 應用最好無狀態，無狀態化的應用天生適合上雲。這時服務的註冊於發現、應用的彈性伸縮完全交給雲平臺來做，比如Mesos+Marathon的HAProxy+etcd+Confd或者Kubernetes8s的service+RC；
2. 已經叢集化的應用元件部署相對困難，比如基於PaaS平臺釋出單個例項的Redis容器，但是釋出Redis叢集就比較困難，苦難就困難在Redis叢集中的節點需要相互通訊，而容器如果重啟或者IP發生變化都會對叢集造成影響；
3. 服務註冊與發現如果應用本身提供了，PaaS平臺的服務註冊與發現功能便不能使用，不能兩套服務註冊與發現同時使用。

這裡給出一個應用上雲部署的例子：

上圖左邊是某傳統企業電商應用最初架構，Web部署於一臺高配置x86伺服器、APP部署於一臺中端小型機、DB部署於一臺中端小型機，右邊是初步進行了改造後的架構，即遷移到PaaS平臺之前應用已經做了模組化與叢集化的初步改造：

1. 前臺用負載均衡將流量引入到三個Web節點中，每個Web節點部署於x86伺服器，Session集中存在Redis叢集（無狀態化改造，互動用HTTP+JSON短連線）；
2. APP層也通過Redis集中存放狀態資訊，做到了無狀態化，每個APP節點部署於三臺x86伺服器；
3. Web與APP在流量大的時候可以做到手動擴容，但是需要配置固定的IP，APP服務（提供給）的註冊發現是基於ZooKeeper完成（應用自己來完成服務註冊於發現）；
4. DB層做了主從資料庫，部署與x86伺服器。

該應用裡面還用到了Kafka，用來做資料匯流排，也採取了叢集化部署。

針對目前的現狀，如上圖，應用遷移到PaaS平臺需要做三方面的工作：

1. 完成Web層的服務註冊與發現，在此基礎上實現web層的自動擴縮容，此處基於Kubernetes的ingress service（一個改造後的Nginx，執行在一個Kubernetes的POD裡面）實現軟負載+RC控制節點伸縮實現（每個Web部署於一個pod）；
2. APP層的自動擴縮容，由於已經完成了基於ZooKeeper的服務註冊於發現，所以只需APP層能夠彈性伸縮部署即可；此處基於RC控制節點伸縮實現；
3. DB層由於執行穩定，暫時不做PaaS化但是，基於訪問路由做到分散式部署。

剩餘一個問題需要探討，Redis叢集、ZooKeeper叢集、Kafka叢集（用作訊息匯流排）要不要做PaaS化？如何做？

首先回答一個問題，Redis、Zookeeper、Kafka等叢集PaaS化（容器化）的難點在哪兒？

主要是這些叢集節點之間的互相通訊與資料傳輸即東西向流量，要求這些節點之間的IP配置需要固定IP，而且重新啟動以後相應的配置資訊不能改變。容器自身的啟動、網路配置比較動態化，對需要固定的叢集配置而言是一個挑戰。

比如大多數的PaaS平臺提供單個例項的Redis快取服務不是問題，但是提供任意配置的Redis叢集便不支援。我們經過前期的測試，實現了容器平臺下的此類應用的叢集化部署，以ZooKeeper為例：

ZooKeeper自身部署要求：

1. ZooKeeper client依賴固定ZooKeeper server IP來完成服務；
2. ZooKeeper server配置（所有成員IP必須固定）；
3. 至少3個獨立節點；

解決方案（基於Kubernetes）：

1. Client通過固定3個service IP連線ZooKeeper server；
2. 構建3個單POD的RC；
3. 配置DeamonSet，指定ZooKeeper的POD所啟動執行的主機；
4. ZooKeeper自身配置使用Service DNS name；
5. 儲存進行持久化。

最後，需要說明的是，應用上雲後一個很重要因素，PaaS平臺（Docker為基礎的構建），穩定性與可靠性也是至關重要的，我們在部署遷移應用時，每次都會針對應用做較為詳細的測試，測試案例包括：

• 無負載的POD併發測試；
• 頻繁建立帶業務的POD及其穩定性；
• 業務的併發性測試；
• 不同業務的IO併發效能測試；
• 容器間網路效能測試；
• 幾類常見的資料庫效能測試；
• Nginx叢集效能測試；
• Kubernetes Rc機制測試；
• Docker對MEM資源限制能力的測試；
• Docker對程序數量限制能力的測試；

等等。這些測試方面供大家參考，具體測試方法與步驟可針對應用自行設計，不在這裡具體分享。

Q&A

Q：在你的新一代PaaS平臺中，我怎麼對公司的很多個不同的應用做不同的叢集，有些叢集偏向於大量的IO佔用，有些叢集偏向於大量的網路佔用，有些叢集偏向於大量的記憶體佔用，並且啟用的叢集間還有通訊和互動，針對這些不均衡現象該如何處理？

A：所以PaaS平臺硬體資源會針對不同應用去做區分，在企業私有云建設時，需要對應用進行梳理，將不同的應用分類，底層採取相應叢集支撐，比如計算密集型、IO密集型等，同時綜合考慮波峰波谷與業務特性進行配置。

Q：公司有很多Web系統，每一個Web系統都有自己的儲存、資料庫，所以如果融入PaaS平臺的話，首先第一點軟硬體問題如何做到全部滿足，其次就是就算把我的DB層整合遷徙到你的PaaS的DB層，我是不是還要做其它方面的投入，比如開發成本等等，還有就是DB的相容性是不是會有問題？

A：Web層我們推薦做無狀態化，且要做應用與資料分離，session資訊集中存放。DB遷移到PaaS層是一個比較慎重的過程，PaaS層優先考慮開源資料庫。如果原先是MySQL基於PaaS平臺也提供的MySQL資料庫服務，那麼開發成本基本比較小，只需考慮版本問題。

Q：請問MySQL部署資料應用能承載多大資料量，響應速度如何？

A：我們一個專案中，採用讀寫分離的MySQL架構，幾千萬的資料表，及時查詢沒問題，這也要看硬體配置與資料索引的建立等。

Q：有些傳統公司，有些軟體裝置是以序列號安裝使用的，所以這一塊融入PaaS平臺是不是不太可能？

A：比較困難，另外還有一個問題是License限制的問題，在彈性架構中也比較難。

Q：請問架構改造會不會導致應用要重新開發？

A：會，從IOE架構到x86架構，從x86物理機到虛擬機器到Docker，應用需要以越來越小的模組化分散式部署，也就是說逐步向微服務化過渡。

Q：為什麼Kubernetes和Mesos要一起用呢，考慮點在哪裡？

A：針對單個應用Docker化，我們開始的選型定位在Kubernetes，主要考慮了POD的應用場景更類似虛擬機器，另外Kubernetes的模組比較豐富，像負載均衡、服務發現等已經成熟，後來用Mesos是因為需要把大資料之類的應用進行整合。需要Kubernetes/Spark on Mesos。

Q：開發週期過長或者客戶開發能力弱會導致整個架構流產 有配套的應用改造方案嗎？

A：對傳統企業而言，一開始就搭建一個大而全PaaS方案是不現實的，我們推薦從某一個典型應用做起。我們針對交易性應用、分散式應用、批處理應用等應用都有配套改造方案。

Q：Mesos使用集中式儲存和分散式儲存效率上有什麼不同嗎？

A：這個看應用，集中式儲存在叢集中應用時，如果針對單一與應用劃分Volume，效能會好一些，如果是分散式應用，比如MR類的應用，分散式儲存反而會好。

Q：容器彈性伸縮策略具體怎麼考慮的，CPU？

A：CPU、記憶體、IO、使用者連線數等都可以作為彈性伸縮的策略依據。