沒有比“不用做”更有效的方式來解決“如何更高效做”的問題了。
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 開發工程師。現就職於阿里雲智能基礎設施事業部，主要負責阿里巴巴數據中心運營平臺的研發工作。
本文轉載自公衆號阿里巴巴中間件（ID：Aliware_2018）。
原文鏈接：