都在叨叨雲原生，到底什麼是雲原生？

根據大多數定義，雲原生是一種軟體設計、實施和部署方法，旨在充分利用基於雲的服務和交付模型。雲原生應用程式通常也使用分散式架構執行，這意味著應用程式功能被分解為多個服務，然後分佈在託管環境中，而不是整合到單個伺服器上。

有點令人困惑的是，雲原生應用程式不一定在雲中執行。可以根據雲原生原則構建應用程式，並使用Kubernetes[2]等平臺將其部署在本地，該平臺模仿雲環境的分散式、基於服務的交付模型。

儘管如此，大多數雲原生應用程式都在雲中執行。任何按照雲原生原則設計的應用程式都可以在雲中執行。

雲原生是如何工作的?

雲原生是一個高階概念，而不是特定型別的應用程式架構、設計或交付過程。因此，有多種方法可以建立雲原生軟體以及可以幫助實現這一目標的各種工具。

然而，一般來說，雲原生應用程式共享某些核心功能：

它們是使用微服務[3]架構構建的。這意味著應用程式功能分佈在許多微服務中，這些微服務相互互動以執行完整的應用程式。

它們廣泛依賴 API 將內部元件相互整合，以及與第三方服務進行互動。

它們使用DevOps[4]等軟體開發策略迭代和持續更新。

它們部署在分散式環境中，例如伺服器叢集，而不是單個伺服器上。

您可以總結以上所有內容，即雲原生應用程式本質上是使用現代工具和方法設計和構建的應用程式。在很多方面，“雲原生軟體開發”簡直成了“現代軟體開發[5]”的簡寫。這兩個術語都有些模稜兩可，但這就是重點：正如有很多方法可以使軟體設計和開發操作現代化一樣，也有很多方法可以接近雲原生。

雲原生有什麼好處?

與傳統的應用程式設計和開發策略相比，雲原生提供了多種優勢。這意味著那些以單體架構、本地部署和單節點託管環境等技術為中心的優勢：

彈性和可靠性：由於雲原生應用程式通常部署在分散式環境中，因此它們在面對故障和中斷時更具彈性。單個伺服器故障，甚至是多個伺服器的故障，通常不會導致應用程式失敗，因為服務可以重新部署到叢集中的其他伺服器。

可擴充套件性：雲原生透過允許將應用程式分解為離散的部分來達到可擴充套件性。每個部分都可以單獨縮放，從而可以高效、快速地縮放。例如，如果應用程式登入次數激增，則可以擴充套件應用程式的身份驗證服務以應對這種增加，即使應用程式的其餘部分繼續以正常容量執行。

效率：從成本和效能的角度來看，雲原生應用程式往往是高效的。這是因為他們只能從與之互動的雲服務中消耗他們需要的資源。單體應用程式和單節點應用程式通常效率不高，因為它們可能會佔用整個伺服器，即使它們並不總是需要伺服器上的所有可用資源。

更快的創新：雲原生將應用程式分解為多個元件，這些元件可以使用自己的程式碼庫單獨開發。它還鼓勵透過持續整合/持續交付[6](CI/CD) 等方法進行持續的迭代開發。在這兩種方式中，雲原生都讓建立新功能和創新變得更加容易。

可移植性：使用雲原生方法設計的應用程式通常可以在任何雲中執行，以及在基於服務的模型(如 Kubernetes)上管理資源的任何本地託管平臺。在這方面，雲原生應用程式往往與雲和基礎設施無關，因此可以輕鬆地將它們從一個環境移植到另一個環境，而無需修改應用程式本身。

自動化：雲原生可以在部署和管理應用程式時輕鬆充分利用自動化工具。例如，雲原生應用程式經常使用容器進行部署，可以使用 Docker Swarm 或 Kubernetes 等工具進行編排，這些工具可以自動處理負載平衡和工作負載放置等任務。

雲原生的缺點是什麼?

雖然雲原生是加速應用程式開發、最大化效率和提高可靠性的好方法，但它帶來了一些挑戰。最常見的包括：

複雜性：簡單來說，雲原生的開發策略和應用架構比傳統應用更復雜。與使用單個程式碼庫開發的單體應用程式相比，雲原生應用程式包含更多移動部件，並且需要更復雜的開發過程。出於這個原因，採用雲原生的組織必須實施工具和流程，使他們能夠管理應用程式開發過程以及應用程式部署和管理過程的複雜性。

更多工具：與此類似，雲原生應用程式通常依賴於更多工具，從而導致更復雜的技術堆疊。雖然單體應用程式通常可以僅使用 VM 進行部署，但云原生應用程式可以使用容器部署，這些容器在 VM 上執行並透過 Kubernetes 進行編排。此外，CI/CD 等開發技術需要團隊管理大量工具(CI 伺服器、IDE、原始碼管理器等)。在有關雲原生應用程式的所有這些方面，團隊必須學習和跟蹤更多的工具和技術。

API 依賴：雖然雲原生應用程式以 API 為中心的設計使得按需消耗資源變得容易，但廣泛依賴 API 也存在缺陷。API 可能會引入原本不存在的安全問題。此外，API 效能或可用性問題可能會影響雲原生應用程式的效能，並且由於對第三方 API(如雲供應商提供的 API)的可見性有限，這些問題可能難以解決。

鎖定風險：雖然可以透過使用開放 API 和技術將雲原生應用程式設計為與供應商無關，但情況並非總是如此。一些雲原生應用程式可能需要來自特定雲供應商的 API，或者依賴於特定的編排平臺，從而導致供應商或平臺鎖定。

雲原生開發示例

如今，雲原生開發在各種型別和規模的組織中得到廣泛使用。考慮以下雲原生示例和用例：

重構遺留應用程式

擁有設計為在本地執行的遺留應用程式的企業可能會採用雲原生作為對這些應用程式進行全面檢查和現代化的手段。通常，這項工作需要重構，這意味著重新設計應用程式，使其可以在分散式環境中執行並充分利用基於服務的交付模型。

容器化應用

尋求利用比虛擬機器更高效且效能更好的容器的組織可能會轉向雲原生來實現這一點。雖然您不必使用容器來實現雲原生，但容器很適合基於微服務、面向服務的開發和部署技術。

雲遷移

擁抱雲原生是開始向雲遷移的好方法，或者是對現有云投資的雙重投資。從技術上講，您的應用程式不必是雲原生的就可以在雲中執行;例如，您可以在基於雲的 VM 上部署單體應用程式以在雲中執行它。但是為了充分利用雲，並在雲環境中實現成本和效能之間的最佳平衡，您需要您的應用程式是雲原生的。

成本最佳化

由於雲原生架構和開發策略傾向於更有效地利用資源，因此雲原生是尋求降低 IT 運營成本的企業的常見策略。雖然採用雲原生並不能自動保證成本效率，但精心設計的雲原生應用程式的執行和更新成本將低於傳統應用程式。

可靠性增強

如上所述，雲原生應用程式往往更可靠，因為即使主機基礎設施的一部分發生故障，它們仍然可用。出於這個原因，尋求使他們的應用程式更可靠，進而改善終端使用者體驗的組織應該考慮雲原生。

概括

透過允許組織充分利用分散式、基於服務的應用程式託管環境，雲原生可以為企業、開發人員和使用者等帶來更好的結果。並非每個應用程式都需要是雲原生的，但總的來說，雲原生是構建新應用程式或大修舊應用程式時要走的路。