原文链接：基础概念回顾：云原生应用交付
转载来源：NGINX 开源社区

NGINX 唯一中文官方社区 ，尽在 nginx.org.cn

尽管云原生应用开发诞生于 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 越大越复杂，独立的管理平面就越有用。

NGINX 唯一中文官方社区 ，尽在 nginx.org.cn

更多 NGINX 相关的技术干货、互动问答、系列课程、活动资源： 开源社区官网 | 微信公众号