紅帽資深解決方案架構師魏新宇：雲原生應用構建之路 | IDCF

1、雲原生應用

1.1 什麼是雲原生應用

傳統的軟件開發流程是瀑布式的，開發週期比較長，而且若是有任何變動，都要從新走一遍開發流程。在商場如戰場的今天，軟件一個版本推遲發佈可能到發佈時這個版本在市場上就已通過時了；而競爭對手極可能因爲在新軟件發佈上快了一步就搶佔了客戶和市場。
相比於傳統應用，雲原生應用很是注重上市速度。雲原生應用是獨立的、小規模鬆散耦合服務的集合，旨在充分利用雲計算模型提升應用發佈速度、應用靈活性和應用代碼質量，並下降應用部署風險。雖然名字中包含「雲原生」三個字，但云原生的重點並非應用部署在何處，而是如何構建、部署和管理應用。經過表 1-1，咱們能夠比較清晰地看出雲原生應用與傳統應用之間的差異。

1.2 雲原生應用開發和部署的四大原則

雲原生應用所構建和運行的應用，旨在充分利用基於四大原則的雲計算模型。

• 基於服務的架構：基於服務的架構（如微服務）提倡構建鬆散耦合的模塊化服務。採用基於服務的鬆散耦合設計，可幫助企業提升應用建立速度，下降複雜性。
• 基於 API 的通訊：即經過輕量級 API 來進行服務之間的相互調用。經過 API 驅動的方式，企業能夠經過所提供的 API 在內部和外部建立新的業務功能，極大提高了業務的靈活性。此外，採用基於 API 的設計，在調用服務時可避免因直接連接、共享內存模型或直接讀取數據存儲而帶來的風險。
• 基於容器的基礎架構：雲原生應用依靠容器來構建跨技術環境的通用運行模型，並在不一樣的環境和基礎架構（包括公有云、私有云和混合雲）間實現真正的應用可移植性。此外，容器平臺有助於實現雲原生應用的彈性擴展。
• 基於 DevOps 流程：採用雲原生方案時，企業會使用敏捷的方法，依據持續交付和 DevOps 原則來開發應用。這些方法和原則要求開發、質量保證、安全、IT 運維團隊以及交付過程當中所涉及的其餘團隊以協做方式構建和交付應用。
  在瞭解了雲原生應用開發和部署的四大原則後，咱們接下來介紹雲原生應用的構建之路。

2、雲原生應用構建之路的步驟

雲原生應用的構建之路一共分爲 6 個步驟。

步驟 1：發展 DevOps 文化和實踐。

要完成雲原生應用的構建之路，開發和 IT 運維團隊必須進行多方面的變革，以便更加快速高效地構建和部署應用。各行各業的客戶都須要周全地考慮各類活動、技術、團隊和流程，由於這些要素綜合起來才能實現 DevOps 文化。

所以，要想充分利用新技術，採用更加快速的方案，實現更爲密切的合做，企業必須切實遵循 DevOps 的原則和文化價值，並圍繞這些價值來進行組織和規劃。藉助於 Red Hat 的 OpenShift，企業能夠實現 DevOps 以及進一步的 DevSecOps 技術的落地。

步驟 2：藉助輕量級應用服務器，爲現有單體應用提速。

在開啓雲原生應用之旅時，企業不能只關注開發新的應用。不少傳統應用都是確保企業順利運營和不斷創收的關鍵所在，不能簡單地取而代之。企業需將這類應用與新的雲原生應用整合到一塊兒。可是，如何加快現有單體式應用的運行速度呢？

正確的方法是：將現有的單體式架構遷移到模塊化程度更高且基於服務的架構中，並採用基於 API 的通訊方式，從而實施快速單體式方案。在開始實施將單體式應用重構爲微服務的艱鉅任務前，企業應該先爲他們的單體式架構奠基堅實的基礎。雖然單體式應用的敏捷性欠佳，但其受到詬病的主要緣由是自身的構建方式。運行快速的單體式應用能夠實現微服務所能帶來的諸多敏捷性優點，並且不會增長相關的複雜性和成本。

經過對快速單體式方案進行評估，能夠確保應用在構建時遵循嚴苛的設計原則，以及正肯定義域邊界。這樣，企業就能在須要時以更加按部就班、風險更低的方式過渡至微服務架構。如能以這種方式實現快速單體式應用的轉型，便可爲優良的微服務架構打下紮實的基礎。

藉助於 Red Hat OpenShift 和輕量級的應用服務器 Red Hat JBoss EAP，咱們能夠將傳統單體應用遷移到容器中，爲現有單體應用提速。隨着 OpenShift 承載的單體應用愈來愈多，就會涉及傳統 ESB 分佈式的問題，即分佈式集成。

