需求開發應用部署「一條龍」，平安雲如何加速容器場景落地

2019年6月20日，由Rancher Labs（如下簡稱Rancher）主辦的第三屆企業容器創新大會（Enterprise Container Innovation Conference, 如下簡稱ECIC）在北京喜來登大酒店盛大舉行。本屆ECIC規模宏大，全天共設置了17場主題演講，吸引了近千名容器技術愛好者參加，超過10000名觀衆在線上直播平臺觀看了本次盛會。

來自Rancher、阿里雲、百度雲、平安科技、中國聯通、飛貸金融科技、中國人壽、SmartX、華泰保險、廈門航空、JFrog、新東方、Cisco等近20家企業的技術負責人出席了本屆ECIC，在大會現場帶來了關於企業容器項目實踐經驗的精彩分享。

大會現場，平安科技CTO及總架構師方國偉提出，近年來在雲計算賽道上，容器由於它輕量、靈活、易管理、易遷移等特性被企業普遍採用，如一輛高速前進的方程式賽車脫穎而出，成爲了企業雲化歷程中的大勢所趨。在將來3年，平安雲將會重點投入容器建設，解決容器快速交付的難題，而且進行微服務的支撐。

如下是平安科技CTO及總架構師方國偉的演講實錄：

你們上午好！謝謝梁勝博士，謝謝Rancher邀請咱們在企業容器創新大會上分享。

先和你們介紹一下平安科技的容器應用狀況，咱們從2014年開始關注容器技術，2015年開始構建容器相關的產品，也從2015年開始和Rancher接觸以及合做，是Rancher在國內最先合做的企業之一。剛纔梁勝博士在介紹Rancher產品的時候，提到了平安雲支持容器服務，能夠經過Rancher進行多集羣管理。

平安雲對外提供「2+1」的雲服務。公有云和其餘公有云平臺是同樣的，對外提供服務，用戶本身註冊，審覈以後變成平安雲的客戶，這就是公有云。第二部分是專有云，專有云和平安總體發展領域有比較大的關係，平安集團專一於五個生態圈，金融、醫療、智慧城市、汽車和房地產，咱們針對各個垂直領域創建獨立的物理隔離的雲平臺，這就是咱們的專有云。

公有云和專有云在技術架構上基本上是同樣的，區別在部署、安全隔離和法規徵信方面。好比金融雲，央行會有專門的金融雲的認證規範，專有云平臺要知足這個規範以後才能夠將本身稱做爲金融雲。

「2+1」中的2，一個是公有云，另外一個是專有云，專有云按不一樣行業劃分，政府客戶基本上就會將應用部署在政務雲上。那「2+1」中的1就是私有云，國內大企業比較傾向於在本身的數據中心內部署私有云平臺，平安則爲他們提供解決方案，讓客戶在本身的數據中內心構建和平安專有云、公有云相似的雲平臺。

私有云總體架構和公有云、專有云相似，區別在私有云在產品上面公有云的子集，絕大部分客戶並不須要一個特別複雜的雲平臺在企業內部運行。

平安雲和其餘雲的區別在哪裏？咱們最大的區別在於咱們對外提供Full Stack（全棧服務），在咱們前面提到的五個生態圈領域，每一個生態圈領域有專門的公司構建SaaS服務。有些雲平臺廠商不提供應用，有些雲平臺廠商上不碰應用，可是下不碰數據等本身的市場策略。

平安總體的戰略思路在於咱們總體業務層面能力比較強，咱們有大量SaaS應用，好比一帳通，這是一款針對金融領域的SaaS平臺，咱們對外提供的服務Full Stack從底下的IaaS、PaaS到上面的SaaS，以總體的形式爲客戶提供解決方案。容器在這裏面的角色就很是重要了，由於容器能夠跨平臺，在私有云和專有云上咱們能夠進行多雲管理，這些都是容器在當中的價值。

接下來，我會講一下咱們怎麼看到容器在雲平臺內的做用以及咱們作的一些事情。前面也提到，咱們從2014年開始關注容器，2015年開始容器相關的產品，當中很重要的緣由就是咱們以爲容器能夠改變雲計算的多個方面，尤爲是在計算服務提供方式上。我列舉了一些容器的特色，它更加靈活，也能夠和底層資源進行耦合。

