Merge pull request #1500 from cncf/dev-zh

[zh] Update Chinese version in main with dev-zh

content/zh-cn/api-gateway.md

@@ -21,6 +21,5 @@ API 网关是一种通过聚合多个应用程序的 [API](/zh-cn/application-pr
 
 通过为多个 API 提供一个统一的访问入口，API 网关能够让组织更容易地将交叉性业务或安全性逻辑移交到一个可集中管理的地方。
 应用的消费端也只需要访问单个地址就可以满足其所有需求。
-
 通过为系统中的所有 web 服务提供统一的访问入口，API 网关还可以简化诸如安全性和[可观测性](/observability/)之类的运维问题。
 由于所有请求都流经 API 网关，因此它可以中心化的为这些请求添加诸如指标收集、速率限制和授权等功能。

content/zh-cn/bare-metal-machine.md

@@ -2,6 +2,7 @@
 title: 裸机
 status: Completed
 category: 技术
+tags: ["基础设施", "", ""]
 ---
 
 ## 是什么

content/zh-cn/chaos-engineering.md

@@ -7,12 +7,12 @@ tags: ["安全", "", ""]
 
 ## 是什么
 
-混沌工程或 CE 是在生产中对 [分布式系统](/distributed-systems/) 进行实验的学科，以建立对系统承受动荡和意外情况时能力的信心。
+混沌工程或 CE 是在生产中对 [分布式系统](/zh-cn/distributed-systems/) 进行实验的学科，以建立对系统承受动荡和意外情况时能力的信心。
 
 ## 解决的问题
 
-[SRE](/site_reliability_engineering/) 和 [DevOps](/devops/) 实践侧重于提高产品弹性和 [可靠性](/reliability/) 的技术。
-系统在故障容灾时确保服务质量的能力通常是对软件开发提出的要求。这里涉及到几个方面可能导致应用程序中断，例如基础设施、平台或（基于[微服务](/microservices/)）的应用程序的其他部分。
+[SRE](/zh-cn/site_reliability_engineering/) 和 [DevOps](/zh-cn/devops/) 实践侧重于提高产品弹性和 [可靠性](/zh-cn/reliability/) 的技术。
+系统在故障容灾时确保服务质量的能力通常是对软件开发提出的要求。这里涉及到几个方面可能导致应用程序中断，例如基础设施、平台或（基于[微服务](/zh-cn/microservices/)）的应用程序的其他部分。
 高频地持续部署新功能到生产环境会增加服务中断和恶性事件发生的可能性，乃至于对业务产生重大影响。
 
 ## 如何帮助

content/zh-cn/cloud-native-apps.md

@@ -15,7 +15,7 @@ tags: ["应用程序", "", ""]
 ## 解决的问题
 
 传统上，本地环境以相当定制的方式提供计算资源。
-每个数据中心都有与特定环境 [紧密耦合](/tightly-coupled-architectures/) 应用程序的服务，通常严重依赖于基础设施的手动配置，例如 [虚拟机](/zh-cn/virtual-machine/) 和服务。
+每个数据中心都有与特定环境 [紧密耦合](/zh-cn/tightly-coupled-architectures/) 应用程序的服务，通常严重依赖于基础设施的手动配置，例如 [虚拟机](/zh-cn/virtual-machine/) 和服务。
 这反过来又将开发人员及其应用程序限制在该特定数据中心。
 不是为云设计的应用程序无法利用云环境的弹性和伸缩能力。
 例如，需要手动干预才能正确启动的应用程序无法自动伸缩，也无法在发生故障时自动重启。

content/zh-cn/container-orchestration.md

@@ -0,0 +1,24 @@
+---
+title: 容器编排
+status: Completed
+category: 概念
+---
+
+## 是什么
+
+[容器](/zh-cn/container/)编排指的是在动态的环境中自动管理容器化应用的生命周期。
+这通过一个容器编排器（大多是 [Kubernetes](/zh-cn/kubernetes)）来执行，实现部署、（自动）扩缩、自愈和监控。
+编排是一个比喻用词：编排工具像乐队指挥一样指挥众多容器，确保每个容器（或乐手）各行其是。
+
+## 解决的问题
+
+手动管理大规模的[微服务](/zh-cn/microservices)、安全性和网络通信
+（及常见的[分布式系统](/zh-cn/distributed-systems)）即使并非不可能，亦会非常困难。
+而容器编排能让用户自动化处理所有这些管理任务。
+
+## 如何帮助
+
+容器编排工具允许用户确定系统的状态。
+首先，这些工具会声明系统应具备的框架（例如 x 个容器、y 个 Pod 等）。
+然后，编排工具将自动监控基础设施，并在其状态偏离声明的状态时对其进行修正（例如如果一个容器崩溃，则启动一个新的容器）。
+这种自动化作业精简了许多工程团队原本需要大量手动完成的复杂运营任务，例如制备、部署、扩缩容、联网、负载均衡和其他活动。

content/zh-cn/containerization.md

@@ -7,19 +7,19 @@ tags: ["应用程序", "", ""]
 
 ## 是什么
 
-容器化是将一个应用程序及其依赖关系捆绑到 [容器图像](/zh-cn/container-image/) 中的过程。
+容器化是将一个应用程序及其依赖关系捆绑到 [容器镜像](/zh-cn/container-image/) 中的过程。
 容器构建过程需要遵守 [开放容器倡议](https://opencontainers.org)(OCI) 标准。
 只要输出的是一个符合这个标准的容器镜像，使用哪种容器化工具并不重要。
 
-## 解决的问题 
+## 解决的问题
 
-在容器盛行之前，企业依靠虚拟机 (VMs) 在一台 [裸机](/bare-metal-machine/) 上协调多个应用程序。
+在容器盛行之前，企业依靠虚拟机 (VMs) 在一台 [裸机](/zh-cn/bare-metal-machine/) 上协调多个应用程序。
 虚拟机比容器大得多，需要一个管理程序来运行。由于这些较大的虚拟机模板的存储、备份和传输，创建虚拟机模板也很慢。
-此外，虚拟机可能会出现配置漂移，这违反了 [不变性](/immutable-infrastructure/) 的原则。
+此外，虚拟机可能会出现配置漂移，这违反了 [不变性](/zh-cn/immutable-infrastructure/) 的原则。
 
 ## 如何帮助
 
-容器图像是轻量级的（与传统的虚拟机不同），容器化过程需要一个带有依赖性列表的文件。
+容器镜像是轻量级的（与传统的虚拟机不同），容器化过程需要一个带有依赖性列表的文件。
 这个文件可以被版本控制，构建过程也可以自动化，允许一个组织在自动化过程中关注其他优先事项。
 容器镜像由一个唯一的标识符来存储，该标识符与它的确切内容和配置相联系。
 当容器被安排和重新安排时，它们总是被重置为其初始状态，从而消除了配置漂移。

content/zh-cn/containers-as-a-service.md

@@ -1,13 +1,13 @@
 ---
-title: 容器即服务
+title: 容器即服务 (CaaS)
 status: Completed
 category: 技术
 tags: ["平台", "", ""]
 ---
 
 ## 是什么
 
-容器即服务（CaaS）是一种云服务，有助于使用基于 [容器](/zh-cn/container/) 的 [抽象](/abstraction/) 管理和部署应用程序。
+容器即服务（CaaS）是一种云服务，有助于使用基于 [容器](/zh-cn/container/) 的 [抽象](/zh-cn/abstraction/) 管理和部署应用程序。
 这项服务可以部署在企业内部或云中。
 
 CaaS 供应商提供了一个框架或协调平台，使容器部署和管理的关键 IT 功能自动化。

content/zh-cn/devops.md

@@ -12,7 +12,7 @@ DevOps 需要一组工程师来处理小组件（相对于整个功能），从
 
 ## 解决的问题
 
-传统上，在具有 [紧密耦合](/tightly-coupled-architectures/) [单体应用程序](/zh-cn/monolithic_apps/) 的复杂组织中，工作通常分散在多个组之间。
+传统上，在具有 [紧密耦合](/zh-cn/tightly-coupled-architectures/) [单体应用程序](/zh-cn/monolithic_apps/) 的复杂组织中，工作通常分散在多个组之间。
 这导致了多次交接和较长的交货时间。 每次组件或更新准备就绪时，都会将其放入队列中以供下一个团队使用。
 因为个人只参与了项目的一小部分，这种方法导致缺乏所有权。 他们的目标是将工作交给下一个小组，而不是为客户提供正确的功能——明显的优先级错位。
 

content/zh-cn/distributed-systems.md

@@ -8,7 +8,7 @@ tags: ["架构", "", ""]
 ## 是什么
 
 分布式系统是通过网络连接的自主计算元素的集合，在用户看来是一个单一的连贯系统。
-一般被称为 [节点](/nodes/)，这些组件可以是硬件设备（如电脑、手机）或软件进程。
+一般被称为 [节点](/zh-cn/nodes/)，这些组件可以是硬件设备（如电脑、手机）或软件进程。
 节点被编程以实现一个共同的目标，为了协作，它们通过网络交换信息。
 
 ## 解决的问题

content/zh-cn/event-driven-architecture.md

@@ -0,0 +1,25 @@
+---
+title: 事件驱动架构
+status: Completed
+category: 概念
+---
+
+## 是什么
+
+事件驱动架构是一种提倡事件的创建、处理和消费的软件架构。
+事件是对应用程序状态的任何更改。
+例如，在拼车应用上叫车代表一个事件。
+这种架构创建了一个结构，在该结构中，事件可以从它们的源（请求乘车的应用程序）正确地路由到所需的接收器（附近可用司机的应用程序）。
+
+## 解决的问题
+
+随着越来越多的数据变得实时，寻找可靠的方法来确保捕获事件并将其路由到必须处理事件请求的适当[服务](/zh-cn/service/)变得越来越具有挑战性。
+处理事件的传统方法通常无法保证消息被恰当地路由或发送或接收。
+随着应用程序的扩展，编排事件变得更具挑战性。
+
+## 如何帮助
+
+事件驱动架构为所有事件建立了一个中心枢纽（例如，Kafka）。
+然后定义事件生产者（源）和消费者（接收者），中心事件枢纽保证事件的流动。
+这种架构确保服务保持解耦，并且事件从生产者正确路由到消费者。
+生产者通常通过 HTTP 协议接收传入事件，然后路由事件信息。

content/zh-cn/horizontal-scaling.md

@@ -7,10 +7,10 @@ tags: ["基础设施", "", ""]
 
 ## 是什么
 
-水平伸缩是一种通过添加更多[节点](/nodes/)来增加系统容量的技术，而不是向单个节点添加更多计算资源（后者称为[垂直伸缩](/zh-cn/vertical-scaling/)）。
+水平伸缩是一种通过添加更多[节点](/zh-cn/nodes/)来增加系统容量的技术，而不是向单个节点添加更多计算资源（后者称为[垂直伸缩](/zh-cn/vertical-scaling/)）。
 假设我们有一个 4GB RAM 的系统，并且想要将其容量增加到 16GB RAM，水平伸缩意味着通过添加 4 x 4GB RAM 而不是切换到 16GB RAM 系统来实现。
 
-这种方法通过添加新实例或[节点](/nodes/)来提高应用程序的性能，以更好地均衡工作负载。
+这种方法通过添加新实例或[节点](/zh-cn/nodes/)来提高应用程序的性能，以更好地均衡工作负载。
 简而言之，它旨在减少服务器的负载，而不是扩大单个服务器的容量。
 
 ## 解决的问题

content/zh-cn/infrastructure-as-a-service.md

@@ -1,22 +1,21 @@
 ---
-title: 基础设施即代码 (IaaS)
+title: 基础设施即服务 (IaaS)
 status: Completed
 category: 技术
 tags: ["基础设施", "", ""]
 ---
 
 ## 是什么
 
-基础设施即代码，或者 IaaS ，是一种 [云计算](/zh-cn/cloud-computing/) 服务模型，
-它提供 [物理](/bare-metal-machine/) 或 [虚拟](/zh-cn/virtualization/) 的计算、存储和网络资源，使用按需按量的计费模式。
+基础设施即服务，或者 IaaS ，是一种 [云计算](/zh-cn/cloud-computing/) 服务模型，
+它提供 [物理](/zh-cn/bare-metal-machine/) 或 [虚拟](/zh-cn/virtualization/) 的计算、存储和网络资源，使用按需按量的计费模式。
 云提供商拥有和管理软件和硬件设施，可供消费者在公共、私有或混合云部署和使用。
 
 ## 解决的问题
 
 在搭建传统的本地设施时，组织常常受困于如何保证资源的有效利用。
 数据中心建立时必须考虑潜在的高峰需求，即使这样的需求只占1%的使用时间。
 而在低需求期间，这些计算资源是空闲的。
-
 而且，如果工作负载超过预期需求，处理工作负载的计算资源则会出现短缺。
 这种缺乏可伸缩性的使用方式，将导致成本增加和资源使用率降低。
 

content/zh-cn/infrastructure-as-code.md

@@ -1,5 +1,5 @@
 ---
-title: 基础设施即代码
+title: 基础设施即代码 (IaC)
 status: Completed
 category: 概念
 tags: ["基础设施", "", ""]
@@ -13,13 +13,13 @@ tags: ["基础设施", "", ""]
 ## 解决的问题
 
 云原生方式构建应用程序要求基础设施是一次性的和可复现的。
-它还需要以自动化和可重复的方式按需 [伸缩](/scalability/)，甚至可能无需人工干预。
-手动配置则无法满足 [云原生应用](/cloud_native_apps/) 对响应能力和灵活伸缩的诉求。
+它还需要以自动化和可重复的方式按需 [伸缩](/zh-cn/scalability/)，甚至可能无需人工干预。
+手动配置则无法满足 [云原生应用](/zh-cn/cloud_native_apps/) 对响应能力和灵活伸缩的诉求。
 而且手动基础架构变更不可复现，很容易碰到伸缩瓶颈，并引入错误配置。
 
 ## 如何帮助
 
 通过将服务器、负载均衡器和子网等数据中心资源表示为代码，
-它允许基础架构团队对所有配置拥有单一的数据源，并允许他们在 
-[CI](/continuous-integration/ )/[CD](/continuous-delivery/) 
+它允许基础架构团队对所有配置拥有单一的数据源，并允许他们在
+[CI](/zh-cn/continuous-integration/ )/[CD](/zh-cn/continuous-delivery/)
 通道中管理数据中心，实现版本控制和部署策略。

content/zh-cn/kubernetes.md

@@ -10,7 +10,7 @@ tags: ["基础设施", "", ""]
 Kubernetes，通常缩写为K8s，是一种流行的现代基础设施自动化的开源工具。
 它就像一个数据中心的操作系统，管理在 [分布式系统](/zh-cn/distributed-systems/) 上运行的应用程序（就像你笔记本上的操作系统，管理你的应用程序）。
 
-Kubernetes在 [集群](/zh-cn/cluster/) 的 [节点](/nodes/) 上调度 [容器](/zh-cn/container/)。
+Kubernetes在 [集群](/zh-cn/cluster/) 的 [节点](/zh-cn/nodes/) 上调度 [容器](/zh-cn/container/)。
 它捆绑了几个基础设施结构，有时被称为 "基元"，如应用程序的实例、负载平衡器、持久性存储等，以一种可以被组成应用程序的方式。
 
 Kubernetes 实现了自动化和可扩展性，使用户能够以可重复的方式声明性地部署应用程序。

content/zh-cn/managed-services.md

@@ -0,0 +1,23 @@
+---
+title: 托管服务
+status: Completed
+category: 技术
+tags: ["", "", ""]
+---
+
+## 是什么
+
+托管服务是一种软件产品，其运营和管理由第三方负责。
+例如类似 Amazon RDS 的数据库即服务或类似 Datadog 的外部监控服务。
+
+## 解决的问题
+
+软件的管理比较复杂，尤其是要考虑现代技术栈所包含的各种不同技术。
+而想要将管理做到面面俱到并招募能胜任此职的内部专家，要么成本过于高昂，要么会耗用工程师的宝贵时间。
+你的团队应投入精力构建新功能，而不是处理可以通过外包就能轻松解决的运营任务。
+
+## 如何帮助
+
+托管服务从一开始就处于使用就绪状态，运营开销非常小。
+托管服务具备良好定义的、通常由 [API](/zh-cn/application-programming-interface/) 驱动的边界，
+便于各个组织将超出其核心竞争力的任务有效外包出去。

content/zh-cn/microservices.md

@@ -16,7 +16,7 @@ tags: ["架构", "", ""]
 微服务是对单体应用所带来的挑战的一种回应。一般来说，一个应用程序的不同部分需要分别进行 [伸缩](/zh-cn/scalability/)。
 例如，一个在线商店将有更多的产品视图而不是结账。这意味着你需要更多的产品视图功能的运行，而不是结账。
 在一个单一的应用程序中，这些逻辑位不能被单独部署。如果你不能单独扩展产品功能，你将不得不复制整个应用程序和所有其他你不需要的组件--这是一种低效的资源利用。
-单机式应用程序也使开发人员容易屈服于设计陷阱。因为所有的代码都在一个地方，所以更容易使这些代码 [高耦合](/tightly-coupled-architectures/)，更难执行关注点分离的原则。
+单机式应用程序也使开发人员容易屈服于设计陷阱。因为所有的代码都在一个地方，所以更容易使这些代码 [高耦合](/zh-cn/tightly-coupled-architectures/)，更难执行关注点分离的原则。
 单机通常要求开发人员了解整个代码库，然后才能有成效。
 
 ## 如何帮助

content/zh-cn/mutual-transport-layer-security.md

@@ -0,0 +1,25 @@
+---
+title: 双向传输层安全性协议（mTLS）
+status: Completed
+category: 概念
+tags: ["安全", "", ""]
+---
+
+## 是什么
+
+双向 TLS (mTLS) 是一种用于对两个[服务](/zh-cn/service/)之间发送的消息进行身份验证和加密的技术。 
+双向 TLS (mTLS) 是标准的[传输层安全性协议](/zh-cn/transport-layer-security/)(TLS) ， 
+但不是仅验证一个连接的身份，而是验证双方。
+
+## 解决的问题
+
+[微服务](/zh-cn/microservices/)通过网络进行通信， 
+就像您的 wifi 网络一样，通过该网络传输的通信可能会被黑客入侵。 
+mTLS 确保没有未经授权的一方监听或冒充合法请求。
+
+## 如何帮助
+
+mTLS 确保客户端和服务器之间的双向流量是安全和可信的， 
+为进入网络或应用程序的用户提供了额外的安全层。 
+它还验证不遵循登录过程的客户端设备连接，例如物联网 (IoT) 设备。 
+mTLS 可以防止诸如路径上的攻击、欺骗攻击、凭证填充、暴力攻击等攻击。

content/zh-cn/observability.md

@@ -0,0 +1,27 @@
+---
+title: 可观测性
+status: Completed
+category: 概念
+tags: ["方法论", "应用程序", "基础设施"]
+---
+
+## 是什么
+
+可观测性指的是从所观测的系统采集信号，持续生成并发现可执行的洞察力。
+换言之，可观测性允许用户从某个系统的外部输出中洞察该系统的状态并采取（修正）措施。
+
+## 解决的问题
+
+计算机系统的衡量机制为观测 CPU 时间、内存、磁盘空间等底层信号以及每秒
+API 响应次数、每秒错误率、每秒处理的事务数等高级信号和业务信号。
+
+系统的可观测性对其运营和开发成本有重大影响。
+可观测系统为操作人员提供了有意义的、可执行的数据，使他们能够达成有利的结果
+（即更快的事件响应、更高的开发效率）以及更少的艰辛时刻和更短的停机时间。
+
+## 如何帮助
+
+请注意，更多的信息并不一定能转化为可观测性更好的系统。
+事实上，有时系统生成的大量信息会形成信息噪音，会使得鉴别有价值的健康信号变得更加困难。
+可观测性需要在合适的时间为合适的消费者（一个人或一个软件）提供合适的数据，从而做出合适的决策。
+

content/zh-cn/platform-as-a-service.md

@@ -13,7 +13,7 @@ Heroku、Cloud Foundry、App Engine 是 PaaS 产品的示例。
 ## 解决的问题
 
 要利用好 [微服务](/zh-cn/microservices/) 或 [分布式应用程序](/zh-cn/distributed-apps/) 等云原生模式，
-运维团队和开发人员需要能够免去大量运维工作， 其中包括供应基础设施、处理[服务发现](/service-discovery/) 和
+运维团队和开发人员需要能够免去大量运维工作， 其中包括供应基础设施、处理[服务发现](/zh-cn/service-discovery/) 和
 负载平衡以及[扩展](/zh-cn/scalability/) 应用程序等任务。
 
 ## 如何帮助

content/zh-cn/policy-as-code.md

@@ -0,0 +1,23 @@
+---
+title: 策略即代码 (PaC)
+status: Feedback Appreciated
+category: 概念
+tags: ["", "", ""]
+---
+
+## 是什么
+
+策略即代码是将一些策略的定义存储为一个或多个机器可读和可处理格式文件的做法。
+这取代了在传统模型中，以人类可读的形式记录在单独文档中的策略。
+
+## 解决的问题
+
+构建应用和基础设施通常受到某组织所定义的许多策略的约束，
+例如禁止在源代码中存储 Secret、禁止以超级用户权限运行容器或禁止将某些数据存储在特定地理区域之外的安全策略。
+对于开发人员和审查人员来说，按照策略文档手动检查应用和基础设施既耗时费力又容易出错。
+手动检查策略无法满足云原生应用的响应要求和扩缩要求。
+
+## 如何帮助
+
+通过使用策略即代码，可以自动检查系统属性和操作。
+软件开发的最佳实践也适用于构建策略即代码，例如使用 Git 及相关工作流。