傳統(tǒng)企業(yè)PaaS平臺功能設(shè)計與業(yè)務(wù)上云思考

傳統(tǒng)企業(yè)PaaS平臺功能設(shè)計與業(yè)務(wù)上云思考傳統(tǒng)企業(yè)的應(yīng)用架構(gòu)與應(yīng)用分類SAN存儲：包括高、低、中不同的存儲，存儲中磁盤的RAID配置、存儲池配置、存儲的集群配置、存儲的容災(zāi)備份、數(shù)據(jù)的熱點遷移、數(shù)據(jù)的緩存、存儲之間的SAN交換機配置（劃分Zoning，連接主機）等都需要專業(yè)的存儲工程師（衍生出來了很多的認證），這種存儲可以做到高IOPS、低延遲、高可靠性，是目前大多數(shù)的分布式存儲難以匹敵的，且目前存儲廠商在SAN上也做到了虛擬化；傳統(tǒng)企業(yè)的應(yīng)用架構(gòu)與應(yīng)用分類主機：小型機、x86服務(wù)器，小型機以IBM小型機為例，小型機虛擬化比x86虛擬化出現(xiàn)的年代早了幾十年，當時是硬分區(qū)技術(shù)，后來發(fā)展到邏輯分區(qū)+IO虛擬化，邏輯分區(qū)可以做到分配0.1個CPU的細粒度，同時也在2007年就推出了類似于容器的技術(shù)，做到了進程級別的隔離，但因為不開源、不方便打包、鏡像管理沒有Docker方便，最終只在少數(shù)客戶處進行了部署使用；傳統(tǒng)企業(yè)的應(yīng)用架構(gòu)與應(yīng)用分類APP：以IBMWebSphere為例，十年之前就有WAS集群的概念，可以部分做到橫向擴展。傳統(tǒng)企業(yè)的應(yīng)用架構(gòu)與應(yīng)用分類傳統(tǒng)企業(yè)的應(yīng)用云化改造需求OLTP類應(yīng)用云化的要求云化關(guān)鍵點1：系統(tǒng)彈性伸縮通過應(yīng)用與數(shù)據(jù)分離和集群化部署，實現(xiàn)系統(tǒng)快速擴容、處理能力靈活水平線性擴展、故障自動隔離。對于獨立的應(yīng)用主機可以進行靈活彈性伸縮。彈性伸縮特點：在線快速擴容：系統(tǒng)擴容操作低耗時、無數(shù)據(jù)遷移、服務(wù)不間斷；處理能力線性擴展：系統(tǒng)處理能力可以通過新增節(jié)點近線性提升，實現(xiàn)高吞吐、高并發(fā)處理能力，應(yīng)對業(yè)務(wù)爆發(fā)式增長；故障自動接管：集群可以自動發(fā)現(xiàn)故障節(jié)點并調(diào)整任務(wù)調(diào)度策略，在不影響處理的同時接管故障節(jié)點，保持系統(tǒng)高可用。云化關(guān)鍵點2：應(yīng)用集群化部署將緊密耦合的大應(yīng)用模塊化拆分為多個模塊化小應(yīng)用，通過資源池提供系統(tǒng)資源的整體利用率，并將拆分后的子模塊部署于資源池（后來我們搞Docker的稱之為微服務(wù)化）。當硬件資源實施池化后，才具備了支撐應(yīng)用的彈性伸縮，實現(xiàn)硬件的按需分配的基本需求，充分提高資源利用率。云化關(guān)鍵點3：通過數(shù)據(jù)分級分類實現(xiàn)應(yīng)用與數(shù)據(jù)分離根據(jù)數(shù)據(jù)實時性、重要性、敏感性等因素，將數(shù)據(jù)分成數(shù)個級別，各個級別的數(shù)據(jù)對系統(tǒng)的作用、采用存儲、保護方式也都有所不同位置無關(guān)性：數(shù)據(jù)在遠程還是本地存儲，對應(yīng)用最好透明。分布無關(guān)性：數(shù)據(jù)分布在多個數(shù)據(jù)節(jié)點，對應(yīng)用透明。比如查詢某個客戶的所有相關(guān)數(shù)據(jù)，雖然同一個用戶信息分布在多個數(shù)據(jù)節(jié)點上，但對應(yīng)用來說就好像一個集中數(shù)據(jù)庫進行查詢。存儲無關(guān)性：數(shù)據(jù)存儲在內(nèi)存庫、物理庫（關(guān)系型數(shù)據(jù)庫、NoSQL數(shù)據(jù)庫）、File還是緩存等介質(zhì)，對應(yīng)用透明。云化關(guān)鍵點4：合理規(guī)劃實現(xiàn)數(shù)據(jù)分布式部署對不同業(yè)務(wù)的數(shù)據(jù)、不同類型的數(shù)據(jù)進行有效規(guī)劃部署。通過某種特定的條件，將存放在同一個數(shù)據(jù)庫中的數(shù)據(jù)分散存放到多個數(shù)據(jù)庫上，實現(xiàn)數(shù)據(jù)分布存儲，通過路由規(guī)則路由訪問特定的數(shù)據(jù)庫。數(shù)據(jù)庫拆分方式包括：垂直（縱向）拆分：將數(shù)據(jù)庫表按業(yè)務(wù)、功能拆分到不同的數(shù)據(jù)庫表，比如分為客戶資料庫、訂單庫、資源庫、資料庫等，這種方式多個數(shù)據(jù)庫之間的表結(jié)構(gòu)不同；目的是降低業(yè)務(wù)之間的影響，減少系統(tǒng)承載壓力。水平（橫向）拆分：將同一個表的數(shù)據(jù)進行分塊保存到不同的數(shù)據(jù)表中，這些數(shù)據(jù)庫中的表結(jié)構(gòu)完全相同。云化關(guān)鍵點5：數(shù)據(jù)平臺化數(shù)據(jù)平臺化是指通過應(yīng)用架構(gòu)和數(shù)據(jù)架構(gòu)的重新梳理、規(guī)劃與調(diào)整，將業(yè)務(wù)處理中的業(yè)務(wù)數(shù)據(jù)和狀態(tài)數(shù)據(jù)與應(yīng)用分離，實現(xiàn)應(yīng)用的輕量化、無狀態(tài)；構(gòu)建統(tǒng)一的數(shù)據(jù)訪問層，實現(xiàn)數(shù)據(jù)的共享訪問。數(shù)據(jù)平臺化是數(shù)據(jù)處理水平線性擴展的前提和基礎(chǔ)。數(shù)據(jù)平臺化特點：應(yīng)用輕量化：縮短開發(fā)周期，提升新業(yè)務(wù)響應(yīng)速度；應(yīng)用無狀態(tài)：實現(xiàn)應(yīng)用的同質(zhì)化，應(yīng)用層處理能力的獨立擴展，實現(xiàn)應(yīng)用靈活調(diào)度和分配；數(shù)據(jù)共享訪問：逐步實現(xiàn)數(shù)據(jù)集中訪問，跨地市的流量共享、流量統(tǒng)付、流量轉(zhuǎn)移業(yè)務(wù)能夠更高效支撐。OLAP型應(yīng)用云化的需求OLAP型應(yīng)用云化的需求這種架構(gòu)以處理結(jié)構(gòu)化數(shù)據(jù)為主，基本部署于Oracle、小型機、SAN存儲之上，擴展性不足，難以處理海量數(shù)據(jù)。大數(shù)據(jù)處理技術(shù)的興起讓這類應(yīng)用的云化找到了思路。云化時總體推薦混搭架構(gòu)，即采用多種技術(shù)架構(gòu)建設(shè)大數(shù)據(jù)中心：垂直混搭架構(gòu)OLAP型應(yīng)用云化的需求水平混搭架構(gòu)OLAP型應(yīng)用云化的需求企業(yè)級數(shù)據(jù)云平臺：逐漸實現(xiàn)企業(yè)內(nèi)數(shù)據(jù)的統(tǒng)一存儲，承載數(shù)據(jù)的加工計算；未來提供企業(yè)數(shù)據(jù)的統(tǒng)一存儲和計算能力；數(shù)據(jù)倉庫、集市和挖掘庫：計算逐漸遷移到云平臺實現(xiàn)輕載化；直接從云平臺加載應(yīng)用結(jié)果數(shù)據(jù)，實現(xiàn)上層應(yīng)用的兼容性；流處理平臺：實時計算結(jié)果存儲到云數(shù)據(jù)平臺，可通過能力開放平臺的消息中間件直接供應(yīng)用訪問。OLAP型應(yīng)用云化的需求OLAP云化關(guān)鍵點1：數(shù)據(jù)計算引擎開源化M/R計算引擎：用HDFS文件保證每一步計算結(jié)果，避免硬件故障導(dǎo)致重頭執(zhí)行。優(yōu)點：可靠性高；缺點：數(shù)據(jù)處理任務(wù)是一系列M/R任務(wù)的串行執(zhí)行，輸入和輸出都是HDFS文件，導(dǎo)致頻繁的磁盤I/O，執(zhí)行速度慢；局限性：原始單一的編程模型和數(shù)據(jù)結(jié)構(gòu)，導(dǎo)致開發(fā)效率低，限制更多應(yīng)用的產(chǎn)生。OLAP型應(yīng)用云化的需求OLAP云化建設(shè)關(guān)鍵點2：數(shù)據(jù)集市云化建設(shè)建設(shè)現(xiàn)狀：傳統(tǒng)小機+Oracle數(shù)據(jù)庫和新建的MPP數(shù)據(jù)庫兩種建設(shè)模式。演進策略一：用MPP數(shù)據(jù)庫來取代小機+Oracle數(shù)據(jù)庫；演進策略二：用數(shù)據(jù)云平臺+開源MYSQL/PGSQL集群來代替小機+Oracle數(shù)據(jù)庫。OLAP型應(yīng)用云化的需求數(shù)據(jù)云平臺完成所有的后臺計算。OLAP型應(yīng)用云化的需求OLAP云化關(guān)鍵點3：數(shù)據(jù)ETL云化建設(shè)傳輸?shù)膶崟r化：支持MQ等分布式實時消息傳輸機制；基于內(nèi)存的計算：數(shù)據(jù)不落地，避免海量數(shù)據(jù)的兩次重復(fù)加載；計算的輕量化：清單級的過濾、排重、規(guī)則化，更多的計算任務(wù)由大數(shù)據(jù)存儲和計算平臺來完成；分布式并行執(zhí)行：高可用性、分布式調(diào)度、資源分配；技術(shù)實現(xiàn)：Kafka+HDFS+MR/Spark?；谌萜鞯腜aaS平臺架構(gòu)的構(gòu)建基于此架構(gòu)有以下幾個主要問題：可以實現(xiàn)應(yīng)用編排與部署，但是編排的基礎(chǔ)單元是虛擬機模板，模板比較重，而且鏡像很難修改，編排、分發(fā)、運行、持續(xù)集成等都有很大的困難，因此構(gòu)建在模板上的應(yīng)用形成的服務(wù)很難用；基于虛擬機的彈性伸縮相應(yīng)時間也比較慢，我們嘗試做過基于Cloudwatch+Autoscaling的虛擬機彈性伸縮功能，發(fā)現(xiàn)彈性伸縮對業(yè)務(wù)的響應(yīng)時間有一個偏差，這個偏差大約在十幾分鐘，在搶購、秒殺等業(yè)務(wù)中基本不可接受；很難在企業(yè)內(nèi)部形成一個統(tǒng)一的私有云集群來同時運行這兩類業(yè)務(wù)，因此兩個PAAS集群實際上是兩個獨立的集群，都是按照業(yè)務(wù)最高峰配置，存在資源浪費的現(xiàn)象，運維也是分開運維。新一代PaaS平臺新一代PaaS平臺使用容器+容器鏡像管理替代服務(wù)目錄管理+虛擬機模板管理。在InstancePaaS（iPaaS）平臺上除了基于Kubernetes的容器管理、鏡像管理、應(yīng)用管理等功能，還構(gòu)建了如下子系統(tǒng)：日志子系統(tǒng)：基于ELK實現(xiàn)；計算子系統(tǒng)：集成OpenStack與自研的SkyformCMP；存儲子系統(tǒng)：通過Cinder，支持ISCSI、NFS、Ceph三類存儲，與IaaS打通；網(wǎng)絡(luò)子系統(tǒng)：我們選用了Netron+OVS的SDN解決方案；監(jiān)控子系統(tǒng)：通過Ceilometer+MongoDB進行實施數(shù)據(jù)的監(jiān)控、Phoenix+Hadoop進行歷史數(shù)據(jù)分析；用戶交互子系統(tǒng)：基于Node.js開發(fā)。整體的PaaS平臺構(gòu)建基于Kubernetes、Hadoop、SparkonMesos，構(gòu)建完整的DCOS平臺。需要說明的是，在傳統(tǒng)企業(yè)在云平臺還需要對接大量的系統(tǒng)，比如ITIL、4A/3A、人力資源系統(tǒng)、審計系統(tǒng)等PaaS平臺對傳統(tǒng)應(yīng)用云化關(guān)鍵點的解決針對OLTP類應(yīng)用云化的5個關(guān)鍵點的解決：系統(tǒng)彈性伸縮：通過KubernetesRC+service實現(xiàn)；應(yīng)用集群化部署：通過Mesos/Kubernetes構(gòu)建x86集群，將應(yīng)用分布式改造以后部署與集群；通過數(shù)據(jù)分級分類實現(xiàn)應(yīng)用與數(shù)據(jù)分離：通過BigdataPaaS的HDFS服務(wù)與InstancePaaS的DB服務(wù)可以提供部分數(shù)據(jù)分級服務(wù)的基礎(chǔ)，但是數(shù)據(jù)分級與存儲，以及訪問透明性未能完全實現(xiàn)，需要在業(yè)務(wù)層面進行適配；合理規(guī)劃實現(xiàn)數(shù)據(jù)分布式部署：通過在InstancePaaS提供數(shù)據(jù)庫服務(wù)，以及開開源數(shù)據(jù)路由服務(wù)，實現(xiàn)，注：需要DBA規(guī)劃數(shù)據(jù)的存儲；數(shù)據(jù)平臺化：應(yīng)用改造后即可實現(xiàn)。OLAP云化的3個關(guān)鍵點的解決數(shù)據(jù)計算引擎開源化：可由BigdataPAAS直接提供MR、Spark服務(wù)；數(shù)據(jù)集市云化建設(shè)：可由InstancePaaS平臺提供開源MySQL+TDDL實現(xiàn)；數(shù)據(jù)ETL云化建設(shè)：可由InstancePaaS提供Kafka、BigdataPaaS提供MR、SPARK實現(xiàn)。PaaS平臺問題及傳統(tǒng)應(yīng)用上云改造的一些注意點基于Kubernetes、Hadoop、SparkonMesos的問題這種調(diào)度實際上是兩級的調(diào)度框架，Mesos本身只管資源（主要是CPU與MEM），提供offer給上層的調(diào)度框架使用。一級調(diào)度即Mesos層有兩種調(diào)度模式：Mesos粗粒度，這種模式下，一旦一臺機器（一個Node）分配給某個框架，其他框架便不能使用；Mesos細粒度，這種模式下，多個框架可以共享一臺機器（一個Node）。PaaS平臺問題及傳統(tǒng)應(yīng)用上云改造的一些注意點粗粒度存在資源還是不能完全共享的問題，因此仍然有資源浪費的問題，細粒度模式可以改變這種問題，但是又帶來新的問題：Mesos集群運行多種框架，包括Spark，也運行著很多Web、中間件、數(shù)據(jù)庫等服務(wù)，但是Mesos不支持搶占，無法設(shè)置任務(wù)優(yōu)先級，而Spark默認是貪婪模式，這樣就會出現(xiàn)Spark運行時無法發(fā)布其他Web任務(wù)到Mesos集群上的情況。Hadoop與Spark在運行時，Shuffle階段數(shù)據(jù)會交互寫HDFS磁盤，這時網(wǎng)絡(luò)資源會被大量占用（我們稱之為東西向流量），導(dǎo)致Web服務(wù)基本不能響應(yīng)（我們稱之為南北向流量）。

