點擊上方“朱小廝的博客”，選擇“設為星標”

后臺回復”加群“獲取公眾號專屬群聊入口

來源：阿里巴巴中間件

DevOps 概述

---

DevOps 是一組用于促進開發和運維人員之間協作的過程、方法和系統的統稱。

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

說到 DevOps ，就必然會提到持續集成，持續集成指的是在軟件開發過程中，軟件開發人員持續不斷地將開發出來的代碼和其他的開發人員的代碼進行合并，每次合并后自動地進行編譯、構建，并運行自動化測試進行驗證，而不是等到最后各自開發完成后才合并在一起。持續集成能從根本上提高一個團隊的軟件開發效率。在軟件開發過程中引入持續集成，可以幫助團隊及時的發現系統中的問題，并快速做出修復，不僅可以縮短軟件開發的時間，而且可以交付更具質量的系統。

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

---

一個 DevOps 開發環境需要滿足以下 8 點需求。

1、環境一致性：在本地開發出來的功能，無論在什么環境下部署都應該能得到一致的結果。
2、代碼自動檢查：為了盡早發現問題，每一次代碼提交后，系統都應該自動對代碼進行檢查，及早發現潛在的問題，并運行自動化測試。
3、持續集成：每次代碼提交后系統可以自動進行代碼的編譯和打包，無需運維人員手動進行。
4、持續部署：代碼集成完畢后，系統可以自動將運行環境中的舊版本應用更新成新版本的應用并且整個過程中不會讓系統不可用。
5、持續反饋：在代碼自動檢查、持續集成、持續部署的過程中，一旦出現問題，要能及時將問題反饋給開發人員以及運維人員。開發和運維人員收到反饋后對問題及時進行修復。
6、快速回滾：當發現本次部署的版本出現問題時，系統應能快速回退到上一個可用版本。
7、彈性伸縮：當某個服務訪問量增大時，系統應可以對這個服務快速進行擴容，保證用戶的訪問。當訪問量回歸正常時，系統能將擴容的資源釋放回去，實現根據訪問情況對系統進行彈性伸縮。
8、可視化運維：提供可視化的頁面，可實時監控應用、集群、硬件的各種狀態。
為了滿足以上 8 點要求，設計出的 DevOps 開發環境如下圖所示。

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

1、代碼倉庫 Gitlab 。
2、容器技術 Docker 。
3、持續集成工具 Jenkins 。
4、代碼質量檢測平臺 SonarQube 。
5、鏡像倉庫 Harbor 。
6、容器集群管理系統 Kubernetes 。

整個環境的運行流程主要分為以下 6 步。

1、開發人員在本地開發并驗證好功能后，將代碼提交到代碼倉庫。
2、通過事先配置好的 Webhook 通知方式，當開發人員提交完代碼后，部署在云端的持續集成工具 Jenkins 會實時感知，并從代碼倉庫中獲取最新的代碼。

3、獲取到最新代碼后，Jenkins 會啟動測試平臺 SonarQube 對最新的代碼進行代碼檢查以及執行單元測試，執行完成后在 SonarQube 平臺上生成測試報告。如果測試沒通過，則以郵件的方式通知研發人員進行修改，終止整個流程。若測試通過，將結果反饋給 Jenkins 并進行下一步。
4、代碼檢查以及單元測試通過后， Jenkins 會將代碼發送到持續集成服務器中，在服務器上對代碼進行編譯、構建然后打包成能在容器環境上運行的鏡像文件。如果中間有步驟出現問題，則通過郵件的方式通知開發人員和運維人員進行處理，并終止整個流程。
5、將鏡像文件上傳到私有鏡像倉庫 Harbor 中保存。
6、鏡像上傳完成后， 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.

首先需要強調一點的是無服務器計算并不意味著我們不再需要使用服務器來運行代碼，代碼仍需要運行在服務器上對外提供服務。

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

