backup/translations
1
0
Fork 0
mirror of https://github.com/oldratlee/translations.git synced 2026-02-02 17:59:34 +08:00
Code Issues Projects Releases Wiki Activity

remove redundant parenthesis

Browse Source
This commit is contained in:
Jerry Lee
2018-01-25 19:39:10 +08:00
parent 38d223f08a
commit 6ebd8638da
2 changed files with 6 additions and 6 deletions
Download Patch File Download Diff File Expand all files Collapse all files

4
reactive-manifesto/README.md
View File

@@ -11,8 +11,8 @@
**反应式系统具有：**
* **即时响应性**：只要有可能，[系统](glossary.md#系统)就会及时地做出响应。响应能力是可用性和实用性的基石，但是更加重要的是，响应能力意味着可以快速地检测到问题并且行之有效地解决它。即时响应的系统专注于提供快速而一致的响应时间，确立可靠的上界，从而提供一致地服务质量。这种一致的行为反过来简化了错误处理、建立了最终用户的信任、并鼓励他们进行进一步的交互。
* **弹性**：系统在出现[失败](glossary.md#失败)时依然保持即时响应性。这不仅适用于高可用的、任务关键型系统 —— 任何不具备弹性的系统都将会在失败之后丢失即时响应性。弹性是通过[复制](glossary.md#复制)、遏制、[隔离](/#glossary.md#隔离)以及[委派](glossary.md#委派)来实现的。失败被包含在了每个[组件](glossary.md#隔离)内部，和其他组件相互隔离，从而确保了系统的各个部分能够在不危及整个系统的情况下失败和恢复。每个组件的恢复都被委派给了另一个（外部的）组件，并在必要时通过复制来实现了高可用。（因此）组件的客户端（也就）没有了处理组件失败的负担。
* **适应性**：系统在变化的工作负载之下依保持着即时响应性。反应式系统可以通过增加或者减少分配给服务于输入（负载的）资源，来响应输入（负载的）速率的变化。这意味着设计上并没有争用点和中心化的瓶颈，从而可以分片或者复制组件，并在他们之间分发输入（的负载）能力。通过提供相关的实时性能测量信息，反应式系统都支持预测式以及反应式伸缩算法。他们在日常的硬件以及软件平台上实现了成本高效的[适应性](glossary.md#适应性)。
* **弹性**：系统在出现[失败](glossary.md#失败)时依然保持即时响应性。这不仅适用于高可用的、任务关键型系统 —— 任何不具备弹性的系统都将会在失败之后丢失即时响应性。弹性是通过[复制](glossary.md#复制)、遏制、[隔离](/#glossary.md#隔离)以及[委派](glossary.md#委派)来实现的。失败被包含在了每个[组件](glossary.md#隔离)内部，和其他组件相互隔离，从而确保了系统的各个部分能够在不危及整个系统的情况下失败和恢复。每个组件的恢复都被委派给了另一个外部的组件，并在必要时通过复制来实现了高可用。因此组件的客户端也就没有了处理组件失败的负担。
* **适应性**：系统在变化的工作负载之下依保持着即时响应性。反应式系统可以通过增加或者减少分配给服务于输入负载的资源，来响应输入负载的速率的变化。这意味着设计上并没有争用点和中心化的瓶颈，从而可以分片或者复制组件，并在他们之间分发输入的负载能力。通过提供相关的实时性能测量信息，反应式系统都支持预测式以及反应式伸缩算法。他们在日常的硬件以及软件平台上实现了成本高效的[适应性](glossary.md#适应性)。
* **消息驱动**：反应式系统依赖[异步的](glossary.md#异步的)[消息传递](glossary.md#消息驱动)来确立组件之间的边界，以确保松散耦合、隔离以及[位置透明性](glossary.md#位置透明性)。这一边界还提供了将[失败](glossary.md#失败)作为消息委派出去的手段。使用显式的消息传递，通过在系统中形成并监视消息流队列，并在必要的时候应用[回压](glossary.md#回压)，从而实现了负载管理、适应性以及流控制。使用位置透明性的消息传递作为通信的手段，使得跨集群或者在单个主机中使用相同的构造和语义管理失败成为了可能。[非阻塞的](glossary.md#非阻塞的)通信使得接收者可以只在活动的时候消耗[资源](glossary.md#资源)，从而带来更少的系统开销。
大型系统是由较小的系统所构成的，因此依赖于他们的构成部分的反应式特性。这意味着，反应式系统应用了一些设计原则，因此这些属性也适用于所有级别的伸缩，使得他们可以组合。世界上最大型的系统都依赖于基于这些属性的架构，并每日服务于数十亿的人们的需求。现在是时候从一开始就有意识地应用这些设计原则，而不是每次都重新发现他们了。

8
reactive-manifesto/glossary.md
View File

@@ -24,7 +24,7 @@
## 回压
当某个[组件](#组件)正竭力地（`struggling`）跟上（负载或者输入请求的速率）时，整个[系统](#系统)就需要以合理地方式作出反应。对于该正在遭受压力的组件来说，进行灾难性地失败，或者不受控地丢弃消息，都是不能接受的。因为他既不能成功地应对，又不能（直接地）失败，所以他需要向其上游组件传达其正在遭受压力的事实，并让他们（该组件的上游组件）降低负载。这种回压（`back-pressure`）是一种重要的反馈机制，使得系统得以优雅地响应负载，而不是在负载下崩溃。回压可以一路级联到（系统的）用户，在这时响应能力可能会打折，但是这种机制将确保系统在负载之下的弹性，并将提供可能允许系统本身通过利用其他资源来帮助分担负载的信息，参见[适应性](#适应性)。
当某个[组件](#组件)正竭力地（`struggling`）跟上（负载或者输入请求的速率）时，整个[系统](#系统)就需要以合理地方式作出反应。对于该正在遭受压力的组件来说，进行灾难性地失败，或者不受控地丢弃消息，都是不能接受的。因为他既不能成功地应对，又不能直接地失败，所以他需要向其上游组件传达其正在遭受压力的事实，并让他们该组件的上游组件降低负载。这种回压（`back-pressure`）是一种重要的反馈机制，使得系统得以优雅地响应负载，而不是在负载下崩溃。回压可以一路级联到系统的用户，在这时响应能力可能会打折，但是这种机制将确保系统在负载之下的弹性，并将提供可能允许系统本身通过利用其他资源来帮助分担负载的信息，参见[适应性](#适应性)。
## 批量处理
@@ -36,7 +36,7 @@
## 组件
我们所描述的是一个模块化的软件体系架构，其（实际上）是一个非常古老的概念，参见[Parnas (1972)](https://www.cs.umd.edu/class/spring2003/cmsc838p/Design/criteria.pdf)。我们正使用『组件（`component`）』这个术语，因为它和『区划（`compartment`）』联系紧密，其意味着每个组件都是自包含的、封闭的并和其他的组件相[隔离](#隔离)。这个概念首先适用于系统的运行时特征，但是它通常也会反映在源代码的模块化结构中。虽然不同的组件可能会使用相同的软件模块来执行通用的任务，但是定义了每个组件的顶层行为的程序代码则是组件本身的一个模块。组件边界通常与问题域中的[`Bounded Context`](http://martinfowler.com/bliki/BoundedContext.html)密切相关。这意味着系统设计倾向于反应问题域，并因此在保持隔离的同时更加容易演化。消息[协议](#协议)为多个[`Bounded Context`](http://martinfowler.com/bliki/BoundedContext.html)(组件)之间提供了自然的映射和通讯层。
我们所描述的是一个模块化的软件体系架构，其实是一个非常古老的概念，参见[Parnas (1972)](https://www.cs.umd.edu/class/spring2003/cmsc838p/Design/criteria.pdf)。我们正使用『组件（`component`）』这个术语，因为它和『区划（`compartment`）』联系紧密，其意味着每个组件都是自包含的、封闭的并和其他的组件相[隔离](#隔离)。这个概念首先适用于系统的运行时特征，但是它通常也会反映在源代码的模块化结构中。虽然不同的组件可能会使用相同的软件模块来执行通用的任务，但是定义了每个组件的顶层行为的程序代码则是组件本身的一个模块。组件边界通常与问题域中的[`Bounded Context`](http://martinfowler.com/bliki/BoundedContext.html)密切相关。这意味着系统设计倾向于反应问题域，并因此在保持隔离的同时更加容易演化。消息[协议](#协议)为多个[`Bounded Context`](http://martinfowler.com/bliki/BoundedContext.html)(组件)之间提供了自然的映射和通讯层。
## 委派
@@ -50,7 +50,7 @@
<a name="失败"></a>
## 失败（与『错误』对照）
失败是服务中的意外事件，其阻止了服务继续正常地运行。失败通常会阻止对于当前的、并可能所有接下来的客户端请求的响应。和错误相对照，错误是意料之中的，并且针对各种情况进行了处理 —— 例如，在输入验证的过程中所发现的错误，将会作为该消息的正常处理过程的一部分返回给客户端。而失败是意料之外的，并且在系统能够恢复至（和之前）相同的服务水平之前，需要进行干预。这并不意味着失败总是致命的（`fatal`），虽然在失败发生之后，系统的某些服务能力可能会被降低。错误是正常操作流程的预期部分，在错误发生之后，系统将会立即地对其进行处理，并将继续以相同的服务能力继续运行。
失败是服务中的意外事件，其阻止了服务继续正常地运行。失败通常会阻止对于当前的、并可能所有接下来的客户端请求的响应。和错误相对照，错误是意料之中的，并且针对各种情况进行了处理 —— 例如，在输入验证的过程中所发现的错误，将会作为该消息的正常处理过程的一部分返回给客户端。而失败是意料之外的，并且在系统能够恢复至和之前相同的服务水平之前，需要进行干预。这并不意味着失败总是致命的（`fatal`），虽然在失败发生之后，系统的某些服务能力可能会被降低。错误是正常操作流程的预期部分，在错误发生之后，系统将会立即地对其进行处理，并将继续以相同的服务能力继续运行。
失败的例子有：硬件故障、由于致命的资源耗尽而引起的进程意外终止以及导致系统内部状态损坏的程序缺陷。
@@ -68,7 +68,7 @@
## 位置透明性
[适应性](#适应性)系统需要自适应，并不间断地对需求的变化做出反应。他们需要优雅而高效地扩大或者缩减（部署）规模。极大地简化这个问题的一个关键洞察是认识到我们一直都在处理分布式计算。无论我们是在一台单独的（具有多个独立的通过快速通道互联（`QPI`）进行通信的`CPU`的）节点之上，还是在一个（具有多台通过网络进行通信的独立节点的）机器集群之上运行我们的系统，都是如此。拥抱这一事实意味着，在多核心之上进行垂直缩放和在集群之上进行水平伸缩并没有什么概念上的差异。
[适应性](#适应性)系统需要自适应，并不间断地对需求的变化做出反应。他们需要优雅而高效地扩大或者缩减部署规模。极大地简化这个问题的一个关键洞察是认识到我们一直都在处理分布式计算。无论我们是在一台单独的（具有多个独立的通过快速通道互联（`QPI`）进行通信的`CPU`的）节点之上，还是在一个（具有多台通过网络进行通信的独立节点的）机器集群之上运行我们的系统，都是如此。拥抱这一事实意味着，在多核心之上进行垂直缩放和在集群之上进行水平伸缩并没有什么概念上的差异。
如果我们所有的[组件](#组件)都支持移动性，而本地通信只是一项优化。那么我们根本不需要预先定义一个静态的系统拓扑和部署结构。可以将这个决策留给运维人员或者运行时，他们可以根据系统的使用情况来对其进行调整和优化。