Browse by Tags We've categorized the glossary terms. Use the filters to browse terms by tag.
基本原理
基础设施
安全
平台
应用程序
方法论
架构
网络
Select All Deselect All
是什么 API 网关是一种通过聚合多个应用程序的 API，并实现一站式管理的工具。 它允许组织将关键性功能移交到一个可集中管理的地方，例如身份验证和授权、限制应用程序之间的请求数量。 一个 API 网关则作为一个公共的接口，向 API 消费者（通常来自外部）提供服务。
解决的问题 当你的应用需要为外部消费者提供 API 时，你通常需要一个统一的入口来管理和控制所有的访问。 此外，如果你需要对这些交互添加某种功能，也可以在不更改任何应用代码的情况下为所有的流量实现新功能。
如何帮助 通过为多个 API 提供一个统一的访问入口，API 网关能够让组织更容易地将交叉性业务或安全性逻辑移交到一个可集中管理的地方。 应用的消费端也只需要访问单个地址就可以满足其所有需求。 通过为系统中的所有 web 服务提供统一的访问入口，API 网关还可以简化诸如安全性和可观测性之类的运维问题。 由于所有请求都流经 API 网关，因此它可以中心化的为这些请求添加诸如指标收集、速率限制和授权等功能。..
是什么 Kubernetes，通常缩写为K8s，是一种流行的现代基础设施自动化的开源工具。 它就像一个数据中心的操作系统，管理在 分布式系统 上运行的应用程序（就像你笔记本上的操作系统，管理你的应用程序）。
Kubernetes在 集群 的 节点 上调度 容器。 它捆绑了几个基础设施结构，有时被称为 “基元”，如应用程序的实例、负载平衡器、持久性存储等，以一种可以被组成应用程序的方式。
Kubernetes 实现了自动化和可扩展性，使用户能够以可重复的方式声明性地部署应用程序。 Kubernetes 生态系统中的软件产品和项目利用这种自动化和可扩展性来扩展 Kubernetes API 。 这使他们能够利用 Kubernetes 的自动化，并使他们的工具更容易被有经验的 Kubernetes 从业者所接受。
解决的问题 长期以来，基础设施自动化和声明性配置管理一直是重要的概念，而且随着 云计算 的普及而变得更加紧迫。 随着对计算资源的需求增加，组织感到压力，要用更少的工程师提供更多的操作能力，需要新的技术和工作方法来满足这一需求。 此外，云计算的兴起与 容器化 相搭配，那些忙于自动化更多传统基础设施的组织需要一种机制来自动配置和部署其容器。
如何帮助 Kubernetes 以类似于传统的基础设施即代码工具的方式帮助实现自动化，但它的优势在于，与虚拟机或物理机相比，容器更能抵抗配置漂移。 Kubernetes 的工作方式是声明式的，这意味着操作者不是提供关于如何做某事的指示，而是描述（通常是YAML文档）他们想要做什么；Kubernetes将自行处理 “如何 “的问题。这导致Kubernetes与基础设施即代码极为兼容。
Kubernetes 还能自我修复。这意味着它确保集群的实际状态总是与操作者的期望状态相匹配。 如果Kubernetes检测到一个偏差，Kubernetes 控制器就会启动并修复它。 因此，虽然它使用的基础设施可能不断变化，但 Kubernetes 本身也在不断自动适应变化，并确保它与预期状态相匹配。..
是什么 Serverless 是一种云原生开发模型，允许开发人员构建和运行应用程序，而无需管理服务器。 Serverless 中仍有服务器，但它们被 抽象 出来，远离应用程序开发。 云提供商处理配置、维护和 伸缩 服务器基础架构的日常工作。 开发人员可以简单地将他们的代码打包在 容器 中进行部署。 部署后，Serverless 应用程序会响应需求并根据需要自动扩展和缩减。 公共云提供商的 Serverless 产品通常通过事件驱动的执行模型按需计量。 因此，当无服务器功能处于空闲状态时，它不会花费任何费用。
解决的问题 在标准的 基础设施即服务 (IaaS) 云计算 模型下，用户预先购买容量单位， 这意味着您需要向公共云提供商支付永远在线的服务器组件的费用来运行您的应用程序。 用户有责任在高需求时伸缩服务器容量，并在不在需要该容量时缩减容量。 即使在不使用应用程序时，运行应用程序所需的云基础设施也处于活动状态。
如何帮助 相比之下，使用 Serverless 架构，应用程序仅在需要时启动。 当事件触发应用程序代码运行时，公共云提供商会为该代码动态分配资源。 当代码执行完成后，用户就停止为资源付款。除了成本和效率优势之外，Serverless 还使开发人员从与应用程序扩展和服务器配置相关的日常和琐碎任务中解放出来。 借助 Serverless，管理操作系统和文件系统、安全补丁、负载平衡、容量管理、伸缩、日志记录和监控等日常任务都被交给云服务提供商。..
是什么 安全混沌工程（SCE） 是基于混沌工程的学科。 SCE 是指在分布式系统上执行主动安全实验，以建立对系统抵御动荡和恶意条件能力的信心。安全混沌工程师使用科学方法来不断实现这一点，这些方法包括稳态、假设、持续验证、经验教训和缓解实施。
解决的问题 网站稳定性工程师（SRE） 和网络安全工程师的主要职责是尽快恢复服务，来达到零停机时间和最小化业务影响的目标。 SRE 和网络安全工程师共同处理故障前和故障后的各种意外情况。大多数安全问题很难快速发现和修补，这将影响应用程序或系统的功能。此外，在开发阶段通常很难发现安全事件。
如何帮助 安全混沌工程是围绕可观察性和网络弹性实践构建的。它旨在发现“不知道不知道”问题并建立对系统的信心，提高网络弹性和可观察性。
工程团队将逐步提高对复杂基础设施、平台和分布式系统中安全问题的理解。 SCE 提高了整个产品的网络弹性，发现隐藏的安全问题，暴露经典盲点，并让团队为关键的边缘案例做好准备。这种方法有助于 SRE、 开发运维和DevSecOps工程师建立对系统的信心，提高网络弹性并提高可观察性。..
是什么 源代码管理（或版本控制）是一种跟踪和管理文档更改的行为。 它是一个持续记录单个文件或一组文件变化的系统，以便你在以后可以回退到特定版本。
解决的问题 版本控制系统致力于解决以下问题， 备份随时间变化的文档或代码库， 允许在多个用户存在交叉修改时解决冲突，并随时间存储更改日志。 处理关键业务的应用程序代码通常复杂且重要， 因此，跟踪谁更改了内容、什么时候更改的以及更改原因是非常重要的。 此外，许多（甚至可以说大部分）应用程序是由多个开发人员修改的，并且不同开发人员引入的更改之间经常存在冲突。
如何帮助 版本控制可帮助开发人员快速行动并保持效率，同时存储更改记录并提供解决冲突的工具。 它可以将应用程序代码存储在代码仓库中并简化开发人员间的协作。 现代应用程序开发非常依赖版本控制系统，如 git，来存储他们的代码。..
是什么 持续部署，通常缩写为 CD，通过将已经完成的软件直接部署到生产环境，比持续交付更进了一步。持续部署 (CD) 与持续集成(CI) 一起，通常被称为 CI/CD。 CI 流程测试给定应用程序的修改是否正确，CD 流程自动部署企业测试环境的代码更改到生产环境。
解决的问题 发布新的软件版本是一个劳动密集且容易出错的过程。这也是企业不想频繁发布新版本的原因，避免生产事故并减少工程师在正常工作时间之外需要随时响应的时间。传统的软件部署模型使组织陷入了一个恶性循环，即发布软件的过程无法同时满足企业在稳定性和软件迭代速度方面的需求。
如何帮助 通过自动化发布周期迫使企业更频繁地发布版本到生产环境，CD 为运维团队完成了 CI 为开发团队所做的事情。具体来说，它迫使运维团队将生产部署中痛苦且容易出错的部分自动化，从而降低整体风险。它还使企业能够更好地接受和适应生产环境变化，从而提高稳定性。
相关术语 持续集成 持续交付..
是什么 持续集成，通常缩写为CI，是尽可能定期集成代码变化的做法。 CI 是 持续交付（CD）的前提。 传统上，CI 过程从代码修改提交到源码控制系统（Git、Mercurial 或 Subversion）时开始，以准备被CD系统使用的测试工件结束。
解决的问题 软件系统通常是庞大而复杂的，有许多开发人员在维护和更新它们。 在系统的不同部分平行工作，这些开发人员可能会做出相互冲突的修改，并在无意中破坏对方的工作。 此外，由于多个开发人员在同一个项目上工作，任何日常工作，如测试和计算代码质量，都需要由每个开发人员重复进行，浪费了时间。
如何帮助 每当开发人员提交修改时，CI 软件都会自动检查代码修改是否合并得很干净。 使用 CI 服务器来运行代码质量检查、测试甚至部署，这几乎是一种普遍的做法。 因此，它成为团队内部质量控制的一个具体实施。 CI 允许软件团队把每一个代码提交变成具体的失败或可行的候选发布。
相关术语 持续交付 持续部署..
是什么 持续交付，通常缩写为 CD，是一套实践，其中代码的变化被自动部署到验收环境中（或者，在持续部署的情况下，部署到生产中）。 CD 关键是包括确保软件在部署前得到充分测试的程序，并提供一种在认为必要时回滚修改的方法。 持续集成（CI）是实现持续交付的第一步（也就是说，在测试和部署之前，变化必须干净地合并）。
解决的问题 部署 可靠 的更新在规模上成为一个问题。 理想情况下，我们会更频繁地部署，为终端用户提供更好的价值。 然而，手动操作会使每一个变化都转化为高额的交易成本。 历史上，为了避免这些成本，企业发布的频率较低，一次部署更多的变化，增加了出错的风险。
如何帮助 CD 策略创建了一个完全自动化的生产路径，使用各种部署策略测试和部署软件，如 金丝雀部署 或 蓝绿部署 发布。 这使得开发人员可以频繁地部署代码，让他们放心地认为新的修订版已经过测试。 通常情况下，CD 策略中使用基于主干的开发，而不是功能分支或拉动请求。
相关术语 持续集成 持续部署..
在计算的上下文中，抽象是一种对 服务 的消费者（消费者可以是计算机程序或人类）隐藏其细节的表示法，使系统更通用也更容易理解。 你的笔记本电脑的操作系统就是一个很好的例子。它把计算机工作的所有细节都抽象出来了。 你不需要知道任何关于CPU、内存以及程序如何被运行，你只需操作操作系统，操作系统会处理这些细节。 所有这些细节都隐藏在操作系统的“幕布”或抽象概念后面。
系统通常有多个抽象层。这大大简化了开发工作。在编程时，开发人员构建与特定抽象层兼容的组件，而不必担心可能非常异构的所有底层细节。 如果组件能与抽象层一起工作，它就能与系统一起工作 —— 无论底层是什么样的。..
是什么 传输层安全性协议 (TLS) 是一种旨在为网络通信提供更高安全性的协议。它确保通过因特网发送的数据安全交付，避免可能的数据监视和/或篡改。该协议广泛用于消息传递、电子邮件等应用程序中。
解决的问题 如果没有 TLS，网页浏览习惯、电子邮件通信、在线聊天和电话会议等敏感信息在传输过程中很容易被他人追踪和篡改。启用服务器和客户端应用程序对 TLS 的支持，可以确保它们之间传输的数据是加密的，并且第三方无法查看。
如何帮助 TLS 使用多种编码技术，在通过网络传输数据时提供安全性。 TLS 允许客户端应用程序和服务器（如浏览器和银行站点）之间的加密连接。它还允许客户端应用程序积极地识别他们正在调用的服务器，从而降低客户端与欺诈站点通信的风险。这可以确保第三方无法查看和监控使用 TLS 在应用程序之间传输的数据，从而保护敏感隐私的信息，例如信用卡号、密码、位置等。..
是什么 垂直伸缩，也称为“向上和向下伸缩”，是一种通过在工作负载增加时向单个节点添加CPU和内存来增加系统容量的技术。 假设您有一台 4GB RAM 的计算机，并且想要将其容量增加到 16GB RAM，垂直伸缩就意味着切换到 16GB RAM 系统。 （请参阅水平伸缩了解不同的伸缩方法。）
解决的问题 随着对应用程序的需求增长超出该应用程序实例的当前容量，我们需要找到一种方法来伸展（增加容量）系统。 我们可以向现有节点添加更多计算资源（垂直伸缩）或向系统添加更多节点(水平伸缩)。 可伸缩性有助于提高竞争力、效率、声誉和质量。
如何帮助 垂直伸缩允许您在不更改应用程序代码的情况下调整服务器大小。这与水平伸缩形成对比，在水平伸缩中，应用程序必须可以被复制来进行伸缩，而这可能需要代码更新。 垂直伸缩通过添加计算资源来增加现有应用程序的容量，允许应用程序处理更多请求并同时执行更多工作。
相关词汇 水平伸缩 自动伸缩..
是什么 单体应用在一个简单可部署的程序中包含所有的功能。在制作一个应用程序时，这通常是最简单和最容易的开始。 然而，一旦应用程序的复杂性增加，单体式就会变得难以维护。随着更多的开发人员在同一个代码库上工作，发生冲突性变化的可能性和开发人员之间的人际沟通的需要就会增加。
解决的问题 将一个应用程序转变成 微服务 会增加其运营开销——有更多的东西需要测试、部署和保持运行。 在产品生命周期的早期，推迟这种复杂性并建立一个单体应用，直到产品被确定为成功，可能是有利的。
如何帮助 精心设计的单体可以坚持精益原则，因为它是启动和运行应用程序的最简单方式。当单体应用的商业价值被证明是成功的，它可以被分解成微服务。 在证明有价值之前，制作一个基于微服务的应用程序可能是过早地花费了工程努力。如果应用程序没有产生任何价值，这些努力就会被浪费掉。..
是什么 调试是从计算机程序、软件或系统中查找并解决故障（或错误） 以获得预期结果的过程或活动。 故障是导致不正确或不符合预期结果的缺陷或问题。
解决的问题 软件开发是一项复杂的活动，在不引入故障的情况下编写代码几乎是不可能的。 这些故障导致代码在执行时可能无法按预期运行，或产生未定义的行为。 根据应用程序的重要性，故障可能会产生重大的负面影响 —— 经济上甚至是人类生活。 通常，应用程序代码必须在不同阶段或环境被测试。 应用程序越关键，测试就必须越准确。
如何帮助 当出现故障时，工程师通过调试（例如，查找和修复）应用程序以减少生产系统中的不良行为。 调试并不是一件容易的事，因为工程师必须追踪不良行为的根源。 它需要有关代码本身和运行时执行上下文的知识。 这是不同的调试技术和工具派上用场的地方。 例如，分析日志、链路信息和指标信息，用于直接在生产中进行调试。 开发人员可以使用交互式调试在运行时单步执行代码，同时分析相关的执行上下文。 一旦定位到故障的根源，他们通过发起修复错误的请求或者发布新的补丁来更正代码行为。..
是什么 防火墙是一个基于特定规则过滤网络流量的系统。防火墙可以是硬件、软件，或者是两者的组合。
强调的问题 默认情况下，在遵循网络的路由规则下，网络将会允许任何人进出。由于这种默认行为，保护网络安全是有挑战性的。 例如，在基于 微服务 的银行应用程序中，服务之间的沟通是通过其网络来相互传递高敏感性财务数据。 假如没有防火墙，恶意行为者可能会渗透网络、拦截通信并且造成破坏。
如何帮助 防火墙使用预设规则来检查网络流量。所有流量都会被过滤，任何来自不可信或可疑来源的流量都会被阻止 —— 只有设置为被接受的流量才能进入。 防火墙在安全和受控的内部可信网络间建立了一道屏障。..
是什么 分布式系统是通过网络连接的自主计算元素的集合，在用户看来是一个单一的连贯系统。 一般被称为 节点，这些组件可以是硬件设备（如电脑、手机）或软件进程。 节点被编程以实现一个共同的目标，为了协作，它们通过网络交换信息。
解决的问题 今天的许多现代应用程序都非常大，需要超级计算机来操作。想想Gmail或Netflix。 没有一台计算机强大到足以承载整个应用程序。通过连接多台计算机，计算能力几乎变得无限大。 如果没有分布式计算，我们今天依赖的许多应用就不可能实现。
传统上，系统会纵向 伸缩。这就是当你在一台单独的机器上添加更多的 CPU 或内存。 垂直伸缩很耗时，需要停机，而且很快就会达到极限。
如何帮助 分布式系统允许 水平伸缩（例如，在需要时向系统添加更多节点）。这可以是自动化的，允许系统处理工作负荷或资源消耗的突然增加。
非分布式系统面临着故障的风险，因为如果一台机器发生故障，整个系统都会故障。分布式系统可以设计成这样，即使一些机器发生故障，整个系统仍然可以继续工作，产生相同的结果。..
是什么 分布式应用是一种应用，其功能被分解成多个较小的独立部分。 分布式应用通常由单独的 微服务 组成，处理更广泛应用中的不同问题。 在云原生环境中，各个组件通常作为 容器 在 集群 上运行。
解决的问题 运行在单一计算机上的应用程序代表了一个单点故障–如果该计算机发生故障，应用程序就不可用。 分布式应用通常与单体式应用形成对比。一个单体应用可能更难扩展，因为各种组件不能独立扩展。 随着应用程序的增长，它们也会拖累开发人员的速度，因为更多的开发人员需要在一个不一定有明确边界的共享代码库上工作。
如何帮助 当把一个应用程序拆分成不同的部分并在许多地方运行时，整个系统可以容忍更多的故障。 它还允许应用程序利用单个应用程序实例所不具备的伸缩功能，即 水平伸缩的能力。 然而，这也是有代价的：增加了复杂性和操作开销–你现在正在运行很多应用组件，而不是一个应用。..
以下的风格指南旨在帮助你了解云原生词汇表的定义结构，并在整个过程中保持一致的风格。
云原生词汇遵循位于CNCF资源库中的 默认风格指南。此外，它还遵循以下规则：
使用简单、易懂的语言，避免技术术语和流行语 避免使用俗语 使用字面和具体的语言 省略缩略语 少用被动语态 力求以积极的形式表述 引号外不加感叹号 不要夸大其词 避免重复 要简明扼要 Definition Template 每个词汇表术语都存储在一个 markdown 文件中，并遵循这个模板：
— title: status: category: — ## 是什么 对该技术或概念的快速总结。 ## 解决的问题 关于它所解决的问题的几句话。 ## 如何帮助 用几句话说明这个东西是如何解决问题的。 标题 title 标签将始终位于定义布局的顶部，其值应使用标题大小写。
— title: 定义模板 状态 status 标签将出现在标题标签之后。状态标签表明定义是经过彻底审查还是未完成的。
有效值：
Completed Feedback Appreciated Not Started 你可以随时对一个已完成的定义提出问题。当一个定义处于变化中时，它的状态将被改变为 Feedback Appreciated。
— title: 定义模版 status: Feedback Appreciated 类别 category 标签将出现在状态标签之后。它的值应该是以下值之一：
技术 属性 概念 — title: 定义模版 status: Feedback Appreciated category: 概念 — 定义 该定义包含三个小标题，为读者提供背景：“是什么”，“解决的问题”，以及 “如何帮助”。 对于技术和概念类的术语来说，这三个标题都是必须的，然而，属性类的定义则不需要这些标题。..
请注意，在 IT 中，服务有多种含义。 在这个定义中，我们将关注更传统的定义：微服务中的服务。 服务与微服务哪里有、是否有区别是细微的，不同的人可能有不同的看法。 在更高层次的定义中，我们将它们视为相同。 请参考微服务的定义。..
是什么 服务代理拦截进出某项 服务 的流量，对其应用一些逻辑，然后将该流量转发给另一项服务。 它本质上是一个“中间人”，收集有关网络流量的信息，并决定是否对其应用规则。
解决的问题 为了跟踪服务与服务之间的通信（又称网络流量），并可能对其进行转换或重定向，我们需要收集数据。 传统上，实现数据收集和网络流量管理的代码被嵌入每个应用程序中。
如何帮助 服务代理允许我们将这种功能“外部化”。它不再需要生活在应用程序中。 相反，它现在被嵌入到平台层中（你的应用程序运行的地方）。
作为服务之间的守门员，代理提供对正在发生的通信类型的洞察力。 根据他们的洞察力，他们决定将一个特定的请求发送到哪里，甚至完全拒绝它。
代理人收集关键数据，管理路由（在服务之间平均分配流量，或在某些服务中断时重新路由），加密连接，并缓存内容（减少资源消耗）。..
是什么 服务发现是查找组成服务各个实例的过程。 服务发现工具持续跟踪构成服务的各种节点或端点。
解决的问题 云原生架构是动态的和不确定的，这意味着它们不断在变化。 容器化 的应用程序在其生命周期内可能会多次启动和停止。 每次这种情况发生时，它都会有一个新地址，任何应用程序想要找到它，都需要一个工具来提供新的地址信息。
如何帮助 服务发现持续跟踪网络中的应用程序，以便在需要时可以找到彼此。 它提供了一个公共的地方来查找和识别不同服务。 服务发现引擎是类似数据库的工具，用于存储当前有哪些服务以及如何找到它们。..
是什么 在 微服务 的理念里，应用程序被分解成多个较小的 服务，通过网络进行通信。 就像你的 WIFI 网络一样，计算机网络本质上是不可靠的，可被黑客攻击的，而且往往很慢。 服务网格通过管理服务之间的流量（即通信），并在所有服务中统一添加 可靠性、可观察性 和安全功能来解决这一系列新的挑战。
解决的问题 在转向微服务架构后，工程师们现在要处理数百个，甚至数千个单独的服务，都需要进行通信。 这意味着大量的流量在网络上来回传输。除此之外，单个应用程序可能需要对通信进行加密，以支持监管要求，为运营团队提供通用指标，或提供对流量的详细洞察，以帮助诊断问题。 如果内置于单个应用程序中，这些功能中的每一个都会引起团队间的冲突，并减缓新功能的开发。
如何帮助 服务网格在集群的所有服务中统一增加了可靠性、可观察性和安全功能，而不需要改变代码。 在服务网格之前，这些功能必须被编码到每一个服务中，成为错误和技术债务的潜在来源。..
<p>大家好! 👋 感谢你对 CNCF 云原生词汇项目的贡献。 无论你是贡献新的术语，帮助将词汇表本地化为你的母语，还是想帮助其他人开始工作，都有很多方法可以成为这个社区的积极成员。 本文档概述了项目中不同的贡献者角色以及随之而来的责任和特权。</p>
<ol>
<li>贡献者 云原生词汇表是为所有人准备的。任何人都可以通过对项目的贡献而成为词汇表的贡献者。 所有贡献者都应遵守 CNCF 行为准则。
你可以通过多种方式为该项目做出贡献，包括：
内容贡献者：每个改进现有条款或贡献新条款的人。 本地化贡献者：帮助将词汇表翻译成其他语言的人。 帮助者：任何在 GitHub、Slack 或社区成员需要支持的地方帮助他人的人。 大使：帮助传播信息的人，教育社区成员如何做出贡献以及为什么要这样做。 贡献者可以有多种角色，也可以只专注于一个领域。所有这些贡献都是同样重要的，这有助于促进社区的繁荣。 关于内容和本地化的贡献，请参考 如何贡献 和 风格指南。</li>
<li>审批者 审批者对 PR 提供反馈并批准它们。任何活跃的贡献者都可以成为审批者（见 “成为审批者”）。 词汇表区分了两种审批者：(1) 英语词汇表的审批者和(2) 本地化团队的审批者。
词汇审批者应做到：
审查 PR 的技术准确性。 为贡献者分配问题并为其贴上适当的标签。 向贡献者提供反馈，并在需要时为他们提供指导。 校对和编辑提交的内容。 如果审批者不再有兴趣或不能履行上述职责，他们应该让维护者知道并退出。
英语词汇表审批者 有三种类型的审批者：
具有强大技术背景的审批者。 具有扎实的写作技巧的审批者。 两者都精通的审批者。 技术审批者：具有强大技术背景的人可以成为审批者，而不需要具备坚实的英语写作技能。 然而，如果他们根据技术价值批准一项公关，他们必须确保由（编辑）批准者进行审查。
编辑：编辑对术语进行校对，并确保根据《风格指南》用简单的语言对其进行解释。 如果一个术语被大量编辑，编辑必须要求技术审批者再次审查，以确保其含义没有被改变。
本地化审批者 词汇表也有本地化审批者。他们是本地化团队（翻译云原生词汇表的团队）的审批者。 本地化审批者只允许为他们自己的团队履行审批者职责，并有能力将 PR 合并到他们专用的开发分支。 如果符合要求，任何本地化审批者也可以成为英语词汇表的审批者。
成为审批者 审批员候选人应该有提交高质量 PR 的记录，并帮助他人将他们的PR合并到可合并的状态。 如果他们的时区允许，他们也应该定期参加 云原生词汇工作组会议。
要成为审批者，首先要向现有的维护者表达兴趣。现有的维护者会要求你在他们的指导下，通过贡献PR、做审查和其他类似的任务来证明上述资格。 经过一段时间的合作，维护者们将决定是否授予你审批者的身份。这个决定将基于你的熟练程度和反应能力。</li>
<li>维护者 维护者是审批者，也可以合并PR。任何人都可以成为词汇表维护者（见 “成为维护者”）。对维护者有一些期望，包括：
成为一个积极响应的审批者（见上文）。 帮助维护存储库，包括网站配置、权限、问题模板、GitHub 工作流程等。 监控云原生词汇表的 Slack 频道，并尽可能地提供帮助。 定期参加 云原生词汇工作组会议 (如果时区允许) 如果维护者不再有兴趣或不能履行上述职责，他们应该将自己转为荣誉会员。</li>
</ol>..
是什么 混沌工程或 CE 是在生产中对 分布式系统 进行实验的学科，以建立对系统承受动荡和意外情况时能力的信心。
解决的问题 SRE 和 DevOps 实践侧重于提高产品弹性和 可靠性 的技术。 系统在故障容灾时确保服务质量的能力通常是对软件开发提出的要求。这里涉及到几个方面可能导致应用程序中断，例如基础设施、平台或（基于微服务）的应用程序的其他部分。 高频地持续部署新功能到生产环境会增加服务中断和恶性事件发生的可能性，乃至于对业务产生重大影响。
如何帮助 混沌工程是一种满足弹性要求的技术。它用于实现对基础架构、平台和应用程序等意外发生时的故障容灾。 混沌工程师使用混沌实验主动注入随机故障，以验证应用程序、基础架构或平台是否可以自我修复，并且故障不会对客户产生明显影响。 混沌实验旨在发现盲点（例如监控或自动伸缩技术）并在恶性事件发生期间增强团队之间的沟通。 这种方法有助于提高复杂系统的弹性和团队对其的信心，尤其是在生产环境。..
是什么 基础设施即代码是将基础设施的定义存储为一个或多个文件的做法。 这取代了通常通过 shell 脚本或其他配置工具手动配置基础架构即服务的传统模型。
解决的问题 云原生方式构建应用程序要求基础设施是一次性的和可复现的。 它还需要以自动化和可重复的方式按需 伸缩，甚至可能无需人工干预。 手动配置则无法满足 云原生应用 对响应能力和灵活伸缩的诉求。 而且手动基础架构变更不可复现，很容易碰到伸缩瓶颈，并引入错误配置。
如何帮助 通过将服务器、负载均衡器和子网等数据中心资源表示为代码， 它允许基础架构团队对所有配置拥有单一的数据源，并允许他们在 CI/CD 通道中管理数据中心，实现版本控制和部署策略。..
是什么 基础设施即服务，或者 IaaS ，是一种 云计算 服务模型， 它提供 物理 或 虚拟 的计算、存储和网络资源，使用按需按量的计费模式。 云提供商拥有和管理软件和硬件设施，可供消费者在公共、私有或混合云部署和使用。
解决的问题 在搭建传统的本地设施时，组织常常受困于如何保证资源的有效利用。 数据中心建立时必须考虑潜在的高峰需求，即使这样的需求只占1%的使用时间。 而在低需求期间，这些计算资源是空闲的。 而且，如果工作负载超过预期需求，处理工作负载的计算资源则会出现短缺。 这种缺乏可伸缩性的使用方式，将导致成本增加和资源使用率降低。
如何帮助 通过 IaaS ，组织可以避免为其应用程序购买和维护计算和数据中心资源。 按需使用的基础设施允许他们根据需要租用计算资源，并推迟大型资本支出， 或 CAPEX ，同时给予他们扩大或缩小规模的灵活性。
IaaS 降低了试验或尝试新应用程序的初期成本，并提供了快速部署基础设施的工具。 云提供商是开发或测试环境的绝佳选择，它可以帮助开发人员低成本的进行试验和创新。..
是什么 集群是一组计算机或应用程序，它们为一个共同的目标一起工作。 在云原生计算的背景下，这个术语最常被应用于 Kubernetes。 Kubernetes 集群是一组服务（或工作负载），它们在各自的容器中运行，通常在不同的机器上。 所有这些 容器化 服务的集合，通过网络连接，代表一个集群。
解决的问题 在单台计算机上运行的软件会出现单点故障——如果这台计算机崩溃了，或者有人不小心拔掉了电源线，那么一些关键的业务系统就可能被下线。 这就是为什么现代软件通常被构建为 分布式应用，以集群的形式组合在一起。
如何帮助 集群式的分布式应用在多台机器上运行，消除了单点故障。但构建分布式系统真的很难，事实上，它本身就是一门计算机科学的学科。 对全球系统的需求和多年的试验和错误导致了一种新的技术栈的发展：云原生技术，这些新技术是使分布式系统的操作和创建更容易的构件。..
是什么 节点是一台能与其他计算机（或节点）协同工作以完成一个共同任务的计算机。 以你的笔记本电脑、调制解调器或打印机为例。它们都通过你的 wifi 网络进行通信和协作，各自代表一个节点。 在云计算中，节点可以是一台物理机，也可以是一台虚拟机（即 VM），甚至可以是容器。
解决的问题 虽然一个应用程序可以（很多应用程序确实是）运行在一台独立的机器上，但这样做存在一些风险。也就是说，底层系统的故障将会破坏应用程序。 为了解决这个问题，开发人员开始创建分布式应用程序，其中每个进程都在自己的节点上运行。 因此，节点作为集群或节点组的一部分运行着应用程序或进程，而这些节点一起工作以实现共同的目标。
如何帮助 节点为你提供了一个可以分配给集群的独特计算单元（内存、CPU、网络）。 在云原生平台或应用程序中，一个节点代表一个可执行工作的单元。 理想情况下，单个节点是不作区分的，因为任何特定类型的节点与其相同类型的节点应该是不可区分的。..
是什么 金丝雀部署是一种部署策略，开始时有两个环境：一个有实时流量，另一个包含没有实时流量的更新代码。 流量逐渐从应用程序的原始版本转移到更新版本。 它可以从移动 1% 的实时流量开始，然后是 10%，25%，以此类推，直到所有流量都通过更新的版本运行。 企业可以在生产中测试新版本的软件，获得反馈，诊断错误，并在必要时快速回滚到稳定版本。
“金丝雀” 一词是指 “煤矿中的金丝雀” 的做法，即把金丝雀带入煤矿以保证矿工的安全。 如果出现无味的有害气体，鸟就会死亡，而矿工们知道他们必须迅速撤离。 同样，如果更新后的代码出了问题，现场交通就会被 “疏散” 回原来的版本。
解决的问题 无论测试策略多么彻底，在生产中总是会发现一些bug。 将100%的流量从一个应用程序的一个版本转移到另一个版本，可能会导致更有影响的失败。
如何帮助 金丝雀部署允许企业在将大量流量转移到新版本之前，查看新软件在真实世界场景中的表现。 这种策略使企业能够最大限度地减少停机时间，并在新部署出现问题时快速回滚。 它还允许更深入的生产应用测试，而不会对整个用户体验产生重大影响。..
紧耦合架构（松耦合架构的相反范式）是一种架构风格， 其中许多应用程序组件相互依赖。 这意味着一个组件的更改可能会影响其他组件。 它通常比松耦合架构更容易实现， 但会使系统更容易受到级联故障的影响。 它还意味着需要协调各个组件的部署， 这可能会拖累开发人员的生产力。
紧耦合应用程序架构是一种相当传统的应用程序构建方式。 在某些特定情况下，当我们不需要与微服务 开发的所有最佳实践一致时，它将变得很有用。 这意味着更快、更简单地实现， 和单体应用很像 ，可以加快最初的开发周期。..
是什么 开发运维是一种方法论，其中团队拥有从应用程序开发到生产操作的整个过程，因此 DevOps，它不仅仅是实施一套技术，还需要文化和流程的彻底转变。 DevOps 需要一组工程师来处理小组件（相对于整个功能），从而减少交接——一个常见的错误来源。
解决的问题 传统上，在具有 紧密耦合 单体应用程序 的复杂组织中，工作通常分散在多个组之间。 这导致了多次交接和较长的交货时间。 每次组件或更新准备就绪时，都会将其放入队列中以供下一个团队使用。 因为个人只参与了项目的一小部分，这种方法导致缺乏所有权。 他们的目标是将工作交给下一个小组，而不是为客户提供正确的功能——明显的优先级错位。
到代码最终投入生产时，它经过了这么多开发人员，排了这么多队列，如果代码不起作用，很难追查问题的根源。DevOps 颠覆了这种方法。
如何帮助 让一个团队拥有应用程序的整个生命周期可以最大限度地减少交接，降低部署到生产中的风险，提高代码质量， 因为团队还负责代码在生产中的执行方式，并且由于更多的自主权和所有权而提高了员工满意度。..
是什么 可观测性指的是从所观测的系统采集信号，持续生成并发现可执行的洞察力。 换言之，可观测性允许用户从某个系统的外部输出中洞察该系统的状态并采取（修正）措施。
解决的问题 计算机系统的衡量机制为观测 CPU 时间、内存、磁盘空间等底层信号以及每秒 API 响应次数、每秒错误率、每秒处理的事务数等高级信号和业务信号。
系统的可观测性对其运营和开发成本有重大影响。 可观测系统为操作人员提供了有意义的、可执行的数据，使他们能够达成有利的结果 （即更快的事件响应、更高的开发效率）以及更少的艰辛时刻和更短的停机时间。
如何帮助 请注意，更多的信息并不一定能转化为可观测性更好的系统。 事实上，有时系统生成的大量信息会形成信息噪音，会使得鉴别有价值的健康信号变得更加困难。 可观测性需要在合适的时间为合适的消费者（一个人或一个软件）提供合适的数据，从而做出合适的决策。..
从云原生的角度来看，可靠性是指系统对故障的响应能力。 如果我们有一个可以在基础架构更改和单个组件发生故障时继续工作的分布式系统 ，那么它是可靠的。 另一方面，如果它很容易出现故障，并且需要操作人员手动干预以保持其运行，则它是不可靠的。 云原生应用程序 的目标是构建内在可靠的系统。..
可伸缩性指的是一个系统能有多大的发展。这就是增加做任何系统应该做的事情的能力。 例如，Kubernetes 集群 通过增加或减少 容器化 应用程序的数量来进行伸缩，但这种可伸缩性取决于几个因素。 它有多少节点，每个节点可以处理多少个容器，控制平面可以支持多少条记录和操作？
可伸缩的系统使添加更多容量更容易。主要有两种缩放方法。 一方面，有 水平伸缩 添加更多节点来处理增加的负载。 相比之下，在 垂直伸缩 中，单个节点的功能更强大，可以执行更多事务（例如，通过向单个机器添加更多内存或 CPU）。 可伸缩的系统能够轻松更改并满足用户需求。..
可移植性是一种软件特征，一种可重用性的形式，有助于避免“锁定”到某些操作环境， 例如云提供商、操作系统或供应商。
传统软件通常是为特定环境（例如 AWS 或 Linux）构建的。 而可移植软件可以在不同的操作环境中工作，无需大量返工。 如果应用适配新环境所需的工作量在合理范围内，则该应用被认为是可移植的。 “移植”这个词意味着修改软件并使其适应在不同的计算机系统上工作。..
是什么 蓝绿部署是一种以最小的停机时间更新运行中的计算机系统的策略。 运营商维护两个环境，被称为 “蓝” 和 “绿”。一个为生产流量服务（所有用户目前正在使用的版本），而另一个则被更新。 一旦在非活动（绿色）环境中的测试结束，生产流量就会被切换过来（通常通过使用负载平衡器）。 请注意，蓝绿色的部署通常意味着一次性切换整个环境，包括许多服务。 令人困惑的是，有时这个术语被用于系统内的单个服务。为了避免这种歧义，在提到单个组件时，最好使用 “零停机部署” 一词。
解决的问题 在更新那些由于缺乏向后兼容性而必须“同步”改变的软件时，蓝绿部署允许最小的停机时间。 例如，蓝绿部署适用于一个由网站和数据库组成的在线商店，该商店需要更新，但新版本的数据库不能与旧版本的网站一起使用，反之亦然。 在这种情况下，两者需要同时改变。 如果在生产系统上这样做，客户会注意到停机时间。
如何帮助 对于需要以最小的停机时间进行更新的非云原生软件来说，蓝绿部署是一种合适的策略。 然而，它的使用通常是一种 “气味”，即遗留软件需要重新设计，以便组件可以单独更新。..
是什么 零信任架构规定了一种完全消除信任的IT系统设计和实施方法。其核心原则是 “永不信任，永远验证”，设备或系统本身在与系统的其他组件进行通信时，总是先验证自己。 在今天的许多网络中，在企业网络中，内部的系统和设备可以自由地相互通信，因为它们在企业网络外围的信任边界内。 零信任架构采取了相反的方法，虽然在网络边界内，但系统内的组件在进行任何通信之前首先必须通过验证。
解决的问题 在传统的基于信任的方法中，存在于企业网络周边的系统和设备，其假设是，因为有信任，所以没有问题。然而，零信任架构认识到，信任是一个弱点。 如果攻击者获得了对受信任设备的访问，根据对该设备的信任和访问程度，系统现在很容易受到攻击，因为攻击者在 “受信任 “的网络边界内，能够在整个系统内横向移动。 在零信任架构中，信任被移除，因此减少了攻击面，因为攻击者现在被迫在进入整个系统之前进行验证。
如何帮助 采用零信任架构带来的主要好处是增加安全，减少攻击面。从你的企业系统中移除信任，现在增加了攻击者必须通过的安全门的数量和强度，以获得对系统的其他区域的访问。..
是什么 裸机是指一台物理计算机，更具体地说是一台服务器，它只有一个操作系统。这样区分在现代计算环境中很重要，因为许多（甚至可以说大部分）服务器都是虚拟机。物理服务器通常是一台相当大的计算机，内置强大的硬件。直接在该物理硬件上安装操作系统并运行应用程序，无需虚拟化，称为在“裸机”上运行。
解决的问题 将一个操作系统与一台物理计算机配对是计算的原始模式。物理计算机的所有资源都可以直接用于操作系统，并且不存在虚拟化层，将操作系统指令转换为硬件不会存在人为延迟。
如何帮助 通过将计算机的所有计算资源专用于单个操作系统，这将为操作系统提供最好的性能。如果需要运行的工作负载必须极快地访问硬件资源，裸机可能是合理的解决方案。
在云原生应用程序的上下文中，我们通常将性能认为是扩展到大量并发事件，这可以通过水平扩展（将更多机器添加到您的资源池）来处理。但是某些工作负载可能需要垂直扩展（为现有物理机增加更多功率）和/或极快的物理硬件响应，在这种情况下，裸机更适合。裸机还允许您调整物理硬件，甚至可能是硬件驱动程序，以帮助完成您的任务。..
在数学或计算机科学中，幂等性描述了一种操作，无论你执行多少次，都会得到相同的结果。如果参数相同，一个幂等操作就不会影响它调用的应用程序。..
是什么 强调迭代式开发和自组织团队的一组实践。 与只有在项目结束时才产生价值的瀑布式项目不同，敏捷软件开发更关注于持续的、增量的价值交付，以及交付流程本身的演进和提升。
解决的问题 在软件项目中，让所有利益相关者都能够定义、沟通并理解需求即使并非不可能，也是非常困难的。 并且，客户还希望他们的软件项目在保质、保量、不超预算的情况下，能够如期交付。 由于能实现周期性的交付，敏捷软件开发能够持续地响应需求，并更快地适应不同的情况，这与瀑布式策略恰好相反。
如何帮助 敏捷软件开发也涵盖了所有传统（瀑布式）策略的阶段，比如需求工程、计划、实现、评审、测试和交付。 最大的区别是软件项目的整个时间跨度将被切分成多个迭代，每个迭代都包含了上述所有阶段。 在每次迭代后，团队可以与客户一起评审所创造的价值，并根据最终目标适时地调整需求。 此外，开发团队也可以复盘要采取哪些行动项以改进当前的交付流程。..
是什么 平台即服务（PaaS）是应用程序开发团队部署和运行其应用程序的外部平台。 Heroku、Cloud Foundry、App Engine 是 PaaS 产品的示例。
解决的问题 要利用好 微服务 或 分布式应用程序 等云原生模式， 运维团队和开发人员需要能够免去大量运维工作， 其中包括供应基础设施、处理服务发现 和 负载平衡以及扩展 应用程序等任务。
如何帮助 平台即服务（PaaS）以完全自动化的方式为应用程序开发人员提供通用基础设施工具。 它使开发人员可以了解基础设施并减少对基础设施的担忧，并将更多的时间和精力用于编写应用程序代码。 它还提供了一些监控和 可观察性 来帮助应用程序团队确保他们的应用程序是健康的。..
是什么 容器是由计算机操作系统管理的具有资源和能力限制的运行进程。 容器进程可用的文件被打包为容器镜像。 容器在同一台机器上彼此相邻运行，但通常操作系统会阻止单独的容器进程相互交互。
解决的问题 在容器可用之前，需要单独的机器来运行应用程序。每台机器都需要自己的操作系统，它占用 CPU、内存和磁盘空间， 所有这些都是为了让单个应用程序运行。此外，操作系统的维护、升级和启动是另一个重要的工作来源。
如何帮助 容器共享相同的操作系统及其机器资源，分散了操作系统的资源开销并创建了物理机器的有效使用。 这种能力之所以成为可能，是因为容器之间的交互通常受到限制。 这允许更多的应用程序在同一台物理机器上运行。
但是，有一些限制。由于容器共享相同的操作系统，因此可以认为进程不如替代方法安全。 容器还需要对共享资源进行限制。 为了保证资源， 管理员必须约束和限制内存和 CPU 的使用，以使其他应用程序不会表现不佳。..
是什么 容器编排指的是在动态的环境中自动管理容器化应用的生命周期。 这通过一个容器编排器（大多是 Kubernetes）来执行，实现部署、（自动）扩缩、自愈和监控。 编排是一个比喻用词：编排工具像乐队指挥一样指挥众多容器，确保每个容器（或乐手）各行其是。
解决的问题 手动管理大规模的微服务、安全性和网络通信 （及常见的分布式系统）即使并非不可能，亦会非常困难。 而容器编排能让用户自动化处理所有这些管理任务。
如何帮助 容器编排工具允许用户确定系统的状态。 首先，这些工具会声明系统应具备的框架（例如 x 个容器、y 个 Pod 等）。 然后，编排工具将自动监控基础设施，并在其状态偏离声明的状态时对其进行修正（例如如果一个容器崩溃，则启动一个新的容器）。 这种自动化作业精简了许多工程团队原本需要大量手动完成的复杂运营任务，例如制备、部署、扩缩容、联网、负载均衡和其他活动。..
是什么 容器化是将一个应用程序及其依赖关系捆绑到 容器镜像中的过程。 容器构建过程需要遵守 开放容器倡议(OCI) 标准。 只要输出的是一个符合这个标准的容器镜像，使用哪种容器化工具并不重要。
解决的问题 在容器盛行之前，企业依靠虚拟机 (VMs) 在一台 裸机 上协调多个应用程序。 虚拟机比容器大得多，需要一个管理程序来运行。由于这些较大的虚拟机模板的存储、备份和传输，创建虚拟机模板也很慢。 此外，虚拟机可能会出现配置漂移，这违反了 不变性 的原则。
如何帮助 容器镜像是轻量级的（与传统的虚拟机不同），容器化过程需要一个带有依赖性列表的文件。 这个文件可以被版本控制，构建过程也可以自动化，允许一个组织在自动化过程中关注其他优先事项。 容器镜像由一个唯一的标识符来存储，该标识符与它的确切内容和配置相联系。 当容器被安排和重新安排时，它们总是被重置为其初始状态，从而消除了配置漂移。..
是什么 容器即服务（CaaS）是一种云服务，有助于使用基于 容器 的 抽象 管理和部署应用程序。 这项服务可以部署在企业内部或云中。
CaaS 供应商提供了一个框架或协调平台，使容器部署和管理的关键 IT 功能自动化。 它帮助开发者建立安全和 可伸缩 的容器化应用。 因为用户只购买他们需要的资源（调度能力、负载平衡等），他们可以节省资金并提高效率。 容器创造了一致的环境，以快速开发和交付可以在任何地方运行的 云原生应用。
解决的问题 如果没有 CaaS，软件开发团队需要部署、管理和监控容器运行的底层基础设施。
如何帮助 当把容器化应用部署到 CaaS 平台时，用户可以通过日志聚合和监控工具获得对系统性能的可见性。 CaaS 还包括 自动伸缩 和协调管理的内置功能。 它使团队能够建立高可见性和高可用性的 分布式系统。 此外，通过允许快速部署，CaaS 提高了团队的开发速度。在容器确保一致的部署目标的同时，CaaS 通过减少管理部署所需的 DevOps 资源，降低了工程运营成本。..
云原生词汇表的内容存储在这个 GitHub 仓库中，在这里你可以找到关于词汇表的 议题、 PR 和 讨论 的列表。
你可以通过四种方式做出贡献：
在现有的议题上工作 提出新术语 更新现有术语 云原生词汇表翻译帮助 加入 Glossary 社区 如果你想定期做出贡献，可以考虑加入我们每月的词汇工作组会议。你可以在 CNCF 日历 中找到会议细节。 你也可以在 CNCF Slack 的 #glossary 频道中与维护者和其他贡献者联系，我们很乐意见到你!
在现有的议题上工作 进入云原生词汇表 GitHub 仓库的 议题。在那里你会看到一个所有议题的列表。 你可以通过标签来过滤（例如，English language, help needed, good first issue）。请注意，你需要一个 GitHub 账户来做这些事情。
确保你感兴趣的术语还没有分配给某人。这里你可以看到，前三个术语是可用的，而下一个术语已经被分配了：
一旦你找到了一个你想做的术语，就在议题中说出来。点击它并添加一个评论。
此外，请加入 CNCF Slack 的 #glossary 频道， 让维护者知道你为一个新术语提出了一个议题（最好标记 @Catherine Paganini, @jmo, @Seokho Son, @Jihoon Seo, 和/或 @iamnoah 以确保他们不会错过它）。 请注意，你一次只能认领一个术语。如果你想做多个术语，请在申请下一个术语之前完成前一个术语。
一旦他们把它分配给你，你就可以开始工作了。接下来的步骤，请参考 提交一个新术语（创建一个PR）部分。
提出新术语 你可以提出一个新的术语让别人去研究，或者自己创造一个新的定义。无论哪种方式，你都要从创建一个议题开始。 请注意，术语必须符合 CNCF的云原生定义。 唯一的例外是理解云原生概念所需的基础性术语。
以下是为那些还不熟悉 GitHub 的人提供的分步指南。 如果你是 GitHub 的专业人员，请特别看一下，确保你使用我们的议题模板，适当的命名惯例，在 Slack 上声明一个 PR（否则我们可能会错过它），以及在哪里找到文件模板。 在开始之前，请确保阅读 风格指南–谢谢!..
是什么 软件即服务 (SaaS) 允许用户通过互联网连接或使用云服务。 常见的例子有电邮、日历和办公工具（例如 Gmail、AWS、GitHub、Slack）。 SaaS 以按需付费的方式提供完整的软件解决方案。 所有运维任务和应用数据由服务提供商处理。
解决的问题 传统的商业软件被安装在独立的计算机上，需要管理员维护和更新。 例如：某组织可能在企业内部使用客户关系管理 (CRM) 软件。 该软件需要内部 IT 部门采购、安装、确保安全、维护和定期升级，为 IT 团队增加了负担。 与许可证、安装和潜在附加硬件相关的前期成本可能令人望而却步。 也很难按需响应，很难随着业务增长或变化快速扩缩。
如何帮助 SaaS 应用无需内部 IT 部门付出任何特别努力即可工作。 这些应用由供应商安装、维护、升级和确保安全。 扩缩、可用性和容量问题由服务提供商处理，采用按需付费的模式。 对于想要使用企业级应用的各个组织而言，SaaS 是一种经济实惠的方式。..
是什么 事件驱动架构是一种提倡事件的创建、处理和消费的软件架构。 事件是对应用程序状态的任何更改。 例如，在拼车应用上叫车代表一个事件。 这种架构创建了一个结构，在该结构中，事件可以从它们的源（请求乘车的应用程序）正确地路由到所需的接收器（附近可用司机的应用程序）。
解决的问题 随着越来越多的数据变得实时，寻找可靠的方法来确保捕获事件并将其路由到必须处理事件请求的适当服务变得越来越具有挑战性。 处理事件的传统方法通常无法保证消息被恰当地路由或发送或接收。 随着应用程序的扩展，编排事件变得更具挑战性。
如何帮助 事件驱动架构为所有事件建立了一个中心枢纽（例如，Kafka）。 然后定义事件生产者（源）和消费者（接收者），中心事件枢纽保证事件的流动。 这种架构确保服务保持解耦，并且事件从生产者正确路由到消费者。 生产者通常通过 HTTP 协议接收传入事件，然后路由事件信息。..
是什么 数据库即服务 (DBaaS) 是由云运营商（公共或私有）管理的服务，它支持应用程序，而无需应用程序团队执行传统的数据库管理功能。 DBaaS 允许应用程序开发人员利用数据库，而无需成为专家或聘请数据库管理员 (DBA) 来保持数据库最新状态。
解决的问题 传统上，在本地设置中，组织必须定期投资额外的存储和处理能力，以适应可能昂贵的数据库扩展。 此外，开发人员在 IT 基础架构团队的帮助下配置和配置数据库，从而降低了数据库驱动应用程序的部署速度。 加载和执行它们也需要更长的时间。
如何帮助 DBaaS 允许开发人员将所有管理/行政操作外包给基于云的服务提供商。 服务提供商确保数据库顺利运行，包括配置管理、备份、补丁、升级、服务监控等，并通过用户友好的界面进行管理。 DBaaS 可帮助组织更快地开发企业级应用程序，同时最大限度地降低数据库成本。..
是什么 双向 TLS (mTLS) 是一种用于对两个服务之间发送的消息进行身份验证和加密的技术。 双向 TLS (mTLS) 是标准的传输层安全性协议(TLS) ， 但不是仅验证一个连接的身份，而是验证双方。
解决的问题 微服务通过网络进行通信， 就像您的 wifi 网络一样，通过该网络传输的通信可能会被黑客入侵。 mTLS 确保没有未经授权的一方监听或冒充合法请求。
如何帮助 mTLS 确保客户端和服务器之间的双向流量是安全和可信的， 为进入网络或应用程序的用户提供了额外的安全层。 它还验证不遵循登录过程的客户端设备连接，例如物联网 (IoT) 设备。 mTLS 可以防止诸如路径上的攻击、欺骗攻击、凭证填充、暴力攻击等攻击。..
是什么 水平伸缩是一种通过添加更多节点来增加系统容量的技术，而不是向单个节点添加更多计算资源（后者称为垂直伸缩）。 假设我们有一个 4GB RAM 的系统，并且想要将其容量增加到 16GB RAM，水平伸缩意味着通过添加 4 x 4GB RAM 而不是切换到 16GB RAM 系统来实现。
这种方法通过添加新实例或节点来提高应用程序的性能，以更好地均衡工作负载。 简而言之，它旨在减少服务器的负载，而不是扩大单个服务器的容量。
解决的问题 随着对应用程序的需求增长超出该应用程序实例的当前容量，我们需要找到一种方法来伸缩（增加容量）系统。 我们可以向系统添加更多节点（水平伸缩）或向现有节点添加更多计算资源（垂直伸缩）。
如何帮助 水平伸缩允许应用程序在底层集群设置的范围内进行伸缩。通过向系统添加更多实例，应用程序可以处理更多请求。 如果单个节点每秒可以处理 1,000 个请求，则每增加一个节点，每秒的请求总数应该会增加大约 1,000 个。 这使得应用程序可同时执行更多工作，而无需特别增加任何单个节点的容量。
相关词汇 垂直伸缩 自动伸缩..
松耦合架构（紧耦合架构的相反范式）是一种架构风格， 其中应用程序的各个组件彼此独立构建。 每个组件，有时称为 微服务，都是为了执行特定功能而构建的， 以便被任意数量的其他服务使用。 这种模式的实现通常比紧耦合架构慢。 但有许多好处，特别是随着应用程序的不断扩展。 松耦合的应用程序允许团队独立开发功能、部署和扩展， 这允许组织快速迭代各个组件。 应用程序开发速度更快，团队结构可以围绕应用程序的能力构建，专注于他们的特定应用程序。..
是什么 托管服务是一种软件产品，其运营和管理由第三方负责。 例如类似 Amazon RDS 的数据库即服务或类似 Datadog 的外部监控服务。
解决的问题 软件的管理比较复杂，尤其是要考虑现代技术栈所包含的各种不同技术。 而想要将管理做到面面俱到并招募能胜任此职的内部专家，要么成本过于高昂，要么会耗用工程师的宝贵时间。 你的团队应投入精力构建新功能，而不是处理可以通过外包就能轻松解决的运营任务。
如何帮助 托管服务从一开始就处于使用就绪状态，运营开销非常小。 托管服务具备良好定义的、通常由 API 驱动的边界， 便于各个组织将超出其核心竞争力的任务有效外包出去。..
是什么 网站可靠性工程（SRE） 是一门结合运营和软件工程的学科。 后者特别适用于基础设施和运营问题。 这意味着，网站可靠性工程师不是构建产品功能，而是构建系统来运行应用程序。 与 DevOps 有相似之处，但 DevOps 专注于将代码投入生产环境， 而 SRE 是确保在生产环境中运行的代码正常工作。
解决的问题 确保应用程序可靠运行需要多种功能， 从性能监控、警报、调试到故障排除。 没有这些，系统操作员只能对问题做出反应，而不是主动努力避免它们 —— 停机只是时间问题。
如何帮助 网站可靠性工程通过不断改进底层系统来最小化软件开发过程的成本、时间和工作量。 该系统持续测量和监控基础设施和应用程序组件。 当出现问题时，系统会提示网站可靠性工程师何时、何地以及如何修复它。 这种方法通过自动化任务来帮助创建高度可扩展和可靠的软件系统。..
是什么 微服务是一种利用云原生技术进行应用开发的现代方法。虽然现代应用程序，如 Netflix，看起来是一个单一的应用程序，但它们实际上是一个较小的服务的集合——所有的服务都密切配合。 例如，一个允许你访问、搜索和预览视频的单一页面很可能是由较小的服务提供的，它们各自处理其中的一个方面（如搜索、认证和在浏览器中运行预览）。 简而言之，微服务指的是一种应用架构模式，通常与 单体应用 形成对比。
解决的问题 微服务是对单体应用所带来的挑战的一种回应。一般来说，一个应用程序的不同部分需要分别进行 伸缩。 例如，一个在线商店将有更多的产品视图而不是结账。这意味着你需要更多的产品视图功能的运行，而不是结账。 在一个单一的应用程序中，这些逻辑位不能被单独部署。如果你不能单独扩展产品功能，你将不得不复制整个应用程序和所有其他你不需要的组件–这是一种低效的资源利用。 单机式应用程序也使开发人员容易屈服于设计陷阱。因为所有的代码都在一个地方，所以更容易使这些代码 高耦合，更难执行关注点分离的原则。 单机通常要求开发人员了解整个代码库，然后才能有成效。
如何帮助 将功能分离成不同的微服务，使它们更容易独立部署、更新和扩展。通过允许不同的团队专注于更大的应用中他们自己的一小部分，也让他们更容易在不对组织的其他部分产生负面影响的情况下对他们的应用进行工作。 虽然微服务解决了许多问题，但它们也产生了运营开销——你需要部署和跟踪的东西增加了一个数量级或更多。许多 云原生技术 旨在使微服务更容易部署和管理。..
是什么 虚拟化，在云原生计算的背景下，是指将一台物理计算机，有时称为服务器，并允许它运行多个隔离的操作系统的过程。 这些隔离的操作系统及其专用的计算资源（CPU、内存和网络）被称为虚拟机或VM。 当我们谈论虚拟机时，我们在谈论一个软件定义的计算机。 它看起来和行动都像一台真正的计算机，但与其他虚拟机共享硬件。 举个例子，你可以从AWS租赁一台 “计算机”–该计算机实际上是一个虚拟机。
解决的问题 虚拟化解决了许多问题，包括通过允许更多的应用程序在同一台物理机器上运行，同时为了安全起见仍然相互隔离，从而改善物理硬件的使用。
如何帮助 在虚拟机上运行的应用程序没有意识到他们正在共享一台物理计算机。 虚拟化还允许数据中心的用户在几分钟内启动一台新的 “计算机”（又称虚拟机），而不必担心在数据中心增加一台新计算机的物理限制。 虚拟机还使用户能够加快获得新的虚拟计算机的时间。..
是什么 虚拟机（VM）是一台计算机及其操作系统，不受特定硬件的约束。 虚拟机依靠 虚拟化 将一台物理计算机分割成多个虚拟计算机。 这种分离使组织和基础设施供应商能够轻松地创建和销毁虚拟机，而不影响底层硬件。
解决的问题 虚拟机利用了虚拟化的优势。 当 裸机 机器被束缚在一个单一的操作系统上时，该机器的资源的使用受到一定的限制。 另外，当一个操作系统被绑定在一个单一的物理机上时，它的可用性直接与该硬件联系在一起。 如果物理机由于维护或硬件故障而脱机，操作系统也会脱机。
如何帮助 通过消除操作系统和单一物理机之间的直接关系，你解决了裸机的几个问题：配置时间、硬件利用率和弹性。
由于不需要购买、安装或配置新的硬件来支持它，新计算机的配置时间得到了极大的改善。 虚拟机通过在一台物理机上放置多个虚拟机，使你能够更好地利用现有的物理硬件资源。 不受特定物理机的约束，虚拟机也比物理机更有弹性。 当一台物理机需要下线时，在其上运行的虚拟机可以被转移到另一台机器上，几乎没有停机时间。..
是什么 API (Application Programming Interface, 即应用程序接口) 是计算机程序间交互的一种方式。 就像人类可以通过网页与网站进行交互一样，API 允许计算机程序之间进行交互。 与人类的交互不同，API 可以限制对方可以问什么和不能问什么。对交互的限制有助于在程序之间创建稳定、实用的信息传输。
解决的问题 随着应用程序变得越来越复杂，小的代码更改也可能会对其他功能产生巨大的影响。如果应用程序想要在扩展的同时保持其稳定性，就需要用模块化的方法来管理应用程序的功能。没有 API，应用程序之间就缺乏一个交互的参照标准。如果没有共享的参照标准，应用程序如何进行 伸缩 和集成将是一个挑战。
如何帮助 API 允许计算机程序或应用程序以一种明确的、可理解的方式进行交互和共享信息。它们是现代应用程序的基本构建块，并为开发人员提供了一种将应用程序集成在一起的方法。每当您听说一组 微服务 在一起工作时，就可以推断它们是通过某种 API 进行交互的。..
是什么 当我们说到有状态（和无状态）应用时， 状态是指应用需要存储以便其按设计运行的任何数据。 例如，任何能记住您购物车的在线商店都是有状态应用。
解决的问题 使用一个应用通常需要多个请求。 例如，使用网上银行时，您将通过输入密码（请求 #1）来验证自己的身份， 然后您可以将钱转给某个朋友（请求 #2），最后您需要查看转账详情（请求 #3）。 为了保证正常运行，每一步都必须记住前面的步骤，银行需要记住每个人的账户状态。 今天我们使用的大多数应用至少总有一部分是有状态的， 因为这些应用会存储诸如偏好和设置之类的东西以改善用户体验。
如何帮助 有几种方法可以为有状态应用存储状态。 最简单的是将状态保存在内存中，而不是将其持久保存在任何其他地方。 这样做的问题是，每次应用必须重启时，所有状态都会丢失。 为了防止这种情况发生，状态被持久存储在本地（磁盘上）或数据库系统中。..
是什么 云计算是一种通过互联网按需提供计算资源（如 CPU、网络和磁盘功能）的模型。 云计算使用户能够在远程物理位置访问和使用计算能力。 AWS、GCP、Azure、DigitalOcean 等云提供商都为第三方提供了在多个地理位置租用计算资源的能力。
解决的问题 传统上，组织在尝试扩展计算能力的使用时面临两个主要问题。 他们要么获取、支持、设计和支付托管物理服务器和网络的设施，要么扩展和维护这些设施。 云计算允许组织将部分计算需求外包给另一个组织。
如何帮助 云提供商为组织提供按需租用计算资源并按使用付费的能力。这允许进行两项主要创新： 组织可以在不浪费时间计划和花费金钱或资源在新的物理基础设施上的情况下进行尝试，并且他们可以根据需要和按需伸缩。 云计算允许组织根据需要采用尽可能多或尽可能少的基础设施。..
是什么 云原生安全是一种将安全性构建到 云原生应用程序 中的方法。 它确保安全是从开发到生产的整个应用程序生命周期的一部分。 云原生安全旨在确保与传统安全模型相同的标准，同时适应云原生环境的特殊性，即快速的代码更改和高度短暂的基础设施。 云原生安全与称为 测试左移 的实践高度相关。
解决的问题 传统的安全模型是根据许多不再有效的假设构建的。 云原生应用程序变化频繁，使用大量开源工具和库，通常运行在供应商控制的基础设施中，并且会受到快速的基础设施变化的影响。 代码审查、长质量保证周期、基于主机的漏洞扫描和最后一分钟的安全审查无法与云原生应用程序一起伸缩。
如何帮助 云原生安全引入了一种新的工作方式，通过从传统的安全模型迁移到发布周期的每个步骤都涉及安全的模型来保护应用程序。 人工审核和检查在很大程度上被自动扫描所取代。 快速代码发布管道与在编译之前扫描代码以查找漏洞的工具集成在一起。 开源库从受信任的来源中提取并监控漏洞。 云原生安全模型不是减缓变化，而是通过频繁更新易受攻击的组件或确保定期更换基础设施来拥抱它。..
云原生词汇表 云原生词汇表是由 CNCF 商业价值小组委员会 (BVS, Business Value Subcommittee) 领导的一个项目。 该项目的目的是在不需要任何先决技术知识的情况下，以通俗易懂的语言阐释云原生概念。
社区贡献 我们欢迎所有人对本词汇表提出修改、添加和改进建议。我们采用了 CNCF 所管理的社区驱动流程来开发和改进这个共享词典。 该词汇表提供了一个厂商中立的平台，用于管理云原生技术的共享词汇表。欢迎所有参与者在遵守本项目的目的和章程的前提下作出贡献。
任何想要贡献的人都可以提交 GitHub issue 或 创建 PR。欲了解更多信息，请查看 如何贡献 和遵循 样式指南，并加入 CNCF Slack 中的 #glossary 频道。 这里还有 #glossary-localizations 频道，供想要将 glossary 翻译成母语的人使用。
致谢 云原生词汇表可从 CNCF 营销委员会 (CNCF Marketing Committee) (商业价值小组委员会) 获得, 包括 Catherine Paganini, Chris Aniszczyk, Daniel Jones, Jason Morgan, Katelin Ramer, Mike Foster, Seokho Son 以及更多的贡献者。 如想获得完整的贡献者名单, 请跳转至 GitHub Pages 页.
中文版的云原生词汇表由 Chester Cheung, Brian Yan, Jacob953 Yu, Submarinee 和其他贡献者维护。..
是什么 云原生技术，也称为云原生技术栈，是用于构建 云原生应用程序 的技术。 使组织能够在公共云、私有云和混合云等现代动态环境中构建和运行可伸缩的应用程序，他们坚持“云的承诺”并充分利用云计算的优势。 它们从头开始设计，以利用云计算和容器的功能，服务网格、微服务和不可变的基础设施就是这种方法的例证。
解决的问题 云原生技术栈有许多不同的技术类别，可应对各种挑战。 如果你看看 CNCF 云原生全景图，你会看到它涉及到多少不同的领域。 但在高层次上，它们解决了一组主要挑战：传统 IT 运营模式的缺点。挑战包括难以创建可伸缩、容错、自我修复的应用程序，以及资源利用效率低下等。
如何帮助 虽然每种技术都解决了一个非常具体的问题，但作为一个整体，云原生技术支持松散耦合的系统，这些系统具有弹性、可管理性和可观察性。 结合强大的自动化，它们使工程师能够以最少的工作频繁且可预测地进行高影响力的更改。 云原生系统的理想特性更容易通过云原生堆栈实现。..
是什么 云原生应用程序专门设计用于利用 云计算 中的创新。 这些应用程序可以轻松地与其各自的云架构集成，充分利用云的资源和 可伸缩性 功能。 它还指利用云计算驱动的基础设施创新的应用程序。 今天的云原生应用程序包括在云提供商的数据中心和本地云原生平台上运行的应用程序。
解决的问题 传统上，本地环境以相当定制的方式提供计算资源。 每个数据中心都有与特定环境 紧密耦合 应用程序的服务，通常严重依赖于基础设施的手动配置，例如 虚拟机 和服务。 这反过来又将开发人员及其应用程序限制在该特定数据中心。 不是为云设计的应用程序无法利用云环境的弹性和伸缩能力。 例如，需要手动干预才能正确启动的应用程序无法自动伸缩，也无法在发生故障时自动重启。
如何帮助 虽然云原生应用程序没有“一刀切”的路径，但它们确实有一些共性。 云原生应用程序具有弹性、可管理性，并由配套的云服务套件提供帮助。 各种云服务实现了高度的 可观察性，使用户能够在问题升级之前检测和解决问题。 结合强大的自动化，它们使工程师能够以最少的工作频繁且可预测地进行高影响力的更改。..
是什么 在主从式架构（客户端-服务器架构）中，构成应用程序的逻辑（或代码）会被分成两个或多个组件： 一个期望工作被完成的客户端（例如，运行在你的 web 浏览器中的 Gmail web 应用程序）， 以及一个或多个满足该请求的服务器（例如，运行在云中心的谷歌计算机上的“发送电子邮件”服务）。 在这个例子中，你所写的外发邮件是由客户端（运行在您的 web 浏览器中的 web 应用程序）发送到服务器（Gmail 的计算机，它将您的外发邮件转发给对应的收件人）。
这与在一个地方完成所有工作的独立应用程序（如桌面应用程序）形成了对比。例如，像 Microsoft Word 这样的文字处理程序可能会完全安装并运行在你的计算机上。
解决的问题 主从式架构解决了自包含应用程序所带来的一个巨大挑战：定期更新。在一个自包含应用程序中的每次更新，用户都必须下载并安装最新版本。 想象一下，你在浏览亚马逊之前，必须把亚马逊的所有产品目录下载到自己的电脑上!
如何帮助 通过在远程服务器或服务中实现应用程序逻辑，操作人员可以在不需要修改客户端的逻辑的情况下进行应用程序更新。 这意味着可以更频繁地进行更新。将数据存储在服务器上，允许许多客户端都看到并共享相同的数据。 考虑一下使用在线文字处理程序与传统离线文字处理程序之间的区别。对于前者，你的文件存在于服务器端以便与其他用户共享，这些用户只需从服务器下载它们。 而在传统世界中，文件需要复制到可移动媒体（软盘!）才能与他人共享。..
自动伸缩，通常是指在计算资源方面，系统能够进行自动 伸缩 的能力。自动伸缩系统可在需要时自动添置资源，通过伸缩来满足不断变化的用户需求。 自动伸缩的过程各不相同，可基于不同指标进行配置，例如内存或处理时间。托管云服务相较于大多数本地部署环境，有更多的可选项和实施项，因此往往都搭配有自动伸缩功能。
在此之前，基础设施和应用程序的架构设计会考虑到系统峰值的使用情况。这种架构意味着大部分资源没有得到充分利用，并且在面对不断变化的用户需求时缺乏弹性。 缺乏弹性则意味着低谷时的业务成本增加，而在高峰时又会由于需求过盛引起的服务中断而导致业务流失。
通过利用云，虚拟化和容器化应用程序及其依赖项等手段，组织可以构建随用户需求而伸缩的应用程序。 他们可以监控应用程序的流量并自动伸缩，从而提供最佳的用户体验。以 Netflix 每周五晚上的收视率增长为例，自动伸缩意味着动态添置更多资源：即增加服务器数量以支持更多视频播放需求，并在需求回落后同步缩减。
相关词汇 水平伸缩 垂直伸缩..