rootsongjc
/
kubernetes-handbook
mirror of https://github.com/rootsongjc/kubernetes-handbook.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

针对 cloud-native/cloud-native-philosophy.md 的翻译优化 (#417) 

* 翻译优化:
云原生的设计哲学 >> 云原生应用程序 >> 声明式，非反应式

优化方法:
1. 重新组织语言.
2. 对长难句进行拆解.
3. 对部分指代关系进行补全(或冗余).

* 翻译优化:
云原生的设计哲学 >> 云原生应用程序 >> 声明式，非反应式

优化方法:
1. 重新组织语言.
2. 对长难句进行拆解.
3. 对部分指代关系进行补全(或冗余).

* 针对 cloud-native/cloud-native-philosophy.md 的翻译优化

翻译优化:
云原生的设计哲学 >> 云原生应用程序 >> 声明式，非反应式

优化方法:
1. 重新组织语言.
2. 对长难句进行拆解.
3. 对部分指代关系进行补全(或冗余).

* 翻译优化

"停止反应" 有点牵强, 本质上是希望让读者明白在云原生环境里, 需要使用 "声明式" 来代替 "反应式"

* Update cloud-native-philosophy.md

1. 对...做出反应 改为 基于...做出反应.
2. 补全主语: （这些API）是单一用途的函数

* Update cloud-native-philosophy.md

Co-authored-by: Jimmy Song <rootsongjc@gmail.com>
pull/418/head
FANYI ZHAO 2020-08-09 13:32:40 +08:00 committed by GitHub
parent 6de582cf15
commit 3f481daa09
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
1 changed files with 45 additions and 45 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

14
cloud-native/cloud-native-philosophy.md
View File

@ -199,21 +199,21 @@
### 声明式，非反应式 ### 声明式，非反应式
由于云原生应用程序设计为在云环境中运行，因此它们与基础设施和支持应用程序的交互方式与传统应用程序不同。在云原生应用程序中，与任何事物进行通信的方式都是通过网络进行的。很多时候，网络通信都是通过RESTful HTTP调用完成的，但它也可以通过其他接口（如远程过程调用（RPC））来实现。 因为云原生应用程序被设计为在云环境中运行，所以它们与基础设施以及相关依赖应用程序的交互方式不同于传统应用程序。在云原生应用程序中，与任何事物的通信都需要通过网络来进行。很多时候，网络通信是通过 RESTful HTTP 调用完成的，但是也可以通过其他接口实现，比如远程过程调用 (RPC)。
传统的应用程序会通过消息队列，写在共享存储上的文件或触发shell命令的本地脚本来自动执行任务。通信方法对发生的事件作出反应（例如，如果用户单击提交，运行提交脚本）并且通常需要存在于同一物理或虚拟服务器上的信息。 传统的应用程序会通过向消息队列发送消息、在共享存储上写入文件或触发本地 shell 脚本来执行自动化任务。通信方法基于发生的事件作出反应（例如，如果用户单击提交，运行提交脚本）并且通常需要存在于同一物理或虚拟服务器上的信息。
> **Serverless** > **Serverless**
> >
> 无服务器平台是云原生化的，并通过设计对事件做出响应。他们在云中工作得很好的原因是他们通过HTTP API进行通信，是单用途功能，并且在他们所称的功能中声明。该平台还可以通过在云中进行扩展和访问来提供帮助。 > 无服务器平台是云原生化的，并被设计为对事件做出反应。他们在云中工作得很好的原因是他们通过 HTTP API 进行通信，（这些 API）是单一用途的函数，并且在它们的调用中是声明性的。该平台还使它们可伸缩并可从云内访问。
传统应用程序中的反应性通信常常是尝试增强弹性。如果应用程序在磁盘或消息队列中写入文件，然后应用程序死亡，则消息或文件的结果仍可能完成。 传统应用程序中的反应式通信通常是构建弹性的一种尝试。如果应用程序（以反应式的方式）在磁盘上或消息队列中写入了一个文件，然后应用程序死亡，那么该消息或文件的结果仍然可以完成。
这并不是说不应该使用像消息队列这样的技术，而是说它们不能被依赖于动态和不断发生故障的系统中的唯一弹性层。从根本上讲，应用程序之间的通信应该在云原生环境中改变 - 不仅因为还有其他方法来构建通信弹性（请参阅附录A），还因为在云中复制传统通信方法往往需要更多工作。 这里并不是说不应该使用像消息队列这样的技术，而是说在动态且经常出现故障的系统中，不能将它们作为惟一的弹性层来依赖。从根本上说，在云原生环境之中，应用程序之间的通信方法应该有所变化 - 这不仅是因为还存在其他方法来构建通信弹性（请参阅附录 A），而且还因为如果要让传统的通信方法在云中实现复制，我们往往需要做更多工作。
当应用程序可以信任通信的弹性时，他们应该停止反应并开始声明。声明式沟通相信网络将传递消息。它也相信应用程序将返回成功或错误。这并不是说应用程序监视变化并不重要。 Kubernetes的控制器正是这样做到API服务器。但是，一旦发现变更，他们就会声明一个新的状态，并相信API服务器和kubelets会做必要的事情。 当应用程序可以信任通信的弹性时，它们应该放弃反应式并使用声明式。声明式通信信任网络会将消息送达。它也相信应用程序将返回成功或错误。这并不是说让应用程序观察变化不重要。Kubernetes 的控制器对 API 服务器做的就是这个。但是，一旦发现变更，他们就会声明一个新的状态，并相信 API 服务器和 kubelets 会做必要的事情。
声明式通信模型由于多种原因而变得更加健壮。最重要的是，它规范了通信模型，并且它将功能实现从应用程序转移到远程API或服务端点，从而实现某种状态到达期望状态。这有助于简化应用程序，并使它们彼此的行为更具可预测性。 声明式通信模型由于多种原因而变得更加健壮。最重要的是，它规范了通信模型，并且它将（如何从某种状态到达期望状态的）功能实现从应用程序转移到远程 API 或服务端点。这有助于简化应用程序，并使它们彼此的行为更具可预测性。
### 云原生应用程序如何影响基础设施？ ### 云原生应用程序如何影响基础设施？