云原生架構定義與原則是什么？

　　云原生架構是云原生中非常重要的一個領域，其帶來的優點可以幫助企業和開發人員改善應用的技術體系，降低現代化應用的構建復雜性，更好地適配與運用云計算平臺的能力和體系的關鍵，那么很多人都不了解云原生架構到底是什么，今天小編就來跟大家一起來學習下。

　　云原生架構的構建和演進都是圍繞云計算的核心價值(彈性、自動化、韌性)進行的，必然在實踐中有一定的規律可循，來一起看下行業內典型的架構原則。

　　云原生架構定義

　　從技術角度來說，云原生架構就是基于云原生技術的一組架構原則和設計模式的集合，主要是為了幫助企業和開發充分利用云平臺所提供的平臺化能力和彈性資源能力，使得開發人員將精力聚焦于業務。

　　當然，云原生架構對比我們傳統架構有很大不同，有以下優點：

　　可以最大化地剝離云應用中的非業務代碼部分，讓云設施接管應用中原有的大量非功能特性(例如，彈性、韌性、安全、可觀測性、灰度等)

　　具備輕量、敏捷、高度自動化等特點

　　可以通過與基礎設施深度整合與優化，將計算、存儲、網絡資源管理以及相應的自動化部署和運維能力，交由云基礎設施執行

　　應用自身會更為靈活，可只聚焦業務代碼，且具有彈性和韌性

　　下面我們就來繼續詳細了解下云原生架構所帶來的相關優勢

　　1、降低研發成本

　　云原生架構大幅度降低了研發成本和項目維護復雜度，那我們就來看下到底做了些什么。

　　首先，所有的應用都有兩類特性：

　　功能性特性：比如，如何建立客戶資料、如何處理訂單、如何安全支付

　　非功能性特性：指雖不能為業務實現帶來直接價值，但又必不可少的特性。比如，高可用能力、容災能力、安全特性、可運維性、易用性、可測試性、灰度發布能力等

　　如上圖，在傳統架構和云原生架構中代碼通常包含的三個部分：

　　非功能性代碼：指實現高可用、安全、可觀測性等非功能特性的代碼

　　業務代碼 ：指實現業務邏輯的核心代碼

　　三方軟件調用：指業務代碼中依賴的所有第三方軟件庫，包括業務庫和基礎庫

　　其中業務代碼最為核心，是真正能為業務帶來直接價值的，另外兩部分都是用于支持業務代碼的實現。

　　但由于軟件和業務規模的不斷擴大，部署環境也越來越復雜，分布式復雜性也持續增強。

　　為了因對這些變化帶來的挑戰，應用中的支持型代碼在整個研發流程中占比越來越大，直接導致了軟件構建變得越來越復雜，也對開發人員的技能要求越來越苛刻。

　　相對于傳統架構，云原生架構強調業務研發應充分利用云平臺所提供的IaaS 和PaaS的通用能力。雖然云計算不能解決所有的非功能性問題，但云平臺確實幫助我們解決了大量非功能性問題，特別是分布式環境下的復雜非功能性問題。

　　舉個例子，比如最具有挑戰的高可用問題，云平臺在多個層面為應用提供了解決方案，如下：

　　1)虛擬機層面

　　當虛擬機檢測到底層硬件異常時，可以自動將應用熱遷移，且遷移后的應用無須重新啟動就具備對外服務的能力，應用對整個遷移過程甚至都不會有任何感知。

　　2)容器層面

　　有時，雖然應用所在的物理機運行正常，但應用由于自身的問題(比如，出現Bug、資源耗盡等)而無法正常對外提供服務。

　　對于這種情況，如果采用容器，就能夠通過監控探測到進程的異常狀態，從而實施異常節點下線、新節點上線和生產流量切換等操作。

　　整個過程自動完成，無須運維人員人工干預

　　3) 云服務層面

　　云服務具備極強的高可用特性和7×24小時服務能力，如果應用把“有狀態”部分(如緩存、數據庫、對象存儲等)全部交給云服務，加上進程內存中全局對象的持有小型化和應用快速重構能力(比如基于快照快速恢復到最新狀態)，那么應用本身就會變成更輕量的“無狀態”應用，從而使可用性故障造成的業務中斷時間降至分鐘級;

　　如果應用采用的是N-M對等架構模式，那么結合負載均衡產品則可獲得幾乎無損的高可用能力

