淺談基于微服務PaaS平臺構建Devops生產流水線

黃 靜，陳秋燕，姚東烽

（1.中國移動通信集團廣東有限公司，廣東 廣州 510640；2.浪潮世科（山東）信息技術有限公司，山東 濟南 250000）

0 引言

隨著業界IT技術的不斷發展以及企業園區信息化應用系統不斷增多，且各應用系統采用的技術架構及開發平臺差異較大，對于這些應用系統的持續優化、擴容及維護都要花費較大的投資和成本。通過在微服務PaaS平臺構建DevOps流水線，能夠實現敏捷開發及自動化部署、運維一體化的流程，實現從多個角度對業務系統進行自動化運維監控，從而實現信息化應用的全生命周期無縫管理及自動化的高可用保證。

1 DevOps介紹

1.1 定義

DevOps源于“Development（開發）”和“Operation（運維）”兩個詞的縮寫，軟件開發和IT運維的結合被稱為DevOps。DevOps是一組過程、方法與系統的統稱，用于促進開發（應用程序/軟件工程）、技術運營和質量保障（QA）部門之間的溝通、協作與整合。它的出現是由于軟件行業日益清晰地認識到：為了按時交付軟件產品和服務，開發和運營工作必須緊密合作。[1]

從定義中可以看出，可以明確DevOps這個過程參與的人員主要是開發團隊和運維團隊，而DevOps的目的是在兩個團隊之間，建立良好的溝通和協作，更快速、更可靠的創建高質量軟件。

1.2 開發模式對比

瀑布模式是最早出現的軟件開發模型，由于這種模型的線性過程太理想化，在現代業界的軟件開發中，瀑布模式幾乎不復存在。而同樣作為傳統模式的迭代式開發和螺旋開發，是在瀑布模式的基礎作出調整和改良的軟件開發模式，在現時某些特地場景有其一定的適用性。

現代最流行的是敏捷管理模式，敏捷開發不追求前期完美的設計、完美編碼，而是力求在短期內開發出產品的核心功能，盡早發布出可用的版本，然后在后續的生產周期內按照新需求不斷迭代升級，完善產品。

DevOps是最新近才出現的，它是將運維納入產品開發過程的思維方式，是敏捷的有效補充，它通過消除資源浪費和簡化部署等方式來實現這一目標，從而實現更快，更持續的生產部署。

瀑布模式 敏捷模式 DevOps相似點 三者都有軟件開發、測試和部署這三個階段。但前者嚴格按照線性方式進行，而后兩者追求快速開發軟件，適合經常變化的項目。不同點1、將軟件生存周期的各項活動規定為按固定順序而連接的若干階段工作，階段之間產生大量的文檔，不適應用戶需求的變化。2、由于開發模型是線性的，用戶只有等到整個過程的末期才能見到開發成果，從而增加了開發風險；1、簡化了傳統開發管理的繁瑣流程和文檔，假設和擁抱不確定性，認為需求變更是客戶需求的一部分，強調適應性和團隊中的高度協作；2、敏捷方法在運維方面沒有敏捷實踐的速度，開發和運維之間缺乏協作仍然會減慢開發過程和發布；3、敏捷流程在三個階段之后會終止。1、DevOps幾乎擁有敏捷開發模式的一切優點；2、DevOps方法是基于對更好的協作和更快的交付的需求而產生的；3、D e v O p s包 括 后續持續的運維，即DevOps會持續的監控軟件運行情況和進行持續的開發。

1.3 傳統軟件開發方式和DevOps方式之間的區別[2]

二者的區別主要在于開發和運維的模式上，如下所述：

傳統方式 DevOps 1.傳統上在軟件開發中（無論是瀑布模型還是敏捷方式，敏捷也比較傳統），都由“開發團隊”來構建軟件。2.開發團隊需要與運維團隊進行了大規模的“交接”。運維團隊負責執行一系列“部署”活動，將軟件代碼移至生產環境，并負責維護后續的系統穩定運行。3.生產環境的基礎設施與開發或測試不同。4.需要有額外檢查和平衡，以確保它一切功能正常。DevOps打破了開發和部署之間的界限，實現開發運維一體化：1. 支持持續集成（CI），開發人員提交了新代碼之后，立刻自動的進行構建、（單元）測試。2. 支持持續部署（CD），當交付的代碼通過評審之后，自動部署到生產環境中。3.自動化了所有測試用例，所有的配置管理、環境管理和發布管理，可以直接launch。

2 DevOps生命周期及其相關工具

一般來說，DevOps由多個階段組成：持續開發、持續測試、持續集成、持續監控、持續部署，這些階段統稱為DevOps生命周期。這五個階段能體現DevOps從”需求提出-＞生產-＞完整交付”的整個開發流程，下面對DevOps生命周期的階段性進行分析。[3]