多租戶的問題目前多個框架之間每個都有自己的用戶管理模式，默認情況下，如果多個框架之間有交叉使用，需要在多個框架之間租戶互相打通，涉及到Mesos、Hadoop、Kubernetes的賬號打通問題，需要開發(fā)獨立的賬戶中心，并且完成同步。多租戶的問題應(yīng)用最好無狀態(tài)，無狀態(tài)化的應(yīng)用天生適合上云。這時服務(wù)的注冊于發(fā)現(xiàn)、應(yīng)用的彈性伸縮完全交給云平臺來做，比如Mesos+Marathon的HAProxy+etcd+Confd或者Kubernetes8s的service+RC；已經(jīng)集群化的應(yīng)用組件部署相對困難，比如基于PaaS平臺發(fā)布單個實例的Redis容器，但是發(fā)布Redis集群就比較困難，苦難就困難在Redis集群中的節(jié)點需要相互通信，而容器如果重啟或者IP發(fā)生變化都會對集群造成影響；服務(wù)注冊與發(fā)現(xiàn)如果應(yīng)用本身提供了，PaaS平臺的服務(wù)注冊與發(fā)現(xiàn)功能便不能使用，不能兩套服務(wù)注冊與發(fā)現(xiàn)同時使用。應(yīng)用上云上圖左邊是某傳統(tǒng)企業(yè)電商應(yīng)用最初架構(gòu)，Web部署于一臺高配置x86服務(wù)器、APP部署于一臺中端小型機、DB部署于一臺中端小型機，右邊是初步進行了改造后的架構(gòu)，即遷移到PaaS平臺之前應(yīng)用已經(jīng)做了模塊化與集群化的初步改造：應(yīng)用上云前臺用負載均衡將流量引入到三個Web節(jié)點中，每個Web節(jié)點部署于x86服務(wù)器，Session集中存在Redis集群（無狀態(tài)化改造，交互用HTTP+JSON短連接）；APP層也通過Redis集中存放狀態(tài)信息，做到了無狀態(tài)化，每個APP節(jié)點部署于三臺x86服務(wù)器；Web與APP在流量大的時候可以做到手動擴容，但是需要配置固定的IP，APP服務(wù)（提供給）的注冊發(fā)現(xiàn)是基于ZooKeeper完成（應(yīng)用自己來完成服務(wù)注冊于發(fā)現(xiàn)）；DB層做了主從數(shù)據(jù)庫，部署與x86服務(wù)器。應(yīng)用上云該應(yīng)用里面還用到了Kafka，用來做數(shù)據(jù)總線，也采取了集群化部署。應(yīng)用上云針對目前的現(xiàn)狀，如上圖，應(yīng)用遷移到PaaS平臺需要做三方面的工作：完成Web層的服務(wù)注冊與發(fā)現(xiàn)，在此基礎(chǔ)上實現(xiàn)web層的自動擴縮容，此處基于Kubernetes的ingressservice（一個改造后的Nginx，運行在一個Kubernetes的POD里面）實現(xiàn)軟負載+RC控制節(jié)點伸縮實現(xiàn)（每個Web部署于一個pod）；APP層的自動擴縮容，由于已經(jīng)完成了基于ZooKeeper的服務(wù)注冊于發(fā)現(xiàn)，所以只需APP層能夠彈性伸縮部署即可；此處基于RC控制節(jié)點伸縮實現(xiàn)；DB層由于運行穩(wěn)定，暫時不做PaaS化但是，基于訪問路由做到分布式部署。中間件Redis集群、ZooKeeper集群、Kafka集群（用作消息總線）要不要做PaaS化？如何做？主要是這些集群節(jié)點之間的互相通信與數(shù)據(jù)傳輸即東西向流量，要求這些節(jié)點之間的