　　綜上所述，借助云原生架構，業務研發可以降低原本大量耦合的非業務邏輯占比，縮減業務代碼開發人員的技術關注范圍，并通過云平臺提供的服務提升應用的穩定性和可持續發展性

　　2、加快迭代速度

　　云原生架構的應用，能夠最大程度地利用云服務提升軟件的交付能力，進一步加快軟件的迭代速度，降低管理和運行的成本

　　1)面向單機資源變為面向云服務與云API研發

　　云原生架構對開發人員的最大影響就是，它使編程模型發生了巨大變化。

　　大部分編程語言都包含文件、網絡、線程等技術細節，這些技術點可以幫助開發者充分利用單機資源，但也為開發帶來了復雜性，因此出現大量的框架和產品來為我們解決分布式環境中網絡調用、高可用、CPU競爭、分布式存儲等問題。

　　而在云平臺中，“獲取存儲”變成了若干服務。比如，對象存儲服務、塊存儲服務和文件存儲服務的訪問和使用等。

　　云原生為開發人員提供了解決上述問題的技術支持：

　　通過OpenAPI及開源SDK，提供了解決分布式場景中的高可用性、自動擴縮容、安全、運維升級等諸多挑戰的界面

　　開發人員不用再關心諸如節點宕機后如何在代碼中將本地保存的內容同步到遠端

　　開發人員不用擔心當業務峰值到來時如何對存儲節點進行擴容

　　運維人員不用再考慮諸如在發現零安全天問題時如何緊急升級第三方存儲軟件等問題

　　這些改變不僅降低了開發者的工作難度，也大大提高了軟件的性能和可維護性。

　　云平臺將軟硬件能力升級成了服務，使開發人員的開發復雜度和運維人員的運維工作量都得到了極大降低

　　開發人員不再需要掌握文件及其分布式處理技術，也不再需要掌握各種復雜的網絡技術，技術棧的簡化讓業務開發變得更敏捷

　　2)高度自動化的軟件交付能力

　　公司環境與客戶環境之間的差異，以及軟件交付與運維人員的技能差異，都會影響軟件交付的質量。

　　以往用于填補這些差異的是各種用戶手冊、安裝手冊、運維手冊和培訓文檔，容器的出現改變了這一現狀。

　　容器就像集裝箱一樣，以一種標準的方式對軟件進行打包，利用容器及其相關技術屏蔽了不同環境之間的差異，提供了標準化的軟件交付能力。

　　基于云原生的自動化軟件交付相較于當前的人工軟件交付，是一個巨大的進步。

　　以微服務為例，應用微服務化以后，往往會被部署到成千上萬個節點上，如果系統不具備高度的自動化能力，那么任何一次新業務的上線，都將帶來極大的工作量挑戰，嚴重時還會導致業務部署時長超過上線窗口期而不可用。

　　云原生架構原則

　　作為一種架構模式，云原生架構也必然有若干原則來對應用架構進行核心控制。這些原則可以幫助架構師在進行技術選型時更加高效、準確，下面一起來學習下。

　　1、服務化原則

　　在軟件開發過程中，當代碼數量與開發團隊規模都擴張到一定程度后，就需要重構應用，通過模塊化與組件化的手段分離關注點，降低應用的復雜度，提升軟件的開發效率，降低維護成本

　　如圖，隨著業務的不斷發展，單體應用能夠承載的容量將逐漸到達上限，即使通過應用改造來突破垂直擴展(Scale Up)的瓶頸，并將其轉化為支撐水平擴展(Scale Out)的能力，在全局并發訪問的情況下，也依然會面臨數據計算復雜度和存儲容量的問題。

　　因此，需要將單體應用進一步拆分，按業務邊界重新劃分成分布式應用，使應用與應用之間不再直接共享數據，而是通過約定好的契約進行通信，以提高擴展性

　　服務化設計原則：

　　通過服務化架構拆分不同生命周期的業務單元，實現業務單元的獨立迭代，從而加快整體的迭代速度，保證迭代的穩定性

　　服務化架構采用的是面向接口編程方式，增加了軟件的復用程度，增強了水平擴展的能力

　　在架構層面抽象化業務模塊之間的關系，幫助業務模塊實現基于服務流量(而非網絡流量)的策略控制和治理，無須關注這些服務是基于何種編程語言開發的

　　雖然隨著云原生興起，服務化原則不斷演進、落地于實際業務，但企業在實際落地過程中也會遇到不少的挑戰。比如：