這裏面有一個很是值得思考的問題，就是爲何谷歌會花費這麼大力去作Kubernetes？而且在整個開源界去推廣這個事情？我以爲最重要緣由是谷歌總體在雲上落後於像AWS這樣的雲廠商的，可是AWS最重要的服務是計算服務或者是它大部分的收入都與計算相關，它的計算服務是基於虛擬化的雲主機來進行的。谷歌做爲一個後來者，要想辦法追趕AWS，若是仍是傳統的模式，追遇上的可能性就很小了。若是谷歌要追遇上AWS的話，它必定要改變遊戲規則，容器能夠幫助它，容器不必定可以超越，但這是一個很好的機會。

對於平安雲來說，咱們很是看重容器也是基於相似的緣由。咱們相信在幾年以後，愈來愈多的應用會變得Cloud Native，愈來愈多的用戶會採用像微服務、Istio這樣的方式來進行部署，容器能夠很快地知足客戶部署上的要求。這就是爲何咱們花不少力氣在容器服務上，用Kubernetes來構建產品的緣由，這是大的背景。

平安雲在容器部署方面是怎樣的呢？咱們是牢牢圍繞客戶的需求來構建產品的。在梁勝博士演講的時候也提到，咱們實際使用容器的時候，用Docker或者是Kubernetes仍是會產生一些問題的。不一樣的客戶需求不同，有些開發人員對Docker和Kubernetes很熟悉，他能夠輕鬆地管理本身的Kubernetes集羣。也有一些開發人員不太喜歡底下的pod、端口等，他以爲只須要了解業務需求，寫代碼就能夠了，無需關心底下容器相關的事情。因此不一樣的開發人員、不一樣客戶對象需求是不同的。

咱們在平安雲上提供了不一樣級別容器相關的服務，最底層毫無疑問的是I層的一些服務，從底向上咱們會有Kubernetes集羣，叫EKS，其上面咱們會有Container Service，再往上咱們會有PaaS平臺，最上面是DevOps服務。這就是平安雲上容器相關的幾大服務。

EKS概念上很簡單，這是一個Kubernetes管理服務，梁勝博士也提到，不管咱們在公有云仍是私有云上，咱們都部署一個Kubernetes，固然你能夠利用雲主機本身去部署一個Kubernetes，可是雲上面提供原生的EKS服務，它與雲上面的資源，不管是底下的各類資源仍是上面的像日誌服務、監控服務等，均可以比較快速地經過API把服務利用起來。對Kubernetes比較瞭解的開發人員或者是運維人員而言EKS是一個比較好的選擇，Kubernetes的API徹底同樣，若是他喜歡用Kubernetes命令來管理K8S服務也是徹底同樣的，相對而言比本身去安裝一個Kubernetes簡單一些。這是第一類基於Docker、Kubernetes的服務，你能夠快速拿到K8S集羣，構建本身的容器服務。

第二個產品咱們叫作Container Service，對於不少用戶來說，他不想關心Kubernetes，也不想成爲一個Kubernetes專家，他想拿到一個Container，經過Container去部署他的應用。對於這一類客戶來說，咱們提供Container as a Service即CaaS服務。你不用關心底下Kubernetes的東西，由平安雲的後臺服務和運營團隊幫你管理集羣。你拿到不一樣Container，就在上面直接部署應用。固然咱們也會管理相關的鏡像市場，提供快速的鏡像上傳、下載、推拉等，也會應用編排一些功能，對客戶來說就是Container as a Service。

咱們內部在底下換過幾回Container Service的技術，如今用的是Kubernetes，這些對客戶來講都是透明的。由於客戶關心的是Container，拿到的也是Container，底下你用什麼樣的方式來作編排他都是能夠接受的。咱們之前用過Mesos，後面把Mesos換成了Kubernetes，這對用戶來講也是無所謂的，因此這裏面最大的區別在於用戶關注的是Container，他不關心編排，這是咱們一個第二層級的，對不須要關心Kubernetes的用戶來說，他可使用CaaS服務來進行應用部署。

第三類服務就是我連容器都不想管理，有沒有這樣的服務呢？正如梁勝博士在前面提到的，他講的是Rio，他們想構建一個MicroPaaS平臺。這個有點像是平安雲構建的PaaS服務，咱們目前的產品叫作APaaS，APaaS的概念來自於Gartner，Gartner不少年前有份報告是分析平臺層Platform Service裏面到底有哪幾類服務，它當時就把PaaS分爲兩大類，一類叫作APaaS，一類叫作IPaaS。APaaS就是咱們這邊在作的，IPaaS是APaaS以外的一些集成服務好比MQ、認證等。這些服務都是平臺層的，它統一放在IPaaS裏面。剛纔梁勝博士講的Rancher作的是一個微小的Micro Platform Rio。我最初在微軟作Windows Azure，一開始定位在Platform Service，後來發現Platform Service有些問題，後來轉到VM從新進入IaaS跟Amazon AWS是同樣的。