步驟 3：藉助 PaaS 平臺和 DevOps 加快應用開發速度。

可複用性一直都是加速軟件開發的關鍵所在，雲原生應用也不例外。可是，雲原生應用的可複用組件必須通過優化，並整合到容器 PaaS 平臺和 DevOps 中。例如， CI/CD 開發流水線、PaaS 提供的滾動升級和藍/綠部署、自動可擴展性、容錯等，能夠大幅提高雲原生應用的開發速度。

步驟 4：選擇合適的應用開發框架。

隨着物聯網（IoT）、機器學習、人工智能（AI）、數據挖掘、圖像識別、自動駕駛等新興技術的興起，應運而生的應用開發框架也愈來愈多，如圖 1-1 所示。咱們須要根據特定的業務應用需求來選擇語言或框架，所以不一樣的雲原生應用會採用不一樣的應用開發框架。這就要求容器 PaaS 平臺可以支持多種應用開發框架。Red Hat OpenShift 能夠支撐多種應用開發框架。

步驟 5：藉助可重複的流程、規則和框架，實現 IT 自動化，加速應用交付。

經過 IT 自動化流程、避免手動執行 IT 任務，是加速交付雲原生應用的重點。IT 自動化管理工具會建立可重複的流程、規則和框架，以替代或減小會延遲上市的勞動密集型人工。這些工具能夠進一步延伸到具體的技術（如容器）、方法（如 DevOps），再到更普遍的領域（如雲計算、安全性、測試、監控和警報）。所以，自動化是 IT 優化和數字化轉型的關鍵，能夠縮短實現價值所需的總時長。

步驟 6：推進變革，採用模塊化程度更高的架構。

在微服務開發架構中，應用被拆分紅最小的組件，並彼此獨立。此種軟件開發方案強調高精度、輕量化，力求在多個應用中共享類似的流程。雖然微服務架構不要求使用特定的底層基礎架構，但基於容器的平臺更易於微服務的落地。

經過微服務架構，企業能夠在一天內屢次執行生產部署。從架構的角度來看，微服務需將每個服務拆分紅各自的部署單元。隨後，用戶可單獨管理和部署每一個微服務，而且可能由不一樣的團隊來負責各個微服務的生命週期。可是，實施微服務架構須要必定的投資和技能，企業在引入微服務時，能夠採用 Monolith First 方案，即先構建一個單體式應用。

這樣作的目的是：先充分理解你的應用所屬的域，而後更好地識別其所包含的有限上下文，這些上下文將做爲轉換成微服務的候選內容。這有助於避免技術債務，好比因不瞭解應用的所屬域和有限上下文就構建一組微服務而產生的修復成本。可以支持不一樣的框架、語言和雲原生應用開發方案的企業級 PaaS 平臺（如 OpenShift），是雲原生應用成功的關鍵。

除此以外，在使用微服務後，咱們還應考慮雲原生應用的安全，如認證受權、單點登陸、流量控制等。隨着微服務的普及、業務系統複雜性的增長，咱們還須要考慮 API 治理和業務系統分佈式集成。

內容來源：中生代技術

更多關於基於 OpenShift 構建雲原生應用的內容推薦閱讀《雲原生應用構建：基於 OpenShift》。

做者：魏新宇，紅帽資深解決方案架構師。在 IaaS、PaaS 方面有豐富的經驗，致力於開源解決方案在企業中的推廣和應用。從售前角度主導了紅帽在金融、汽車行業的 PaaS 方面的多個項目。

曾就任於華爲、IBM、VMware，工做涉及領域包括硬件、AIX/Linux、虛擬化、PaaS、DevOps、微服務等。

暢銷書《OpenShift 在企業中的實踐 PaaS DevOps 微服務》《雲原生應用構建：基於 OpenShift》聯合做者。得到紅帽 RHCA Level 5 認證、RHCE 認證，以及 ITIL V三、Cobit五、TOGAF、C-STAR/TOGAF（鑑定級）相關認證。經過「大魏分享」（david-share）微信公衆號，分享了不少項目實踐經驗。

聲明：文章得到做者受權在IDCF社區公衆號（devopshub）轉發。優質內容共享給思否平臺的技術同伴，如原做者有其餘考慮請聯繫小編刪除，致謝。

5月每週四晚8點，【冬哥有話說】質量與測試專場。公衆號留言「質量」可獲取地址，回覆「回放」可獲取回放視頻地址

• 0506 朱少民 《如何最大化軟件測試效能》
• 0513 陳琦 《數據驅動測試》
• 0520 陳霽 《沒錯，去QA是提升質量最有效的方法！》
• 0527 施慧斌 《DevOps實踐之持續測試》