2.1 持續開發

DevOps生命周期的第一個階段是編碼和構建。開發應用程序源代碼的第一步是從不同的編程語言中進行選擇，諸如JavaScript，C / C ++和Python等。而維護代碼的過程稱為源代碼管理（SCM），可使用Git和SVN等工具來維護不同版本的代碼，以及使用Gradle，Maven等類似工具來構建/打包代碼到可執行文件中。

與瀑布模式不同的是，軟件可交付成果被分解為短開發周期的多個任務節點，在很短的時間內開發并交付。這是DevOps生命周期中一個不斷進行軟件開發的階段。

2.2 持續測試

在這個階段，對開發的軟件進行持續的Bug測試。TestNG，Selenium和JUnit是常用于自動化測試的一些DevOps工具，這些工具允許質量管理系統完全并行地測試多個代碼庫，以確保功能中沒有缺陷。通過自動化測試，可節省開發人員手動測試浪費的時間和精力。在這個階段，使用Docker容器實時模擬測試環境。一旦代碼測試通過，它就會被重新發送到持續集成階段以更新源代碼。

2.3 持續集成

這是支持新功能的代碼與現有代碼集成的階段，是整個DevOps生命周期的核心。軟件在不斷地開發，源代碼在頻繁地更改，更新后的代碼需要不斷地集成，并順利地與系統集成，以反映對最終用戶的需求更改。更改后的代碼，還應該確保運行時環境中沒有錯誤，允許我們測試更改并檢查它如何與其他更改發生反應。

Jenkins是被廣泛應用的可靠的持續集成工具，用于獲取更新的源代碼，并生成一個構建，最終可以部署到測試或生產環境。 這些轉換是無縫進行的，更新的代碼將打包并進入下一階段，即測試或生產服務器。

2.4 持續部署

在此階段，最終確定的應用程序代碼將被部署到生產環境。配置管理是這一階段的關鍵過程，它將應用程序代代碼發布到服務器，為所有服務器安排更新，確保應用程序性能和功能條件在整個生產過程中保持一致。Puppet，Chef，SaltStack和Ansible是用于配置管理的一些有效的DevOps工具，用于執行新代碼的快速和連續部署。

需要注意的是，如果添加了任何功能或引入了新功能，我們應該準備好迎接更多的網站流量。

容器化工具在部署階段也發揮著重要作用。 Docker和Vagrant是流行的容器化工具，這些工具有助于在開發，測試，登臺和生產環境中實現一致性。 同時，它們還可以處理連續部署的可伸縮性。

2.5 持續監控

這是DevOps生命周期中非常關鍵的階段，持續監控旨在保持應用程序中服務的可用性。在此階段，IT運維團隊比開發團隊的參與程度更高，他們監視用戶活動、檢查系統是否有異常行為以及跟蹤錯誤的存在。一些常見系統錯誤如“服務器無法訪問”或“內存不足”可以在這個階段被發現和解決，它還能確認重復出現的系統錯誤的威脅和根本原因。

這也可以通過使用專用監控工具來實現，Splunk，ELK Stack，Nagios，NewRelic和Sensu是用于持續監控的關鍵DevOps工具。這些工具可幫助密切監視應用程序和服務器，主動檢查系統的運行狀況。在這些工具的幫助下，可以提高生產率和應用程序的可靠性，從而降低IT支持成本。當在此階段檢測到重大問題時，可以向開發團隊報告，以便可以在持續開發階段進行修復。

這些DevOps階段連續循環進行，直到達到所需的產品質量。下圖顯示了在DevOps生命周期的各個階段所使用的工具。

3 Pass平臺+DevOps

DevOps的實施往往需要在一個完整的DevOps過程支撐平臺基礎之上，將研發過程管理、持續交付和技術運營全部融合到一起，同時底層開發基于微服務開發框架，組件運行依托在容器化PaaS平臺上，形成一個完整的整體。[4]PaaS平臺+DevOps是使用微服務架構在 PaaS上建立應用程序使得開發人員與運營之間的協作更加無縫。PaaS產品充分利用了容器，提供了正確的標準化以簡化部署管道，當這一點與構建和部署微服務的小團隊協作優勢相結合時，就能夠實現DevOps利益最大化。

微服務、容器、PaaS和DevOps的組合具有巨大潛力，能夠將大型企業信息技術進行轉型，能夠協助企業進行研發管理過程的規范化和流程化，再進一步實現自動化。

4 結束語

微服務PaaS平臺構建DevOps流水線，通過采用敏捷開發模式，能夠明顯提升開發的效率，支持適度的需求變更，支持持續的CI/CD，更好地提升軟件系統的易用性及友好性，同時提升運維效率。