這些運維操作對研發人員來說都是黑盒的，會將開發人員從繁瑣的運維工作中解放出來，只需要按運行時長對資源進行付費即可。和 DevOps 概念提倡的是通過一系列工具和自動化的技術來降低運維的難度，促進研發運維一體化不同， Serverless 更像是一種 NoOps，即通過“不用做”的方式來解決“如何更高效做”的問題。

阿里云在 Serverless 上的實踐

---

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

Serverles應用引擎

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

函數計算

FAAS 是 Serverless 所提供的服務的另一種形態。以阿里云函數計算為例，阿里云函數計算的流程大致如下圖所示。

1、開發者在本地編寫代碼。
2、代碼開發完成后通過命令行工具 fcli, fun 或者可視化界面控制臺上傳到阿里云函數計算平臺。
3、開發者上傳完代碼后，平臺會自動啟動基于 Docker 的 DevOps 流程，對代碼進行編譯、打包成鏡像文件。并上傳到鏡像倉庫。
4、開發者在平臺是配置事件觸發器，當前阿里云已經支持 OSS、HTTP、CDN、SLS、定時任務等多種形式的觸發器形式。
5、當觸發器被觸發后，會到達事件調度器。平臺會將鏡像快速啟動成容器并執行代碼，根據流量自動對服務進行彈性伸縮。保證代碼能正常并執行完成。

伯克利對 Serverless 未來的預測

---

盡管 Serverless 仍存在諸多的挑戰，但是我們相信隨著市場規模的不斷擴大，這些挑戰會逐漸被解決。?UC 伯克利對 Serveless 未來十年的發展趨勢做了以下幾點預測。

1、新型的 Bass 存儲服務會被創造出來，這樣更多類型的應用可以遷移到 Serveless 平臺上。這種存儲服務的性能會和本地存儲的性能相當，并提供長期和短期的存儲。更多適用于 Serveless 平臺的硬件會被使用。
2、由于更高級別的編程抽象以及更加細粒度的資源隔離，在無服務器計算平臺上運行的代碼將會比傳統的方式更加安全可靠。
3、隨著無服務器計算收費模式的不斷發展，幾乎任何應用遷移到無服務器計算平臺都會比原先的有服務器計算的方式的成本更低。
4、有服務器計算在未來會促進 BaaS 的發展。
5、雖然現有的有服務器計算不會消失，但是隨著Serveless技術的不斷發展，有服務器計算在云上所占的比例會逐年下降。
6、無服務器計算將會成為云時代默認的編程方式，它將大規模取代傳統的基于服務器的編程方式，并終結傳統的 C/S 架構。

總結

---

當前數據中心的資源利用率仍處于一個較低水平，特別是對于在線業務而言，日均資源使用率僅在 10% 左右，主要是由于當今資源都是屬于獨享型的，不管你用不用，這些資源都需要保留。而一旦大規模使用 Serveless 之后，資源的使用由平臺統一調度，按需使用，整體的資源利用率會大幅提升，整個云計算資源的使用成本無疑也會大幅降低。

隨著 Serverless 的不斷發展，未來編程方式將會有很大的不同。無論是從成本的角度還是使用的角度，我們有理由相信下一個時代是 Serveless 的時代，并應該朝著這個方向不斷探索。

想知道更多？掃描下面的二維碼關注我

后臺回復”加群“獲取公眾號專屬群聊入口

【精彩推薦】

• 咱們從頭到尾說一次Java垃圾回收

• Netty、Kafka中的零拷貝技術到底有多牛？

• go為什么這么快？

• 面試前，我們要復習多少Redis知識？

• 《深入理解Java虛擬機》第2版挖的坑終于在第3版中被R大填平了

• Redis性能問題分析

• 淺談CAP和Paxos共識算法

• 聊一聊Java中的文件鎖

• Kafka為什么這么快？

• Paxos、Raft不是一致性算法嘛？

• 聊聊Java的幾把JVM級鎖

• 越說越迷糊的CAP

• 聊一聊Java服務端中的亂象
  

>>>?字節跳動社招內推入口?<<<

>>> 字節跳動校招內推入口 <<<

朕已閱?

總結

以上是生活随笔為你收集整理的从 DevOps 到 Serverless的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。