# 云原生的設計哲學 云原生一詞已經被過度的采用，很多軟件都號稱是云原生，很多打著云原生旗號的會議也如雨后春筍般涌現。 云原生本身甚至不能稱為是一種架構，它首先是一種基礎設施，運行在其上的應用稱作云原生應用，只有符合云原生設計哲學的應用架構才叫云原生應用架構。 ## 云原生的設計理念 云原生系統的設計理念如下: - 面向分布式設計（Distribution）：容器、微服務、API 驅動的開發； - 面向配置設計（Configuration）：一個鏡像，多個環境配置； - 面向韌性設計（Resistancy）：故障容忍和自愈； - 面向彈性設計（Elasticity）：彈性擴展和對環境變化（負載）做出響應； - 面向交付設計（Delivery）：自動拉起，縮短交付時間； - 面向性能設計（Performance）：響應式，并發和資源高效利用； - 面向自動化設計（Automation）：自動化的 DevOps； - 面向診斷性設計（Diagnosability）：集群級別的日志、metric 和追蹤； - 面向安全性設計（Security）：安全端點、API Gateway、端到端加密； 以上的設計理念很多都是繼承自分布式應用的設計理念。雖然有如此多的理念但是我們仍然無法辨認什么樣的設施才是云原生基礎設施，不過可以先用排除法，我將解釋什么不是云原生基礎設施。 ## 什么不是云原生基礎設施？ 云原生基礎設施不僅是在公有云上運行基礎設施。僅僅因為你從其他人那里租用服務器時間并不會使您的基礎設施云原生化。管理IaaS的流程通常與運行物理數據中心沒有什么不同，許多將現有基礎架構遷移到云的公司都未能獲得回報。 云原生不是關于在容器中運行應用程序。當Netflix率先推出云原生基礎設施時，幾乎所有應用程序都部署了虛擬機映像，而不是容器。打包應用程序的方式并不意味著您將擁有自治系統的可擴展性和優勢。即使您的應用程序是通過持續集成和持續交付渠道自動構建和部署的，這并不意味著您可以從可以補充API驅動部署的基礎設施中受益。 這也并不意味著你只能運行容器編排器（例如Kubernetes和Mesos）。容器編排器提供了云原生基礎設施所需的許多平臺功能，但并未按預期方式使用這些功能，這意味著您的應用程序會被動態調度以在一組服務器上運行。這是一個非常好的起步，但仍有工作要做。 > **調度器與編排器** > > 術語“調度器”和“編排器”通常可以互換使用。 > > 在大多數情況下，編排器負責集群中的所有資源利用（例如：存儲，網絡和CPU）。該術語典型地用于描述執行許多任務的產品，如健康檢查和云自動化。 調度器是編排平臺的一個子集，僅負責選擇運行在每臺服務器上的進程和服務。 云原生不是微服務或基礎設施即代碼。微服務意味著更快的開發周期和更小的獨特功能，但是單片應用程序可以具有相同的功能，使其能夠通過軟件有效管理，并且還可以從云原生基礎設施中受益。 基礎設施即代碼以機器可解析語言或領域特定語言（DSL）定義、自動化您的基礎設施。將代碼應用于基礎架構的傳統工具包括配置管理工具（例如Chef和Puppet）。這些工具在自動執行任務和提供一致性方面有很大幫助，但是它們在提供必要的抽象來描述超出單個服務器的基礎設施方面存在缺陷。 配置管理工具一次自動化一臺服務器，并依靠人員將服務器提供的功能綁定在一起。這將人類定位為基礎設施規模的潛在瓶頸。這些工具也不會使構建完整系統所需的云基礎設施（例如存儲和網絡）的額外部分自動化。 盡管配置管理工具為操作系統的資源（例如軟件包管理器）提供了一些抽象，但它們并沒有抽象出足夠的底層操作系統來輕松管理它。如果一位工程師想要管理系統中的每個軟件包和文件，這將是一個非常艱苦的過程，并且對于每個配置變體都是獨一無二的。同樣，定義不存在或不正確的資源的配置管理僅消耗系統資源并且不能提供任何價值。 雖然配置管理工具可以幫助自動化部分基礎設施，但它們無法更好地管理應用程序。我們將在后面的章節中通過查看部署，管理，測試和操作基礎架構的流程，探討云原生基礎設施的不同之處，但首先，我們將了解哪些應用程序是成功的以及應該何時與原生基礎設施一起使用。 ## 云原生應用程序 就像云改變了業務和基礎設施之間的關系一樣，云原生應用程序也改變了應用程序和基礎設施之間的關系。我們需要了解與傳統應用程序相比，云本身有什么不同，因此我們需要了解它們與基礎設施的新關系。 為了寫好本書，也為了有一個共享詞匯表，我們需要定義“云原生應用程序”是什么意思。云原生與12因素應用程序不同，即使它們可能共享一些類似的特征。如果你想了解更多細節，請閱讀Kevin Hoffman撰寫的“超越12因素應用程序”（O'Reilly，2012）。 云原生應用程序被設計為在平臺上運行，并設計用于彈性，敏捷性，可操作性和可觀察性。彈性包含失敗而不是試圖阻止它們;它利用了在平臺上運行的動態特性。敏捷性允許快速部署和快速迭代。可操作性從應用程序內部控制應用程序生命周期，而不是依賴外部進程和監視器。可觀察性提供信息來回答有關應用程序狀態的問題。 > **云原生定義** > > 云原生應用程序的定義仍在發展中。還有像CNCF這樣的組織可以提供其他的定義。 云原生應用程序通過各種方法獲取這些特征。它通常取決于應用程序的運行位置以及企業流程和文化。以下是實現云原生應用程序所需特性的常用方法： - 微服務 - 健康報告 - 遙測數據 - 彈性 - 聲明式的，而不是反應式的 ### 微服務 作為單個實體進行管理和部署的應用程序通常稱為單體應用。最初開發應用程序時，單體有很多好處。它們更易于理解，并允許您在不影響其他服務的情況下更改主要功能。 隨著應用程序復雜性的增長，單體應用的益處逐漸減少。它們變得更難理解，而且失去了敏捷性，因為工程師很難推斷和修改代碼。 對付復雜性的最好方法之一是將明確定義的功能分成更小的服務，并讓每個服務獨立迭代。這增加了應用程序的靈活性，允許根據需要更輕松地更改部分應用程序。每個微服務可以由單獨的團隊進行管理，使用適當的語言編寫，并根據需要進行獨立擴縮容。 只要每項服務都遵守強有力的合約，應用程序就可以快速改進和改變。當然，轉向微服務架構還有許多其他的考慮因素。其中最不重要的是彈性通信，我們在附錄A中有討論。 我們無法考慮轉向微服務的所有考慮因素。擁有微服務并不意味著您擁有云原生基礎設施。如果您想閱讀更多，我們推薦Sam Newman的Building Microservices（O'Reilly，2015）。雖然微服務是實現您的應用程序靈活性的一種方式，但正如我們之前所說的，它們不是云原生應用程序的必需條件。 ### 健康報告 > 停止逆向工程應用程序并開始從內部進行監控。 —— Kelsey Hightower，Monitorama PDX 2016：healthz 沒有人比開發人員更了解應用程序需要什么才能以健康的狀態運行。很長一段時間，基礎設施管理員都試圖從他們負責運行的應用程序中找出“健康”該怎么定義。如果不實際了解應用程序的健康狀況，他們嘗試在應用程序不健康時進行監控并發出警報，這往往是脆弱和不完整的。 為了提高云原生應用程序的可操作性，應用程序應該暴露健康檢查。開發人員可以將其實施為命令或過程信號，以便應用程序在執行自我檢查之后響應，或者更常見的是：通過應用程序提供Web服務，返回HTTP狀態碼來檢查健康狀態。 > **Google Borg示例** > > Google的Borg報告中列出了一個健康報告的例子： > > 幾乎每個在Borg下運行的任務都包含一個內置的HTTP服務器，該服務器發布有關任務運行狀況和數千個性能指標（如RPC延遲）的信息。Borg會監控運行狀況檢查URL并重新啟動不及時響應或返回HTTP錯誤代碼的任務。其他數據由監控工具跟蹤，用于儀表板和服務級別目標（SLO）違規警報。 將健康責任轉移到應用程序中使應用程序更容易管理和自動化。應用程序應該知道它是否正常運行以及它依賴于什么（例如，訪問數據庫）來提供業務價值。這意味著開發人員需要與產品經理合作來定義應用服務的業務功能并相應地編寫測試。 提供健康檢查的應用程序示例包括Zookeeper的ruok命令和etcd的HTTP / 健康端點。 應用程序不僅僅有健康或不健康的狀態。它們將經歷一個啟動和關閉過程，在這個過程中它們應該通過健康檢查，報告它們的狀態。如果應用程序可以讓平臺準確了解它所處的狀態，平臺將更容易知道如何操作它。 一個很好的例子就是當平臺需要知道應用程序何時可以接收流量。在應用程序啟動時，如果它不能正確處理流量，它就應該表現為未準備好。此額外狀態將防止應用程序過早終止，因為如果運行狀況檢查失敗，平臺可能會認為應用程序不健康，并且會反復停止或重新啟動它。 應用程序健康只是能夠自動化應用程序生命周期的一部分。除了知道應用程序是否健康之外，您還需要知道應用程序是否正在進行哪些工作。這些信息來自遙測數據。 ### 遙測數據 遙測數據是進行決策所需的信息。確實，遙測數據可能與健康報告重疊，但它們有不同的用途。健康報告通知我們應用程序生命周期狀態，而遙測數據通知我們應用程序業務目標。 您測量的指標有時稱為服務級指標（SLI）或關鍵性能指標（KPI）。這些是特定于應用程序的數據，可以確保應用程序的性能處于服務級別目標（SLO）內。如果您需要更多關于這些術語的信息以及它們與您的應用程序、業務需求的關系，我們推薦你閱讀來自Site Reliability Engineering（O'Reilly）的第4章。 遙測和度量標準用于解決以下問題： - 應用程序每分鐘收到多少請求？ - 有沒有錯誤？ - 什么是應用程序延遲？ - 訂購需要多長時間？ 通常會將數據刮取或推送到時間序列數據庫（例如Prometheus或InfluxDB）進行聚合。遙測數據的唯一要求是它將被收集數據的系統格式化。 至少，可能最好實施度量標準的RED方法，該方法收集應用程序的速率，錯誤和執行時間。 **請求率** 收到了多少個請求 **錯誤** 應用程序有多少錯誤 **時間** 多久才能收到回復 遙測數據應該用于提醒而非健康監測。在動態的、自我修復的環境中，我們更少關注單個應用程序實例的生命周期，更多關注關于整體應用程序SLO的內容。健康報告對于自動應用程序管理仍然很重要，但不應該用于頁面工程師。 如果1個實例或50個應用程序不健康，只要滿足應用程序的業務需求，我們可能不會收到警報。度量標準可讓您知道您是否符合您的SLO，應用程序的使用方式以及對于您的應用程序來說什么是“正常”。警報有助于您將系統恢復到已知的良好狀態。 > 如果它移動，我們跟蹤它。有時候我們會畫出一些尚未移動的圖形，以防萬一它決定為它運行。 > > ——Ian Malpass，衡量所有，衡量一切 警報也不應該與日志記錄混淆。記錄用于調試，開發和觀察模式。它暴露了應用程序的內部功能。度量有時可以從日志（例如錯誤率）計算，但需要額外的聚合服務（例如ElasticSearch）和處理。 ### 彈性 一旦你有遙測和監測數據，你需要確保你的應用程序對故障有適應能力。彈性是基礎設施的責任，但云原生應用程序也需要承擔部分工作。 基礎設施被設計為抵制失敗。硬件用于需要多個硬盤驅動器，電源以及全天候監控和部件更換以保持應用程序可用。使用云原生應用程序，應用程序有責任接受失敗而不是避免失敗。 > 在任何平臺上，尤其是在云中，最重要的特性是其可靠性。 > > ——David Rensin，e ARCHITECT Show：來自Google的關于云計算的速成課程 設計具有彈性的應用程序可能是整本書本身。我們將在云原生應用程序中考慮彈性的兩個主要方面：為失敗設計和優雅降級。 #### 為失敗設計 唯一永遠不會失敗的系統是那些讓你活著的系統（例如心臟植入物和剎車系統）。如果您的服務永遠不會停止運行，您需要花費太多時間設計它們來抵制故障，并且沒有足夠的時間增加業務價值。您的SLO確定服務需要多長時間。您花費在工程設計上超出SLO的正常運行時間的任何資源都將被浪費掉。 您應該為每項服務測量兩個值，即平均無故障時間（MTBF）和平均恢復時間（MTTR）。監控和指標可以讓您檢測您是否符合您的SLO，但運行應用程序的平臺是保持高MTBF和低MTTR的關鍵。 在任何復雜的系統中，都會有失敗。您可以管理硬件中的某些故障（例如，RAID和冗余電源），以及某些基礎設施中的故障（例如負載平衡器）。但是因為應用程序知道他們什么時候健康，所以他們也應該盡可能地管理自己的失敗。 設計一個以失敗期望為目標的應用程序將比假定可用性的應用程序更具防御性。當故障不可避免時，將會有額外的檢查，故障模式和日志內置到應用程序中。 知道應用程序可能失敗的每種方式是不可能的。假設任何事情都可能并且可能會失敗，這是一種云原生應用程序的模式。 您的應用程序的最佳狀態是健康狀態。第二好的狀態是失敗狀態。其他一切都是非二進制的，難以監控和排除故障。 Honeycomb首席執行官CharityMajors在她的文章“Ops：現在每個人都在工作”中指出：“分布式系統永遠不會起作用;它們處于部分退化服務的持續狀態。接受失敗，設計彈性，保護和縮小關鍵路徑。“ 無論發生什么故障，云原生應用程序都應該是可適應的。他們期望失敗，所以他們在檢測到時進行調整。 有些故障不能也不應該被設計到應用程序中（例如，網絡分區和可用區故障）。該平臺應自主處理未集成到應用程序中的故障域。 #### 優雅降級 云原生應用程序需要有一種方法來處理過載，無論它是應用程序還是負載下的相關服務。處理負載的一種方式是優雅降級。 “站點可靠性工程”一書中描述了應用程序的優雅降級，因為它提供的響應在負載過重的情況下“不如正常響應準確或含有較少數據的響應，但計算更容易”。 減少應用程序負載的某些方面由基礎設施處理。智能負載平衡和動態擴展可以提供幫助，但是在某些時候，您的應用程序可能承受的負載比它可以處理的負載更多。云原生應用程序需要知道這種必然性并作出相應的反應。 優雅降級的重點是允許應用程序始終返回請求的答案。如果應用程序沒有足夠的本地計算資源，并且依賴服務沒有及時返回信息，則這是正確的。依賴于一個或多個其他服務的服務應該可用于應答請求，即使依賴于服務不是。當服務退化時，返回部分答案或使用本地緩存中的舊信息進行答案是可能的解決方案。 盡管優雅的降級和失敗處理都應該在應用程序中實現，但平臺的多個層面應該提供幫助。如果采用微服務，則網絡基礎設施成為需要在提供應用彈性方面發揮積極作用的關鍵組件。有關構建彈性網絡層的更多信息，請參閱附錄A. > **可用性數學** > > 云原生應用程序需要在基礎設施之上建立一個平臺，以使基礎設施更具彈性。如果您希望將現有應用程序“提升并轉移”到云中，則應檢查云提供商的服務級別協議（SLA），并考慮在使用多個服務時會發生什么情況。 > > 讓我們拿運行我們的應用程序的云來進行假設。 > > 計算基礎設施的典型可用性是每月99.95％的正常運行時間。這意味著您的實例每天可能會縮短到43.2秒，并且仍在您的云服務提供商的SLA中。 > > 另外，實例的本地存儲（例如EBS卷）也具有99.95％的可用性正常運行時間。如果幸運的話，他們都會同時出現故障，但最糟糕的情況是他們可能會在不同的時間停機，讓您的實例只有99.9％的可用性。 > > 您的應用程序可能還需要一個數據庫，而不是自己安裝一個計算可能的停機時間為1分26秒（99.9％可用性）的情況下，選擇可靠性為99.95％的更可靠的托管數據庫。這使您的應用程序的可靠性達到99.85％，或者每天可能發生2分鐘和9秒的宕機時間。 > > 將可用性乘到一起可以快速了解為什么應以不同方式處理云。真正不好的部分是，如果云提供商不符合其SLA，它將退還其賬單中一定比例的退款。 > > 雖然您不必為停機支付費用，但我們并不知道世界上存在云計算信用的單一業務。如果您的應用程序的可用性不足以超過您收到的信用額度，那么您應該真正考慮是否應該運行這個應用程序。 ### 聲明式，非反應式 由于云原生應用程序設計為在云環境中運行，因此它們與基礎設施和支持應用程序的交互方式與傳統應用程序不同。在云原生應用程序中，與任何事物進行通信的方式都是通過網絡進行的。很多時候，網絡通信都是通過RESTful HTTP調用完成的，但它也可以通過其他接口（如遠程過程調用（RPC））來實現。 傳統的應用程序會通過消息隊列，寫在共享存儲上的文件或觸發shell命令的本地腳本來自動執行任務。通信方法對發生的事件作出反應（例如，如果用戶單擊提交，運行提交腳本）并且通常需要存在于同一物理或虛擬服務器上的信息。 > **Serverless** > > 無服務器平臺是云原生化的，并通過設計對事件做出響應。他們在云中工作得很好的原因是他們通過HTTP API進行通信，是單用途功能，并且在他們所稱的功能中聲明。該平臺還可以通過在云中進行擴展和訪問來提供幫助。 傳統應用程序中的反應性通信常常是嘗試增強彈性。如果應用程序在磁盤或消息隊列中寫入文件，然后應用程序死亡，則消息或文件的結果仍可能完成。 這并不是說不應該使用像消息隊列這樣的技術，而是說它們不能被依賴于動態和不斷發生故障的系統中的唯一彈性層。從根本上講，應用程序之間的通信應該在云原生環境中改變 - 不僅因為還有其他方法來構建通信彈性（請參閱附錄A），還因為在云中復制傳統通信方法往往需要更多工作。 當應用程序可以信任通信的彈性時，他們應該停止反應并開始聲明。聲明式溝通相信網絡將傳遞消息。它也相信應用程序將返回成功或錯誤。這并不是說應用程序監視變化并不重要。 Kubernetes的控制器正是這樣做到API服務器。但是，一旦發現變更，他們就會聲明一個新的狀態，并相信API服務器和kubelets會做必要的事情。 聲明式通信模型由于多種原因而變得更加健壯。最重要的是，它規范了通信模型，并且它將功能實現從應用程序轉移到遠程API或服務端點，從而實現某種狀態到達期望狀態。這有助于簡化應用程序，并使它們彼此的行為更具可預測性。 ### 云原生應用程序如何影響基礎設施？ 希望你可以知道云原生應用程序與傳統應用程序不同。云原生應用程序不能直接在PaaS上運行或與服務器的操作系統緊密耦合。它們期望在一個擁有大多數自治系統的動態環境中運行。 云原生基礎設施在提供自主應用管理的IaaS之上創建了一個平臺。該平臺建立在動態創建的基礎設施之上，以抽象出單個服務器并促進動態資源分配調度。 自動化與自治不一樣。自動化使人類對他們所采取的行動產生更大的影響。 云原生是關于不需要人類做出決定的自治系統。它仍然使用自動化，但只有在決定了所需的操作之后。只有在系統不能自動確定正確的事情時才應該通知人。 具有這些特征的應用程序需要一個能夠實際監控，收集度量標準并在發生故障時做出反應的平臺。云原生應用程序不依賴于人員設置ping檢查或創建Syslog規則。他們需要從選擇基本操作系統或軟件包管理器的過程中提取自助服務資源，并依靠服務發現和強大的網絡通信來提供豐富的功能體驗。 ## 參考 - [“Cloud Native Infrastructure”, a Free O’Reilly eBook](https://blog.heptio.com/i-still-remember-the-first-time-i-logged-into-a-production-server-over-ssh-and-telling-myself-i-53ab1d1e7f46)