儘管雲原生應用開發誕生於21世紀初，但是在術語使用方面還是非常混亂。 本文將帶您了解常見的術語和問題。
雲原生
雲原生計算基金會 （CNCF） 對「雲原生」的定義如下：
雲原生技術允許企業在公有雲、私有雲和混合雲等現代動態環境中構建和運行可擴展的應用。 雲原生的代表技術包括容器、service mesh、微服務、不可變基礎架構和聲明式 API。
這些技術能夠構建容錯性好、易於管理和便於觀察的松耦合系統。 結合可靠的自動化手段，雲原生技術使工程師能夠輕鬆地對系統作出頻繁和可預測的重大變更。
雲負載均衡
雲負載均衡是指將用戶端請求分發到在雲環境中運行的多個應用伺服器。 與其他形式的負載均衡一樣，雲負載均衡能夠最大限度地提高應用的性能和可靠性; 相比本地資源的傳統負載均衡，其優勢（通常）是成本更低，並可以輕鬆地根據需求來擴展或收縮應用。
如今，越來越多的企業（尤其是小型企業）都在雲中運行各種應用。 企業可能會使用基於雲的CRM（如Salesforce.com）儲存客戶資訊，使用基於雲的 ERP 系統追蹤產品數據，使用網路託管廠商（如 Google）託管網站，並使用 Amazon Elastic Compute Cloud （EC2） 運行少量定製的應用。
推薦的作法是將負載均衡器伺服器與所負載均衡的資源部署在同一環境中。 因此，當某個公司的大部分計算基礎架構都託管在雲中時，在雲中運行負載均衡器也是很有必要的。
雲負載均衡的優勢主要體現在雲本身的可擴展性和全域性上。
- 在雲端擴展的便捷性和速度意味著，企業只需在一組應用實例前放置一個可根據需求快速自動擴展的雲負載均衡器，即可輕鬆處理流量峰值（如“雙十一”的流量），並且不會降低性能。
- 在全球多個雲中心託管應用的能力還可以提高可靠性。 舉例來說，如果美國東北部在遭受暴風雪襲擊后發生停電，雲負載均衡器可以將流量從該地區託管的雲資源引導到在該國其他地區託管的資源。
多雲與混合雲
“多雲”和“混合雲”通常用作同義詞，但實際上兩者是有區別的。
多雲基礎架構跨越來自不同供應商的多個公有雲環境。 在多雲基礎架構中，不同的公有雲通常用於執行不同的任務（例如，一個用於程序邏輯，第二個用於資料庫，第三個用於機器學習），而且跨雲分佈可能因應用而異。 企業選擇多雲策略，是為了利用各種雲的靈活性和特性。
混合雲基礎架構包括兩個或多個不同類型的雲環境（本地、私有雲和公有雲）。 在混合雲基礎架構中，公有雲的作用是擴展私有雲或本地環境的功能。 正在將應用遷移到雲或因技術債過多而無法全面實現雲原生的企業，通常會採用此方法。 混合雲基礎架構通常包括多個公有雲，因此結合了混合雲和多雲。
容器
容器是一種虛擬化技術，旨在為應用創造可移植性並支援這種可移植—— 換句話說，是為了在各種不同的平臺上都能輕鬆地部署應用。 容器可以將應用的所有需求（應用代碼本身、應用的依賴項（比如需要運行的庫等），以及應用及其依賴項的運行時環境）打包到一個可跨平臺傳輸和獨立運行的包中。 容器是一個應用從其典型的操作系統運行時環境中的抽象（abstraction）。
Docker 是最有名的容器實現格式; 此外，還有其他容器技術（例如 rkt/CoreOS、containerd、Hyper – V 容器）以及較低級別的技術（例如 cgroups 和 namespaces，這兩種技術都用於應用隔離，類似於容器引擎，但不像容器那樣提供隔離的可移植性）。 您可以使用 Docker 或 rkt 等平臺工具直接管理容器，但大多數部署都使用編排工具（如Kubernetes）管理容器。 Kubernetes 已逐漸成為了預設的生產級容器部署的標準工具。
容器已成為一種備受歡迎的架構選擇，因為它能夠將應用分解為小型獨立元件，使基礎架構管理人員和開發人員可以各司其職。 這在開發過程中好處多多，因為這意味著不同的團隊可以並行開發各種不同元件，而且在部署過程中也大有裨益，因為它可實現平臺之間給定容器的可移植性。 容器還為應用和基礎架構管理人員提供了一套更精簡的工具，因為容器提供了不可變的平臺，讓開發人員可以按一組已知要求來發佈應用容器，並且他們無需自行管理這些需求。
術語「應用容器化」通常用於表示將應用從標準的 Linux 運行時環境遷移到可在許多環境中運行的自包含容器的過程。 許多企業已經步入了容器化之旅，並已開始使用 Kubernetes 等工具遷移到基本的容器中，或有了更全面的容器管理策略。
微服務
微服務是一種利用多個小組件（每個元件執行單個功能，例如身份驗證、通知或支付流程）構建大型複雜應用的軟體架構方法，亦指這些小組件本身。 每個微服務都是軟體開發專案中的一個獨立單元，具有自己的代碼庫、基礎架構和資料庫。 微服務協同工作，通過 Web API 或消息佇列進行通信，以對傳入事件作出回應。
在《構建微服務》一書中，Sam Newman 簡單明瞭地將微服務定義為「協同工作的小型自主服務」——這個定義包含了微服務的三個要素。
- 微服務的代碼庫很「小」，因為它專注於一項功能; 小規模“意味著單個開發人員或小型團隊即可創建並維護代碼。
- “自主”意味著微服務可按需部署和擴展，當微服務內部發生變化時，無需諮詢負責其他微服務的團隊。
- 這之所以成為可能，是因為當微服務「協同工作」時，它們通過明確定義的 API 或不會暴露微服務內部工作原理的類似機制進行通信。
更多有關「微服務」的基礎概念，請閱讀我們的文章《一文瞭解微服務》。
Ingress Controller（Ingress 控制器）
Ingress controller （Ingress 控制器）是面向 Kubernetes（及其他容器化）環境的專用負載均衡器。 Kubernetes 是容器化應用管理的事實標準。
對許多企業而言，將生產工作負載遷移到 Kubernetes 會增加應用流量管理方面的挑戰和複雜性。 Ingress controller 能夠將 Kubernetes 應用流量路由的複雜性抽象出來，並在 Kubernetes 服務和外部服務之間建立了一座橋樑。
Kubernetes Ingress Controller 的功能如下：
- 接受來自 Kubernetes 平臺外部的流量，並將其負載均衡到 Kubernetes 平台內部運行的 pod（容器）
- 可管理集群內需要與集群外其他服務通信的服務的出向流量
- 使用 Kubernetes API 進行配置，以部署名為“Ingress 資源”的物件
- 監控 Kubernetes 中運行的 pod，並在服務添加或刪除 pod 後自動更新負載均衡規則
Service Mesh（服務網格）
根據 The New Stack 的定義，service mesh 是一種旨在“提高分散式系統的安全性、可觀測性及流量控制”的技術。 更具體地說，service mesh 是一種像 Kubernetes 這樣的容器化環境編排工具的元件。
它通常負責一系列功能，包括在容器化應用之間路由流量，用作定義自動的 service 到 service 的雙向 TLS （mTLS） 策略和實施這些策略的介面，並讓應用的可用性和安全性變得可視化。 與 Kubernetes 的整體狀況一樣，service mesh 也是由控制平面、管理平面及數據平面組成。
Service mesh 通常以一種對容器化應用透明的方式處理流量管理和安全防護。 通過 SSL/TLS 卸載、負載均衡 等功能，service mesh 能夠使開發人員無需在每個應用中都單獨實現安全性或服務可用性。 企業級的 service mesh 為各種「難題」提供了解決方案：
- 使用端到端加密和 mTLS 保護流量
- 通過注入管理、sidecar 管理及 Kubernetes API 集成進行編排
- 管理服務流量，包括負載均衡、流量控制（速率限制和斷路）及流量整形（灰度部署、A/B 測試、藍綠部署）
- 使用 Prometheus 和 Grafana 等熱門工具增強對 service 到 service 流量的監控和可視化
- 通過原生集成的 Ingress controller（Ingress 控制器），簡化 Kubernetes 出入向流量管理
Service mesh 可以很小，專注於某項特定功能; 它也可以很大，包含一套全面的網路和集群管理工具（例如 Istio）; 它也可以是介於兩者之間的任何形態。 Service mesh 越大越複雜，獨立的管理平面就越有用。