最近幾年很多公司實現了從VMware等傳統虛擬化到IaaS的轉型，很多公司正在或者已經建立PaaS平臺。那么從項目研發角度看，PaaS產品的系統功能應該主要涵蓋哪些，又該如何更好的為應用研發人員服務呢?本文由云計算專家bryan根據社區活動中的分享交流所整理。

一.PaaS 建議的意義何在，能夠給企業帶來哪些價值?

1. 實現應用運行環境的標準化，提升交付速度：通過容器的鏡像技術保證開發測試和生產等諸多標準化，避免因應用運行環境不一致帶來的各種故障和問題，同時，通過服務編排實現運行環境的自動化運維和快速交付，避免傳統方式的應用系統運行復雜、交付周期較長等問題;

2. 實現運維過程的高度自動化，降低運維成本：PaaS 平臺提供多種自動化運維工具管理應用集群系統，比如智能負載可以實時觀測集群節點的變化并智能修改路由配置，自動伸縮可以實現不同業務負載下集群規模的自動調整等，多種管理功能的自動化減少人工運維工作量，節省運維成本;

3. 有效提升基礎資源的管理水平和硬件利用效率：PaaS 平臺資源的容器是基于操作系統的虛擬化，與 IaaS 基礎環境實現解耦，平臺自身的實現多數是應用較廣的開發框架和標準 API，能夠有效提升資源管理水平，有效避免廠商綁定;同時，合理調整單個操作系統之上容器密度的有效部署，可以更好提升資源使用率，降低硬件采購成本;

4. 有效實現軟件研發的技術路徑統一和把控研發質量：通過運行環境的標準化可真正做到全公司技術路線的精細把控，做到統一不同項目組的技術研發路線，通過部署工具的統一可以做到 CI/CD 思想的有效落地實施，有效提升軟件研發過程的質量把控水平;

5. 有效提升公司 IT 架構治理：相較于傳統開發運維各司其職的模式，PaaS 能有效實現 devops 思維的落地實施，推動企業 IT 流程和人員架構的企業治理，更好的提升 IT 部門各個研發團隊的整體技術水平，從而更好的響應業務需求。

[[205424]]

二. PaaS 的主要技術有哪些?企業如何進行建設?

PaaS 主要以容器云形式實現，容器云依賴容器基礎技術，目前常見的有 Docker 和 garden 兩種類型，其中 BAT、京東、華為和網易等互聯網公司，還有一些大型商業銀行更多的選擇 docker 技術，當然也不乏 garden 成功案例，但較之 docker 案例相對較少。

獨木難成林，容器要云化形式提供服務，必須以多個容器形成集群的方式，此時如何管理和調度集群是一個重要的任務，這個任務由編排引擎進行實現，目前比較流行的有 kubernetes、swarm 等。因此「容器技術+編排引擎」構成了容器云最初始的框架，當然要達到企業級應用還需要做更多企業級的功能，所以就出現了諸如 openshift、阿里飛天、華為等各種以開源軟件為基礎構建的多種產品。

那么企業在建設云的過程中需要考慮幾個問題：

• 容器技術的選擇：盡量選擇市場比較流行的開源社區和生態發展比較完善的技術，編排引擎的框架選擇遵循同樣道理;
• 建設模式：一種方式是購買產品進行企業落地化定制化，一種方式是基于開源框架自研，兩種方式各有優劣，需要結合企業自身特點進行總體考慮;
• 建設規劃：PaaS 的建設涵蓋很多方面，甚至需要企業流程和企業 IT 架構的梳理和調整，因此對大中型企業來講不可能一蹴而就，需要一個循序漸進的過程，這也與企業發展和自身技術特點有關系

三. 容器云的負載均衡如何選擇?

軟件負載有硬件 F5 和軟件 HAProxy、nginx 等。F5 的特點是價格貴、性能好，一般在物理機和虛擬機化時間做 LB;nginx 是一款 HTTP 服務器和反向代理服務器，可以提供 7 層負載均衡能力，主要應用場景有 web 服務器、反向代理、負載均衡等

HAProxy 是一款專業的負載均衡軟件，可提供 4/7 層負載均衡，比 nginx 負載均衡性能好，并發上也優于 nginx。負載均衡的選擇需要和企業自身特點和具體業務場景相關聯，在 PaaS 的企業級產品中更多的選擇 HAproxy

四. PaaS 的日志和監控如何進行處理?

PaaS 平臺的日志和監控和傳統架構的管理方式沒有本質區別。日志的獲取或采用安裝 agent、或采用工具導出，業界已經都有很多成熟的產品和案例可以借鑒;監控分兩部分，先要解決「監」的問題，同樣也需要利用工具抓取信息，然后解決「控」，要么利用自動化運維的模式，要么采用手工的模式，目的其實一樣，區別在于成本控制。

PaaS 可以從系統、網絡、服務、應用監控 4 個層面入手：

1. 系統主要指底層基礎資源，如磁盤、CPU、硬件或 IaaS 等基礎資源

2. 網絡一般采用 SDN 的方式實現，監控比較復雜，主要有連通性、流量、7 層狀態碼等

3. 服務主要是指 PaaS 中的各種中間件服務服務，比如數據庫服務、緩存服務、web 應用服務等

4. 應用監控是最上層的也是非常重要的，比如應用服務質量、響應時間、請求成功率等