　　與自建數據中心相比，公有云下的服務化可能存在巨大的資源池，使得機器錯誤率顯著提高;

　　按需付費增加了擴縮容的操作頻度;

　　新的環境要求應用啟動更快、應用與應用之間無強依賴關系、應用能夠在不同規格的節點之間隨意調度等諸多需要考慮的實際問題。

　　但可以預見的是，這些問題會隨著云原生架構的不斷演進而得到逐一解決。

　　2、彈性原則

　　彈性原則是指系統部署規?？梢噪S著業務量變化自動調整大小，而無須根據事先的容量規劃準備固定的硬件和軟件資源。

　　優秀的彈性能力不僅能夠改變企業的IT成本模式，使得企業不用再考慮額外的軟硬件資源成本支出(閑置成本)，也能更好地支持業務規模的爆發式擴張。

　　在云原生時代，企業在構建IT系統時，應該盡早考慮讓應用架構具備彈性能力，以便在快速發展的業務規模面前靈活應對各種場景需求，充分利用云原生技術及成本優勢。

　　要想構建彈性的系統架構，需要遵循如下四個基本原則：

　　1)按功能切割應用

　　大型復雜系統可能由成百上千個服務組成，架構師在設計架構時，需要遵循的原則是：

　　將相關的邏輯放到一起，不相關的邏輯拆解到獨立的服務中

　　各服務之間通過標準的服務發現(Service Discovery)找到對方，并使用標準的接口進行通信

　　各服務之間松耦合，每一個服務能夠各自獨立地完成彈性伸縮，從而避免服務上下游關聯故障的發生

　　2)支持水平切分

　　按功能切割應用并沒有完全解決彈性的問題。一個應用被拆解為眾多服務后，隨著用戶流量的增長，單個服務最終也會遇到系統瓶頸。

　　因此在設計上，每個服務都需要具備可水平切分的能力，以便將服務切分為不同的邏輯單元，由每個單元處理一部分用戶流量，從而使服務自身具備良好的擴展能力。

　　這其中最大的挑戰在于數據庫系統，因為數據庫系統自身是有狀態的，所以合理地切分數據并提供正確的事務機制將是一個非常復雜的工程。

　　在云原生時代，云平臺所提供的云原生數據庫服務可以解決大部分復雜的分布式系統問題，因此，如果企業是通過云平臺提供的能力來構建彈性系統，自然就會擁有數據庫系統的彈性能力。

　　3)自動化部署

　　系統突發流量通常無法預計，因此常用的解決方案是，通過人工擴容系統的方式，使系統具備支持更大規模用戶訪問的能力。

　　在完成架構拆分之后，彈性系統還需要具備自動化部署能力，以便根據既定的規則或者外部流量突發信號觸發系統的自動化擴容功能。

　　滿足系統對于縮短突發流量影響時長的及時性要求，同時在峰值時段結束后自動縮容系統，降低系統運行的資源占用成本。

　　4)支持服務降級

　　彈性系統需要提前設計異常應對方案。

　　比如，對服務進行分級治理，在彈性機制失效、彈性資源不足或者流量峰值超出預期等異常情況下，系統架構需要具備服務降級的能力。

　　通過降低部分非關鍵服務的質量，或者關閉部分增強功能來讓出資源，并擴容重要功能對應的服務容量，以確保產品的主要功能不受影響。

　　隨著云原生技術的發展，FaaS、Serverless等技術生態逐步成熟，構建大規模彈性系統的難度逐步降低。當企業以FaaS、Serverless等技術理念作為系統架構的設計原則時，系統就具備了彈性伸縮的能力。

　　3、可觀測原則

　　與監控、業務探活、APM(Application Performance Management，應用性能管理)等系統提供的被動能力不同，可觀測性更強調主動性。

　　在云計算這樣的分布式系統中，主動通過日志、鏈路跟蹤和度量等手段，讓一次App點擊所產生的多次服務調用耗時、返回值和參數都清晰可見，甚至可以下鉆到每次第三方軟件調用、SQL請求、節點拓撲、網絡響應等信息中。

　　在微服務架構中，系統的故障點可能出現在任何地方，因此我們需要針對可觀測性進行體系化設計，以降低MTTR(故障平均修復時間)。

　　構建可觀測性體系，需要遵循如下三個基本原則：

　　1)數據的全面采集

　　指標(Metric)、鏈路跟蹤(Tracing)和日志(Logging)這三類數據是構建一個完整的可觀測性系統的“三大支柱”。