這是我本身在工做這麼多年的體會，爲何APaaS之前不太成功呢？緣由在於APaaS構建方都是作技術架構的人，這其實是一個很大的誤區。APaaS真正的用戶對象是開發人員，在構建APaaS的時候，若是有開發人員參與的話，構建的成功率會高一些。由於他知道本身的痛點，知道本身想要什麼，而不是運維人員、底下技術架構人員拍腦殼構建一個Platform Service。因此平安構建APaaS，咱們是由應用架構團隊牽頭構建一個APaaS，目的在於在你部署應用的過程當中，你無須關心Container，你只關心代碼，經過代碼能夠在APaaS平臺上進行部署，快速創建應用程序的部署。好處在於進一步下降容器相關服務的使用門檻。

容器咱們是2014年開始關注的，如今已通過去了好多年，雖然咱們都知道容器應該是指數型發展，但實際上容器總體的發展並無咱們預期的快。當時我認爲容器確定能夠快速替換大部分的雲主機，但實際上這件事情沒有發生。未來容器發展速度確定很是快，但如今來講，它沒有咱們預期快速增加的緣由是由於在容器的使用上對於開發者而言過於複雜，咱們但願經過APaaS平臺，進一步下降使用門檻，底下容器更透明一些，讓開發人員無需過多關心容器自己的細節。

這一目標應該是能夠作到的，最開始咱們想在Windows上構建一個Platform Service，當時沒有Container，它是基於VM來構建的，這也沒有問題，它只須要一個快速的資源分配力度和分配的機制，就能夠實現了。在使用容器以後，咱們如今回過頭來作APaaS，我以爲成功率會大大提高。

在作APaaS的時候，一個很是重要的問題在於對應用自己的服務的管理，對應用管理，對微服務自己的管理，包括對應用配置管理，這是不少時候作底層基礎架構技術的人不容易看到的事情。若是咱們作底下架構的服務構建的時候，你們會想到CMDB，CMDB能夠管理技術架構的不少配置，可是若是你把應用部署起來以後，它也須要應用配置來把應用服務管理起來。這就是在APaaS構建裏面很是重要的一個環節。只有把應用配置相關的事情構建好了，整個APaaS、整個應用發佈流程纔會比較順暢地構建起來。這是咱們構建的第三個層次APaaS。

接下來的PAME也是一個平臺層的服務，這個平臺層的服務在過去一兩年也是很是重要的服務。最近一兩年人工智能很是熱，人工智能內有大量的機器學習、深度學習的需求。機器學習、深度學習須要大量的GPU，GPU在這方面作得效果還不錯，固然若是有專門針對人工智能的芯片也是很是的好，但目前使用比較多的仍是GPU的方式。爲了解決大量數據訓練的需求以及一些推理的需求，咱們構建了一個PAME平臺。

PAME平臺和容器的關係在於它的資源分配是基於容器來進行的，底下是CaaS容器服務，容器服務底下的硬件上面有GPU支持，因此咱們構建了PAME平臺來簡化機器學習使用。除了計算資源以外，在深度學習平臺上，很是重要的一點在於怎樣去管理數據，這是很是重要的。深度訓練的數據從哪裏來、怎麼存儲、怎麼進來？模型導進來以後怎麼去管理？這一切都是PAME須要解決的問題，因此PAME自己的定位也是PaaS的一種，它不是APaaS平臺，它是在平臺層的另一類服務，跟容器有緊密集成的一類服務，叫機器學習平臺。

機器學習平臺的原理很簡單，前面咱們講EKS的時候，裏面是個Manage EKS Service。在PAME裏面，用戶能夠選擇不一樣的學習框架，若是用戶有Tensorflow，我給他快速構建一個 Tensorflow平臺，他能夠學習，至關於咱們能夠快速把機器學習框架包裝起來，同時加上在機器學習裏面須要用到的數據導入導出模型管理這樣的一些需求整合在一塊兒，做爲服務提供給客戶。

