雲原生架構成功的6大原則
雲原生架構是一種在雲環境中從頭開始構建應用程式的設計模式。雖然雲原生架構沒有硬性規則,但大多數雲原生應用程式都是由微服務組織而成。微服務主要用於將應用程式分解為可由小型團隊維護的自治、鬆散耦合的單元,每個微服務通常部署為一個容器或一組容器。
此外,雲原生應用通常遵循12因素應用框架的原則。它們圍繞以下方面構建:
效能:應用程式在設計時考慮可擴充套件性,旨在在規模上表現良好。
彈性:應用程式由伸縮性良好的小型、可擴充套件的元件構建而成。
韌性:應用程式對故障具有很強的復原能力,可自動更換髮生故障的元件且不會中斷其他元件的執行。
安全性:在構建應用程式時考慮安全性,確保應用程式或其資料不被攻擊者破壞。
原生架構原則
在構建雲原生應用程式時,首先應構建一個可以在多個維度上不斷移動的系統,以實現動態擴充套件,自動處理故障,並儘可能輕鬆的新增或刪除元件。以下幾個原則可以使構建的雲原生架構更加強大、更加適應變化並且更容易維護。
01自動化設計
建立可以部署、修復和擴充套件系統的自動化流程,並且生成相關日誌和事件。構建系統以自動處理:
提供的基礎架構,如機器例項;
CI/CD 管道中的生成、測試和部署階段;
基於工作負載或其他應用程式要求的動態可擴充套件性;
備份、執行狀況監視和故障恢復。
02儘可能保持無狀態
雖然一些雲原生純粹主義者認為雲原生應用程式應該是無狀態的,但在現實世界中可能很難實現無狀態應用程式的開發。然而也應儘可能使用無狀態元件,因為跟蹤分散式應用程式中的管理狀態(如當前正在執行的例項數)是困難的。無狀態元件使擴充套件(新增更多副本)、修復(刪除並替換為新例項)、回滾和工作負載平衡(無需關心哪個例項正在處理哪些事務的複雜邏輯)變得更加容易。
03彈性設計
透過在設計中新增冗餘將彈性構建到雲原生應用程式中。雲原生應用程式透過使用例項叢集、資料複製以及多可用區或多區域雲部署來避免單點故障。那些必須在本地執行的應用程式應使用混合架構利用公有云以實現高可用性和災難恢復,至少對於其某些元件而言。
一些常見的彈性機制:
能夠識別由連線丟失或服務超時等臨時問題引起的暫時性故障,進行重試請求;
實現斷路器模式,檢查重試操作的次數,並在後續重試時返回錯誤而不啟用服務;
允許服務在它們所依賴的其他服務出現故障時正常降級,並且仍提供合理的使用者體驗;
根據應用程式的使用速率限制和節流來識別和限制大容量使用者;
使用補償事務,將業務事務分解為一系列較小的事務,更容易在分散式系統中實現事務一致性。
04使用微邊界構建每個元件
雲原生應用不僅應該從一開始就設計安全性,還應該在假設沒有可信任元件的情況下進行設計。因為應用程式與其使用者之間,甚至內部元件之間可能沒有專用網路,此時應該致力於強化所有元件、加密資料並在元件之間實現身份驗證,使應用程式更具彈性,並能夠在不受信任的環境中靈活地部署元件。
05構建多語言架構
雲原生應用不需要高度整合的架構、使用相同語言編寫的元件以及使用相同的技術和框架。由於REST API可以公開每個元件的功能,允許異構元件相互通訊和使用,因此可以在充分考慮團隊能力之後,使用能夠提供最大價值和最快上市時間的語言或技術編寫每個元件。
06元件不可變
透過基礎架構元件不可變以引入高階別的敏捷性和靈活性。這也就意味著不允許在部署後對配置伺服器或虛擬機器(VM)進行修改。
在部署不可變伺服器後,就可以不再對其進行修改,相反,若沒有部署不可變伺服器,則應確保已部署的伺服器保持原樣且不進行任何修改,以便如果出現問題也可以快速輕鬆地更換伺服器並保持應用程式執行。
以下是使用不可變基礎架構的幾個主要優點:
不可變元件有助於實現一致且可靠的基礎架構,使測試變得更加簡單明瞭。
部署不可變元件可以更簡單、更可預測。
不可變元件的每次部署都是版本化和自動化,這使得環境回滾更加容易和簡單。
配置飄逸、雪花伺服器和錯誤得到緩解,甚至完全消除。
使用雲服務時,自動伸縮也毫不費力。
可變伺服器會增加成本和迭代時間,嚴重延遲上市時間,不可變的基礎設施則促進了敏捷開發。不可變基礎架構可提高已部署環境的可靠性、一致性和效率,開發人員可以在幾分鐘內重新建立環境。
雲原生架構的優缺點
雲原生架構有許多優點:
(1)成本:雲提供低成本選項,確保系統不間斷執行,為客戶提供服務,此外還可以利用各種雲交付功能。若在企業內部提供這些功能,則既耗時又昂貴。
(2)可靠性:雲環境提供彈性和可靠性選項,例如可用性區域,可以確保系統永遠不會出現故障,免受中斷的影響,因此避免停機造成的不可挽回的損失。
(3)敏捷性:敏捷開發需要不斷的測試和最佳化,這在傳統的整體架構中是很困難的,因為一個小小的改變可能會破壞整個系統。雲原生系統在構建時考慮了持續變化,因此可以更輕鬆地更新和調整應用程式。
(4)靈活性:雲原生設計與平臺無關,因此若當前系統不適合開發,可以切換到新環境,而不必從頭開始重新編譯。
雲原生架構的缺點包括:
(1)解決問題:在傳統體系架構中可以遵循線性計劃來識別問題。而云原生設計存在複雜網路中相互連線和互動的容器,並且特定元件集之間的路徑可能不明確。如果問題的根源分散在多個容器中,則可能更難找出根本原因。
(2)安全性:由於系統是由大量動態分散式元件構成,雲原生架構通常更難以監控和保護。
(3)知識差距:如果開發人員不熟悉雲原生系統,則需要重新學習,就像使用新語言一樣,重要的是需要能夠很好地理解新概念,以避免造成嚴重損失的錯誤。
在考慮構建新的雲原生架構時,企業組織需要仔細權衡各種優缺點,以便為業務、客戶和利益相關者做出正確的決策。
來自 “ 懸鏡安全實驗室 ”, 原文作者:懸鏡安全實驗室;原文連結:https://page.om.qq.com/page/OXbbjCKG53LDmVPZlNgH0Rfg0,如有侵權,請聯絡管理員刪除。
相關文章
- 雲端計算架構設計6大原則遵循了哪些?架構
- 雲原生架構的七個原則架構
- 雲原生架構及設計原則架構
- 架構設計的五大原則-SOLID架構Solid
- 360°透視:雲原生架構及設計原則架構
- 設計模式“6”大原則!設計模式
- 雲原生架構概述架構
- 雲原生架構白皮書學習筆記(6):主要雲原生技術-Serverless架構筆記Server
- 連續架構六大原則 - Murat Erder架構
- 分散式系統架構與雲原生—阿里雲《雲原生架構白皮書》導讀分散式架構阿里
- 快速瞭解雲原生架構架構
- 雲原生系列6 基於springcloud架構風格的本地debug實現SpringGCCloud架構
- Java的設計模式和6大原則Java設計模式
- 物件導向設計的6大原則物件
- 【開源力量】雲原生架構概述架構
- 聊聊雲原生和微服務架構微服務架構
- 制定企業績效管理的6大原則
- [雲原生微服務架構](十)微服務架構的基礎知識微服務架構
- 設計模式的七大原則(6) --迪米特法則設計模式
- Apache Druid 在 Shopee 的雲原生架構演進ApacheUI架構
- 深入探索雲原生流水線的架構設計架構
- 構建雲原生安全的6個重要能力
- 雲原生架構實施路線圖架構
- 用友雲平臺,真正的雲原生架構,加速雲應用落地架構
- 2024年的雲原生架構需要哪些技術棧架構
- 雲原生架構實施路線圖分析架構
- Dapr閃電說 - Dapr落地雲原生架構架構
- [雲原生微服務架構](九)入門HELM微服務架構
- 奈學p7雲原生架構師架構
- .NET 雲原生架構師訓練營(設計原則&&設計模式)--學習筆記架構設計模式筆記
- 架構師成長系列 | 雲原生時代的 DevOps 之道架構dev
- 我對雲原生軟體架構的觀察與思考架構
- 銀行基於雲原生架構下的 DevOps 建設架構dev
- 雲原生架構下的微服務選型和演進架構微服務
- .NET 雲原生架構師訓練營(系統架構)--學習筆記架構筆記
- 淺析雲原生應用安全組織架構架構
- 雲原生架構日誌監控最佳實踐架構
- H5架構和原生架構的區別H5架構