　　而系統的可觀測性就是需要完整地采集、分析和展示這三類數據。

　　指標：

　　是指在多個連續的時間周期里用于度量的KPI數值。一般情況下，指標會按軟件架構進行分層，分為：

　　系統資源指標(如CPU使用率、磁盤使用率和網絡帶寬情況等)

　　應用指標(如出錯率、服務等級協議SLA、服務滿意度APDEX、平均延時等)

　　業務指標(如用戶會話數、訂單數量和營業額等)

　　鏈路跟蹤

　　鏈路跟蹤是指通過TraceId的唯一標識來記錄并還原發生一次分布式調用的完整過程，貫穿數據從瀏覽器或移動端經過服務器處理，到執行SQL或發起遠程調用的整個過程。

　　日志

　　日志通常用來記錄應用運行的執行過程、代碼調試、錯誤異常等信息，如Nginx日志可以記錄遠端IP、發生請求時間、數據大小等信息。日志數據需要集中化存儲，并具備可檢索的能力。

　　2)數據的關聯分析

　　讓各數據之間產生更多的關聯，這一點對于一個可觀測性系統而言尤為重要。

　　出現故障時，有效的關聯分析可以實現對故障的快速定界與定位，從而提升故障處理效率，減少不必要的損失。

　　一般情況下，會將應用的服務器地址、服務接口等信息作為附加屬性，與指標、調用鏈、日志等信息綁定，并且賦予可觀測系統一定的定制能力，以便靈活滿足更加復雜的運維場景需求。

　　3)統一監控視圖與展現

　　多種形式、多個維度的監控視圖可以幫助運維和開發人員快速發現系統瓶頸，消除系統隱患。

　　監控數據的呈現形式應該不僅僅是指標趨勢圖表、柱狀圖等，還需要結合復雜的實際應用場景需要，讓視圖具備下鉆分析和定制能力，以滿足運維監控、版本發布管理、故障排除等多場景需求。

　　隨著云原生技術的發展，基于異構微服務架構的場景會越來越多、越來越復雜，而可觀測性是一切自動化能力構建的基礎。只有實現全面的可觀測性，才能真正提升系統的穩定性、降低MTTR。

　　4、韌性原則

　　韌性是指當軟件所依賴的軟硬件組件出現異常時，軟件所表現出來的抵御能力。

　　這些異常通常包括：

　　·硬件故障

　　·硬件資源瓶頸(如CPU或網卡帶寬耗盡)

　　·業務流量超出軟件設計承受能力

　　·影響機房正常工作的故障或災難

　　·所依賴軟件發生故障

　　韌性能力的核心設計理念是面向失敗設計，即考慮如何在各種依賴不正常的情況下，減小異常對系統及服務質量的影響并盡快恢復正常。

　　韌性原則的實踐與常見架構主要包括：

　　·服務異步化能力

　　·重試/限流/降級/熔斷/反壓

　　·主從模式

　　·集群模式

　　·多AZ(Availability Zone，可用區)的高可用

　　·單元化

　　·區域(Region)容災

　　·異地多活容災

　　5、所有過程自動化原則

　　技術是把“雙刃劍”，容器、微服務、DevOps以及大量第三方組件的使用，在降低分布式復雜性和提升迭代速度的同時，也提高了軟件技術棧的復雜度，加大了組件規模，從而不可避免地導致了軟件交付的復雜性。

　　如果控制不當，應用就會無法體會到云原生技術的優勢。不過通過IaC、GitOps、OAM、Operator和大量自動化交付工具在CI/CD(持續集成/持續交付)流水線中的實踐，企業可以標準化企業內部的軟件交付過程，也可以在標準化的基礎上實現自動化。

　　要想實現大規模的自動化，需要遵循如下四個基本原則：

　　1)標準化

　　實施自動化，首先要通過容器化、IaC、OAM等手段，標準化業務運行的基礎設施，并進一步標準化對應用的定義乃至交付的流程。

　　只有實現了標準化，才能解除業務對特定的人員和平臺的依賴，實現業務統一和大規模的自動化操作。

　　2)面向終態

　　面向終態是指聲明式地描述基礎設施和應用的期望配置，持續關注應用的實際運行狀態，使系統自身反復地變更和調整直至趨近終態的一種思想。

　　面向終態的原則強調應該避免直接通過工單系統、工作流系統組裝一系列過程式的命令來變更應用，而是通過設置終態，讓系統自己決策如何執行變更。

