從 DevOps 到 Serverless:經過「不用作」的方式解決「如何更高效作」的問題

做者 | 徐進茂(羅離) JAVA 開發工程師 編程

導讀:近年來,Serverless 一詞愈來愈熱,它已經逐漸成爲了一種新型的軟件設計架構。和 DevOps 概念提倡的是經過一系列工具和自動化的技術來下降運維的難度,促進研發運維一體化不一樣, Serverless 更像是一種 NoOps,即經過「不用作」的方式來解決「如何更高效作」的問題。安全

DevOps 概述

DevOps 是一組用於促進開發和運維人員之間協做的過程、方法和系統的統稱。服務器

DevOps 提倡經過一系列的技術和工具下降開發和運維人員之間的隔閡,實現從開發到最終部署的全流程自動化,從而達到開發運維一體化。經過將 DevOps 的理念引入到整個系統的開發過程當中,可以顯著提高軟件的開發效率,縮短軟件交付的週期,更加適應當今快速發展的互聯網時代。微信

說到 DevOps ,就必然會提到持續集成。持續集成指的是在軟件開發過程當中,軟件開發人員持續不斷地將開發出來的代碼和其餘的開發人員的代碼進行合併,每次合併後自動地進行編譯、構建,並運行自動化測試進行驗證,而不是等到最後各自開發完成後才合併在一塊兒。架構

持續集成能從根本上提升一個團隊的軟件開發效率。在軟件開發過程當中引入持續集成,能夠幫助團隊及時的發現系統中的問題,並快速作出修復,不只能夠縮短軟件開發的時間,並且能夠交付更具質量的系統。app

基於 Docker 實現一個 DevOps 開發環境

一個 DevOps 開發環境須要知足如下 8 點需求。框架

  • 環境一致性:在本地開發出來的功能,不管在什麼環境下部署都應該能獲得一致的結果;less

  • 代碼自動檢查:爲了儘早發現問題,每一次代碼提交後,系統都應該自動對代碼進行檢查,及早發現潛在的問題,並運行自動化測試;運維

  • 持續集成:每次代碼提交後系統能夠自動進行代碼的編譯和打包,無需運維人員手動進行;函數

  • 持續部署:代碼集成完畢後,系統能夠自動將運行環境中的舊版本應用更新成新版本的應用而且整個過程當中不會讓系統不可用;

  • 持續反饋:在代碼自動檢查、持續集成、持續部署的過程當中,一旦出現問題,要能及時將問題反饋給開發人員以及運維人員。開發和運維人員收到反饋後對問題及時進行修復;

  • 快速回滾:當發現本次部署的版本出現問題時,系統應能快速回退到上一個可用版本;

  • 彈性伸縮:當某個服務訪問量增大時,系統應能夠對這個服務快速進行擴容,保證用戶的訪問。當訪問量回歸正常時,系統能將擴容的資源釋放回去,實現根據訪問狀況對系統進行彈性伸縮;

  • 可視化運維:提供可視化的頁面,可實時監控應用、集羣、硬件的各類狀態。

爲了知足以上 8 點要求,設計出的 DevOps 開發環境以下圖所示。

2

整個環境主要由 6 部分組成:

  • 代碼倉庫 Gitlab
  • 容器技術 Docker
  • 持續集成工具 Jenkins
  • 代碼質量檢測平臺 SonarQube
  • 鏡像倉庫 Harbor
  • 容器集羣管理系統 Kubernetes

整個環境的運行流程主要分爲如下 6 步:

  • 開發人員在本地開發並驗證好功能後,將代碼提交到代碼倉庫;

  • 經過事先配置好的 Webhook 通知方式,當開發人員提交完代碼後,部署在雲端的持續集成工具 Jenkins 會實時感知,並從代碼倉庫中獲取最新的代碼;

  • 獲取到最新代碼後,Jenkins 會啓動測試平臺 SonarQube 對最新的代碼進行代碼檢查以及執行單元測試,執行完成後在 SonarQube 平臺上生成測試報告。若是測試沒經過,則以郵件的方式通知研發人員進行修改,終止整個流程。若測試經過,將結果反饋給 Jenkins 並進行下一步;

  • 代碼檢查以及單元測試經過後, Jenkins 會將代碼發送到持續集成服務器中,在服務器上對代碼進行編譯、構建而後打包成能在容器環境上運行的鏡像文件。若是中間有步驟出現問題,則經過郵件的方式通知開發人員和運維人員進行處理,並終止整個流程;

  • 將鏡像文件上傳到私有鏡像倉庫 Harbor 中保存;

  • 鏡像上傳完成後, Jenkins 會啓動持續交付服務器,對雲環境中運行的應用進行版本更新,整個更新過程會確保服務的訪問不中斷。持續交付服務器會將最新的鏡像文件拉取到 Kubernetes 集羣中,並採用逐步替換容器的方式進行對應用進行更新,在服務不中斷的前提下完成更新。

經過上述幾步,咱們就能夠簡單實現一個 DevOps 開發環境,實現代碼從提交到最終部署的全流程自動化。

可是自從 2014 年 AWS 發佈 ASW Lambda 以來, Serverless 的概念開始逐漸火熱起來。各大雲廠商開始紛紛開始推出各自的 Serverless 產品,如 Google 的 Cloud Functions ,阿里雲的函數計算、Serverless應用引擎(SAE)等等。究竟什麼是Serverless 無服務計算呢?