對於用戶來說，不用像之前給GPU的服務器或者GPU的雲主機，這些東西申請以後比較龐大。PAME是基於容器的，因此資源用完了，你就能夠關掉退出，資源消耗收費就是雲計算的pay as you go。這就是咱們的第四個服務，叫作PAME服務。

咱們構建了不少服務，但不管是APaaS也好、PAME也好，咱們的目標仍是在上面部署應用，應用自己的管理須要CI/CD平臺、DevOps平臺來作這個事情。咱們構建了神兵研發管理平臺，這至關於平安的CI/CD和DevOps平臺。

這個平臺有幾個特色，第一就是在總體的項目管理週期裏面，從項目管理到代碼管理，到需求故事，測試、版本迭代、敏捷看板全部這些功能都集中在一個產品裏面。這是從研發管理流程上看，它能夠部署到前面的咱們講到的平臺，不管是CaaS仍是APaaS也好，都是打通的。

第二個就是在全部的環節裏面，咱們從研發管理的角度來說，你有流程嗎？好比說要不要通過一些測試，要不要掃描，像這一類的內容咱們直接就加入到流程裏面，該作鏡像掃描就作鏡像掃描，該作安全掃描就作安全掃描，該作測試就測試。好處是什麼？就是咱們公司全部研發過程都能看的很是清楚，這個系統在咱們集團內部月活超過26000。

咱們有一個數據平臺，咱們重點增強了這部分的內容，不少企業不知道研發人員的產出是怎樣的，我相信不少作研發管理的人都會有這樣的困惑，你不知道人員的產出是怎樣的，你也不知道假設一個部門須要擴編了，申請的10個額外編制是應該給仍是不給，甚至你不知道他的開發效率是怎樣的。

咱們但願作的是基於數據的管理。平安近幾年來一直強調基於數據驅動的管理，因此咱們從研發管理的角度提供了一個數據平臺，能夠很是清楚的看到每一個研發人員遞交了多少代碼？代碼的質量怎樣？全部這些都是有數據的，能幫助你提高整個研發管理。不只僅關注他的效率，還能夠關注代碼質量，員工的工做狀況等等。每一個需求從提出到上線，總體的迭代時間多長，開發人員的工做狀況等等，這些均可以從一個平臺很是好的反饋出來。這是從神兵的角度、研發管理角度能夠看到的。

除此以外，咱們還作了一個微服務框架，光有容器還不夠，你還得有運行的東西，如今比較流行用微服務的方式構建應用平臺。咱們在雲上專門作了一個框架PAFA-CLOUD，它是平安總體框架的方式。咱們以前有PAFA-1，PAFA-2到PAFA-5，這個版本咱們不叫PAFA-6了，直接命名爲PAFA-CLOUD。緣由在於咱們專門以Cloud Native的方式構建這一框架。

那麼，它的基本概念是怎樣的呢？在企業內部，個人團隊大部分開發的應用都是底層技術框架的應用，可是對大部分公司來說，它的開發人員都是依賴業務來作開發的。咱們知道，業務應用開發人員關注的點不徹底在技術上面，更多的仍是集中在業務邏輯上。因此大部分開發人員時間都放到怎樣把業務需求分集成業務邏輯，而後依靠代碼來實現。他也不須要花太多時間進行用戶認證、日誌歸結、收集等等，咱們但願他花在這上面的時間越少越好。

這是咱們總體框架的圖，咱們徹底基於Spring Cloud，而後加了不少定製的內容。上面有API網關，底下有服務治理平臺，最下面是基礎設施。不管是CaaS也好，仍是DH、ECS、BMS，這些都是底層資源。對用戶來說，他只須要關注業務服務就行了。像分佈事務、灰度發佈、分佈調度，每一個應用、每一個項目都須要作的事情，咱們都須要經過框架的方式來實現，大大下降了每一個項目組開發時的非業務負擔，提高了業務應用的開發效率。

還有一方面是和PAFA相關聯的事情。好比說你有神兵，日誌有日誌雲、消息有消息雲，這些東西在裏面作了不少對接。這代表什麼呢？咱們在企業裏邊若是要逐漸構建，你們如今都很熱衷於講中臺的概念，那在PAFA裏面就能夠慢慢地把共享的服務作起來，你的應用開發就會變得愈來愈快，你能夠依賴的服務愈來愈多，你不須要每一個服務、每一個項目都本身作，若是每一個項目都是從新造輪子，這樣你的效率就會大大下降。