　　以系統為例，面向終態描述了系統的最終形態，用戶只需要描述自己需要什么，不需要詳細規劃執行路徑，系統會根據線上的實時狀況以及運維知識庫來動態調整，來達到系統安全穩定的目的。

　　舉個通俗易懂的例子，在灰度過程中，會根據灰度的需求來自動執行灰度策略來動態分配流量

　　3)關注點分離

　　自動化最終所能達到的效果不只取決于工具和系統的能力，更取決于為系統設置目標的人，因此要確保找到正確的目標設置人。

　　在描述系統終態時，要將應用研發、應用運維、基礎設施運維這幾種主要角色所關注的配置分離開來。

　　各個角色只需要設置自己所關注和擅長的系統配置，以便確保設定的系統終態是合理的

　　4)面向失敗設計

　　要想實現全部過程自動化，一定要保證自動化的過程是可控的，對系統的影響是可預期的。

　　我們不能期望自動化系統不犯錯誤，但可以保證即使是在出現異常的情況下，錯誤的影響范圍也是可控的、可接受的。

　　因此，自動化系統在執行變更時，同樣需要遵循人工變更的最佳實踐，保證變更是可灰度執行的、執行結果是可觀測的、變更是可快速回滾的、變更影響是可追溯的。

　　6、零信任原則

　　基于邊界模型的傳統安全架構設計，是在可信和不可信的資源之間架設一道墻，例如，公司內網是可信的，而因特網則是不可信的。

　　在這種安全架構設計模式下，一旦入侵者滲透到邊界內，就能夠隨意訪問邊界內的資源了

　　云原生架構的應用、員工遠程辦公模式的普及以及用手機等移動設備處理工作的現狀，已經完全打破了傳統安全架構下的物理邊界。員工在家辦公也可以實現與合作方共享數據，因為應用和數據被托管到了云上。

　　如今，邊界不再是由組織的物理位置來定義，而是已經擴展到了需要訪問組織資源和服務的所有地方，傳統的防火墻和VPN已經無法可靠且靈活地應對這種新邊界。

　　因此，我們需要一種全新的安全架構，來靈活適應云原生和移動時代環境的特性，不論員工在哪里辦公，設備在哪里接入，應用部署在哪里，數據的安全性都能夠得到有效保護。如果要實現這種新的安全架構，就要依托零信任模型

　　零信任模型假設防火墻邊界已經被攻破，且每個請求都來自于不可信網絡，因此每個請求都需要經過驗證。

　　簡單來說，“永不信任，永遠驗證”。

　　在零信任模型下，每個請求都要經過強認證，并基于安全策略得到驗證授權，與請求相關的用戶身份、設備身份、應用身份等，都會作為核心信息來判斷請求是否安全。

　　如果圍繞邊界來討論安全架構，那么傳統安全架構的邊界是物理網絡，而零信任安全架構的邊界則是身份，這個身份包括人的身份、設備的身份、應用的身份等。

　　要想實現零信任安全架構，需要遵循如下三個基本原則：

　　顯式驗證：

　　對每個訪問請求都進行認證和授權。認證和授權需要基于用戶身份、位置、設備信息、服務和工作負載信息以及數據分級和異常檢測等信息來進行。

　　例如，對于企業內部應用之間的通信，不能簡單地判定來源IP是內部IP就直接授權訪問，而是應該判斷來源應用的身份和設備等信息，再結合當前的策略授權

　　最少權限：

　　對于每個請求，只授予其在當下必需的權限，且權限策略應該能夠基于當前請求上下文自適應。

　　例如，HR部門的員工應該擁有訪問HR相關應用的權限，但不應該擁有訪問財務部門應用的權限

　　假設被攻破：

　　假設物理邊界被攻破，則需要嚴格控制安全爆炸半徑，將一個整體的網絡切割成對用戶、設備、應用感知的多個部分。

　　對所有的會話加密，使用數據分析技術保證對安全狀態的可見性。

　　總體來說，整個零信任模型的建設包括身份、設備、應用、基礎設施、網絡、數據等幾個部分。

　　零信任的實現是一個循序漸進的過程。

　　例如，當組織內部傳輸的所有流量都沒有加密的時候第一步應該先保證訪問者訪問應用的流量是加密的，然后再逐步實現所有流量的加密。

　　如果采用云原生架構，就可以直接使用云平臺提供的安全基礎設施和服務，以便幫助企業快速實現零信任架構。