五. PaaS 如何更好的實現 CI/CD，實現應用敏捷開發

PaaS 平臺的一個核心理念是為應用提供各種基礎中間件服務和進行應用集群的管理。devops 是一種貫徹項目研發全生命周期的軟件研發理論，打破傳統的研發部門和運維部門涇渭分明的現象，盡量實現團隊將研發和運維進行統一結合的模式，這種理念落地實施需要借助一定工具。CI 是持續集成，可以實現代碼自動化的靜態檢查、動態檢查、安全檢查和單元測試、集成測試等功能，從而實現代碼的盡快盡早集成，減少后期發現問題的概率、降低項目風險;CD 是持續部署或者持續發布，這種持續部署采用自動化工具，能夠有效提高系統環境的部署效率和升級更新時業務的連續性。

jenkins 可視作一個平臺，在這個平臺中一方面可以用戶定制各種插件，一方面可以將所有的工作以流程化的形式 (pipeline) 串聯起來。這樣可以將 CI/CD 的思維通過 jenkins 的落地實施來貫徹執行，同時 CI/CD 有多種自動化管理功能，而 PaaS 中的相關系統部署或者更新升級或者項目研發過程使用的環境都可以自動化，于是二者可以很好的進行關聯。

Devops 理念的落地實現，可通過 jinkins 中配置自動化的 CI/CD 流程，更好的與 PaaS 進行深度集成，從而提高軟件研發效率和軟件研發質量。詳情可以參考鏈接

六. PaaS 的研究過程中有哪些關鍵技術點和難點，一般市場是如何選擇的?

PaaS 作為一個綜合性的平臺，在以」容器+編排引擎」的基礎上有諸多關鍵技術點和難點，本次主要以開源框架和一些市場產品為依托，主要講述關鍵點的實現

1. 容器技術的選擇：容器技術是整個平臺的基石，猶如開發 web 需要選擇開發語言一樣，目前有 docker 和 garden 兩種主流技術，自研技術選擇時盡量選擇技術相對成熟、企業應用案例相對較多、技術生態圈發展更多的技術，一般建議選擇 docker，如果華為的 PaaS 產品初期選擇 garden，目前也已轉向了 docker，docker 已經成為一種事實上的標準。

2. 編排引擎的選擇：編排引擎的選擇一般會依賴容器技術路線的選擇，比如 docker 容器可以選擇 kubernetes、swarm 等框架，garden 可以選擇 cloud foundry，并且僅此選擇。在 BAT、華為、京東等互聯網公司中，選擇 docker 系的產品更多的選擇了 kubernetes，或許源于此框架出自 google 大家之手

3. 元數據存儲的框架選擇：由于整個 PaaS 的元數據需要一個高可用的存儲結構，以便用作服務發現或共享元數據配置的相關元數據信息。基于 zookeeper 的性能和復雜性等問題考慮，更多的選擇 etcd 框架進行使用，openshift、阿里等產品均采用了此框架

4.PaaS 容器網絡的選擇：容器的網絡隔離是 PaaS 資源隔離的一個重要組成部分，每個容器的網絡多采用內部 SDN 網絡，SDN 網絡的實現技術各不相同，一般主要考慮因素是網絡的性能和網絡變化的靈活性等因素。開源 kubernetes 采用 flannel 框架，openshift 的產品中考慮到網絡性能等采用了 open vswitch，京東在經過各種研究后采用了基于 BGP 路由方式的 Calico

5.CI/CD 的工具選擇：隨著最近幾年微軟對 docker 技術的支持力度加大，各種產品，比如 window server 2016、TFS 等逐漸實現對 docker 的支持。TFS(team foundation server)的產品定位與 jenkins 類似。所以在 CI/CD 的技術落地過程中可以選擇 TFS 或者 jenkins，不過大家更廣發的采用 jenkins，并且有研發能力的均對其進行一定程度的插件研發和定制

6. 日志框架的選擇：在集群環境中如何管理不同節點的日志是一個重要的問題，并且目前有一套成熟的解決方案。ElasticSearch+Logstash+Kinana(ELK)已成為一種通用解決方案

7. 負載均衡的選擇：負載均衡需要在容器集群的容器成員發生變化時能夠自動感知和自動修改路由策略，硬件 F5 和軟負載 HAProxy、Nginx 均可做負載均衡，鑒于 HAProxy 的靈活性，更多的產品或者企業落地均選擇了 HAProxy

8. 域名的使用：容器集群中的某個應用可以視作一個對外提供的服務，如果采用 IP，一方面不方便記憶，一方面 IP 有可能改變，因此 PaaS 產品多采用泛域名的形式，將對外提供服務的 IP 地址和域名關聯對應，然后再提供一個 route 記錄對外提供服務的 IP 地址(frontend)和內部集群 IP 地址(backend)，這樣就可以實現從外部域名到內部集群 IP 地址的訪問。

PaaS 平臺的建議是一個長期的過程，需要不斷持續的進行迭代優化，并且隨著在 PaaS 之上運行應用系統的增多和使用經驗的不斷豐富，對 PaaS 平臺會有更多深入的認知和體會。因此我們也希望論壇上從事這塊研究和實踐的朋友能夠更多的進行技術交流，從而加深技術了解，讓 PaaS 在企業內部更好的發揮其價值和優勢。