咱們總體的理念是怎樣的呢？咱們那總體的理念就是但願行成一條龍的方式，實現把應用開發、流程進行總體管理。一條龍的意思就是，若是你要從業務寫代碼開始，我爲你提供一個整套的框架。你須要去開發，去測試，去部署，咱們就有神兵DevOps平臺來作這個事情。部署到容器、雲主機等等底下的相關資源，你能夠選擇APaaS，也能夠選擇容器相關的服務來部署你的應用。

這樣一連串的流程，咱們把它叫作一條龍流程。咱們照顧到了從應用架構設計開始、到開發測試、到部署相關的這一切。這是咱們在平安推的一條龍流程，能夠極大地提高整個應用開發效率。

咱們過去幾年從各個層面上和Rancher都有比較多的合做，在這裏分享的是與Rancher聯合探索應用容器化實踐。咱們知道，在以前的大部分應用都不是用容器方式去構建的。Rancher在容器方面作得比較領先，並且一直很是專一地作容器相關的事情。咱們和Rancher合做，把大部分咱們內部經常使用的服務進行容器化包裝、打包，能夠做爲服務化部署。不管是基於Helm仍是基於Operator的方式，把它構建成不一樣的服務。

咱們認爲這是未來很是重要的趨勢。公有云上，你能夠用去虛擬化的雲主機運行容器，另外一方面，咱們也作安全容器，容器下面加一個很薄的虛擬化層進行隔離等等。按照這個趨勢看，愈來愈多的隔離應用會以容器的方式運行。這就是爲何咱們和Rancher合做，針對經常使用的服務進行服務化改造，方便用戶快速地獲取服務。雲上的服務很是多，有些服務是雲平臺上直接提供服務建設的，有一些經過Managed Service提供，還有一些人經過容器化的方式來實現。

最後要分享的是咱們對容器自己的判斷。從一開始的時候咱們分析容器的原由，谷歌之因此要花很大力氣作Kubernetes，我相信它是想對AWS發起衝擊，經過改變遊戲規則來實現彎道超車。咱們也看到愈來愈多的應用Cloud Native方向發展。咱們認爲，這個事情對平安雲的向前推動是很是有好處的，因此咱們願意花不少力氣、投入不少資源在容器方面，包括容器延伸上來作一些事情。

除了咱們傳統的雲上服務以外，咱們如今作的另一些事情跟容器的關係也很是密切。好比物聯網，剛纔梁勝博士說起物聯網在IOT裏面，它並不只僅是簡單的端到雲，中間還涉及邊緣。尤爲是未來5G愈來愈多，設備愈來愈多，雲上的性能愈來愈好，整條鏈從端到邊緣到雲上，容器的做用會愈來愈大。

爲何呢？由於咱們不但願是從端到邊緣到雲上面，它的部署模型是不同的，或者運行環境的差別性很大。容器天生有一個很是好的特性，它底下是鬆耦合的，或者它解耦比較好。這個特性在咱們構建整套體系的時候，從端到邊緣到雲體系當中，使整個Programing Model相對比較統一。好比大邊緣上，我用Kubernetes，小邊緣上，我用K3S。你們都是在整個體系裏面，應用能夠在不一樣的點切換，固然你們知道,小邊緣它更靠近Devices，大邊緣它更靠近Cloud。

咱們在區塊鏈上尤爲是平安的壹帳鏈上作得挺不錯的，在部署的過程當中，咱們也是基於容器實現的。人工智能識別中咱們不少的服務也是能夠經過容器的方式來作。私有云也是同樣的，爲了更好地下降耦合度，加快應用部署。咱們也相信愈來愈多的私有云場景裏有容器相關的技術。

咱們的私有云場景我再簡單地解釋一下，咱們總體有一個PA-CMP，咱們叫壹雲管，這是個多管管理的體系，底下的產品咱們是能夠自選的，用戶能夠選擇雲主機，那他就只有雲主機產品在多雲管理裏面。好比用戶以後須要容器，那就是增長容器服務在多雲管理裏面。用戶能夠選本身想要的產品組合成一個他私有的解決方案。

咱們認爲容器相關技術對大部分企業、大部分雲廠商有很是大的做用，咱們但願和Rancher以及更多的廠商合做，構建好總體的服務。我今天的演講就到這裏，謝謝！