什麼是 Serverless?

根據 CNCF (雲原生計算基金會)發佈的 Serverless 白皮書裏的定義:

Serverless computing refers to the concept of building and running applications that do not require server management. It describes a finer-grained deployment model where applications, bundled as one or more functions, are uploaded to a platform and then executed, scaled, and billed in response to the exact demand needed at the moment.

首先須要強調一點的是無服務器計算並不意味着咱們再也不須要使用服務器來運行代碼,代碼仍須要運行在服務器上對外提供服務。

在無服務計算時代,研發人員無需對服務器進行監控、配置、更新、擴容等運維操做。只須要將代碼上傳到雲廠商提供的無服務器計算平臺上便可,雲廠商會保證代碼能正常運行,當流量突增時,自動對服務器進行擴容,流量減小時,對服務器進行縮容。

3

這些運維操做對研發人員來講都是黑盒的,會將開發人員從繁瑣的運維工做中解放出來,只須要按運行時長對資源進行付費便可。

和 DevOps 概念提倡的是經過一系列工具和自動化的技術來下降運維的難度,促進研發運維一體化不一樣, Serverless 更像是一種 NoOps,即經過「不用作」的方式來解決「如何更高效作」的問題。

阿里雲在 Serverless 上的實踐

當前阿里雲上實現 Serverless 技術的產品有 Serverless 應用引擎和函數計算 FaaS。

Serverless 應用引擎

Serverless 應用引擎是面向應用的 Serverless PaaS 平臺,它向上抽象了應用的概念,支持 Spring Cloud、Apache Dubbo、HSF 等流行的開發框架,並經過 WAR 包、JAR 包和鏡像等多種方式部署應用。它的使用能夠經過下面這張圖來了解。

4

函數計算

FaaS 是 Serverless 所提供的服務的另外一種形態。以阿里雲函數計算爲例,阿里雲函數計算的流程大體以下圖所示。

5

  • 開發者在本地編寫代碼;

  • 代碼開發完成後經過命令行工具 fcli、fun 或者可視化界面控制檯上傳到阿里雲函數計算平臺;

  • 開發者上傳完代碼後,平臺會自動啓動基於 Docker 的 DevOps 流程,對代碼進行編譯、打包成鏡像文件。並上傳到鏡像倉庫;

  • 開發者在平臺是配置事件觸發器,當前阿里雲已經支持 OSS、HTTP、CDN、SLS、定時任務等多種形式的觸發器形式;

  • 當觸發器被觸發後,會到達事件調度器。平臺會將鏡像快速啓動成容器並執行代碼,根據流量自動對服務進行彈性伸縮。保證代碼能正常並執行完成。

伯克利對 Serverless 將來的預測

儘管 Serverless 仍存在諸多的挑戰,可是咱們相信隨着市場規模的不斷擴大,這些挑戰會逐漸被解決。UC 伯克利對 Serverless 將來十年的發展趨勢作了如下幾點預測。

  • 新型的 BaSS 存儲服務會被創造出來,這樣更多類型的應用能夠遷移到 Serverless 平臺上。這種存儲服務的性能會和本地存儲的性能至關,並提供長期和短時間的存儲。更多適用於 Serverless 平臺的硬件會被使用;

  • 因爲更高級別的編程抽象以及更加細粒度的資源隔離,在無服務器計算平臺上運行的代碼將會比傳統的方式更加安全可靠;

  • 隨着無服務器計算收費模式的不斷髮展,幾乎任何應用遷移到無服務器計算平臺都會比原先的有服務器計算的方式的成本更低;

  • 有服務器計算在將來會促進 BaaS 的發展;

  • 雖然現有的有服務器計算不會消失,可是隨着 Serverless r技術的不斷髮展,有服務器計算在雲上所佔的比例會逐年降低;

  • 無服務器計算將會成爲雲時代默認的編程方式,它將大規模取代傳統的基於服務器的編程方式,並終結傳統的 C/S 架構。

總結

當前數據中心的資源利用率仍處於一個較低水平,特別是對於在線業務而言,日均資源使用率僅在 10% 左右,主要是因爲當今資源都是屬於獨享型的,無論你用不用,這些資源都須要保留。

一旦大規模使用 Serverless 以後,資源的使用由平臺統一調度,按需使用,總體的資源利用率會大幅提高,整個雲計算資源的使用成本無疑也會大幅下降。

隨着 Serverless 的不斷髮展,將來編程方式將會有很大的不一樣。不管是從成本的角度仍是使用的角度,咱們有理由相信下一個時代是 Serverless 的時代,並應該朝着這個方向不斷探索。

做者簡介:徐進茂(羅離) Java 開發工程師。現就任於阿里雲智能基礎設施事業部,主要負責阿里巴巴數據中心運營平臺的研發工做。


「 阿里巴巴雲原生微信公衆號(ID:Alicloudnative)關注微服務、Serverless、容器、Service Mesh等技術領域、聚焦雲原生流行技術趨勢、雲原生大規模的落地實踐,作最懂雲原生開發者的技術公衆號。」

相關文章
相關標籤/搜索