Re-proofread content

5-event-driven-data-management-for-microservices.md

@@ -6,20 +6,20 @@
 ## 5.1、微服务和分布式数据管理问题
 单体应用程序通常具有一个单一的关系型数据库。使用关系型数据库的一个主要优点是您的应用程序可以使用 [ACID 事务](https://en.wikipedia.org/wiki/ACID)，这些事务提供了以下重要保障：
 
-- **原子性（Atomicity）** — 所作出的改变是原子操作，不可分割
+- **原子性（Atomicity）** — 所作出的更改是原子操作，不可分割
 - **一致性（Consistency）** — 数据库的状态始终保持一致
 - **隔离性（Isolation）** — 即使事务并发执行，但他们看起来更像是串行执行
 - **永久性（Durable）** — 一旦事务提交，它将不可撤销
 
-因此，您的应用程序可以很容易地开始事务、更改（插入、更新和删除）多个行，并提交事务。
+因此，您的应用程序可以很容易地开始事务、更改（插入、更新和删除）多行记录，并提交事务。
 
-使用关系数据库的另一大好处是它提供了 SQL，这是一种丰富、声明式和标准化的查询语言。您可以轻松地编写一个查询来组合来自多个表的数据，之后，RDBMS 查询计划程序将确定执行查询的最佳方式。您不必担心如何访问数据库等底层细节。因为您所有的应用程序数据都存放在同个数据库中，因此很容易查询。
+使用关系型数据库的另一大好处是它提供了 SQL，这是一种丰富、声明式和标准化的查询语言。您可以轻松地编写一个查询组合来自多个表的数据，之后，RDBMS 查询计划程序将确定执行查询的最佳方式。您不必担心如何访问数据库等底层细节。因为您所有的应用程序数据都存放在同个数据库中，因此很容易查询。
 
-很不幸的是，当我们转向微服务架构时，数据访问将变得非常复杂。这是因为每个微服务所拥有的数据[对当前微服务来说是私有的](http://microservices.io/patterns/data/database-per-service.html)，只能通过其提供的 API 进行访问。封装数据可确保微服务松耦合，独立演进。如果多个服务访问相同的数据，模式（schema）更新需要对所有服务进行耗时、协调的更新。
+很不幸的是，当我们转向微服务架构时，数据访问将变得非常复杂。因为每个微服务所拥有的数据[对当前微服务来说是私有的](http://microservices.io/patterns/data/database-per-service.html)，只能通过其提供的 API 进行访问。封装数据可确保微服务松耦合、独立演进。如果多个服务访问相同的数据，模式（schema）更新需要对所有服务进行耗时、协调的更新。
 
 更糟糕的是，不同的微服务经常使用不同类型的数据库。现代应用程序存储和处理着各种数据，而关系型数据库并不总是最佳选择。在某些场景，特定的 NoSQL 数据库可能具有更方便的数据模型，提供了更好的性能和可扩展性。例如，存储和查询文本的服务使用文本搜索引擎（如 Elasticsearch）是合理的。类似地，存储社交图数据的服务应该可以使用图数据库，例如 Neo4j。因此，基于微服务的应用程序通常混合使用 SQL 和 NoSQL 数据库，即所谓的[混合持久化](http://martinfowler.com/bliki/PolyglotPersistence.html)（polyglot persistence）方式。
 
-一个分区的数据存储混合持久化架构具有许多优点，包括了松耦合的服务以及更好的性能与可扩展性。然而，它也引入了一些分布式数据管理方面的挑战。
+分区的数据存储混合持久化架构具有许多优点，包括了松耦合的服务以及更好的性能与可扩展性。然而，它也引入了一些分布式数据管理方面的挑战。
 
 第一个挑战是如何实现维护多个服务之间的业务事务一致性。要了解此问题，让我们先来看一个在线 B2B 商店的示例。Customer Service （顾客服务）维护客户相关的信息，包括信用额度。Order Service （订单）负责管理订单，并且必须验证新订单，不得超过客户的信用额度。在此应用程序的单体版本中，Order Service 可以简单地使用 ACID 交易来检查可用信用额度并创建订单。
 
@@ -62,8 +62,7 @@ Service 和 Order Service 发布的事件更新 Customer Order View （客户订
 
 ![图 5-5 Customer Order View 被两个服务访问](resources/5-5.png)
 
-当 Customer Order View Updater Service 接收到 Customer 或 Order 事件时，它会更新 Customer Order View 数据存储。您可以使用如 MongoDB 之类的文档数据库实现 Customer Order
-View，并为每个 Customer 存储一个文档。Customer Order View Query Service （客户订单视图查询服务）通过查询 Customer Order View 数据存储来处理获取一位客户和最近的订单的请求。
+当 Customer Order View Updater Service 接收到 Customer 或 Order 事件时，它会更新 Customer Order View 数据存储。您可以使用如 MongoDB 之类的文档数据库实现 Customer Order View，并为每个 Customer 存储一个文档。Customer Order View Query Service（客户订单视图查询服务）通过查询 Customer Order View 数据存储来处理获取一位客户和最近的订单的请求。
 
 事件驱动的架构有几个优点与缺点。它能够实现跨越多服务并提供最终一致性事务。另一个好处是它还使得应用程序能够维护[物化视图](https://en.wikipedia.org/wiki/Materialized_view)。
 
@@ -94,7 +93,7 @@ Order Service 将一行记录插入到 ORDER 表中，并将一个 Order Created
 
 ![图 5-7、Message Broker 可以公断数据事务](resources/5-7.png)
 
-使用这种方法的一个示例是 LinkedIn Databus 开源项目。Databus 挖掘 Oracle 事务日志并发布与更改相对应的事件。LinkedIn 使用 Databus 保持与记录系统一致的各种派生数据存储。
+一个使用此方法的示例是 LinkedIn Databus 开源项目。Databus 挖掘 Oracle 事务日志并发布与更改相对应的事件。LinkedIn 使用 Databus 保持与记录系统一致的各种派生数据存储。
 
 另一个例子是 AWS DynamoDB 中的流机制，它是一个托管的 NoSQL 数据库。DynamoDB 流包含了在过去 24 小时内对 DynamoDB 表中的项进行的更改（创建、更新和删除操作），其按时间顺序排列。应用程序可以从流中读取这些更改，比如，将其作为事件发布。
 
@@ -122,7 +121,7 @@ Order Service 将一行记录插入到 ORDER 表中，并将一个 Order Created
 <a id="summary"></a>
 
 ## 5.7、总结
-在微服务架构中，每个微服务都有自己私有的数据存储。不同的微服务可能会使用不同的 SQL 或者 NoSQL 数据库。虽然这种数据库架构具有明显的优势，但它创造了一些分布式数据管理挑战。第一个挑战是如何实现维护多个服务间的业务事务一致性。第二个挑战是如何实现从多个服务中检索数据。
+在微服务架构中，每个微服务都有私有的数据存储。不同的微服务可能会使用不同的 SQL 或者 NoSQL 数据库。虽然这种数据库架构具有明显的优势，但它创造了一些分布式数据管理挑战。第一个挑战是如何实现维护多个服务间的业务事务一致性。第二个挑战是如何实现从多个服务中检索数据。
 
 大部分应用使用的解决方案是事件驱动架构。实现事件驱动架构的一个挑战是如何以原子的方式更新状态以及如何发布事件。有几种方法可以实现这点，包括了将数据库作为消息队列、事务日志挖掘和事件溯源。
 
@@ -132,16 +131,16 @@ Order Service 将一行记录插入到 ORDER 表中，并将一个 Order Created
 
 by Floyd Smith
 
-基于微服务的存储方法涉及大数量和各种数据存储，访问和更新数据将变得更加复杂，DevOps 在维护数据一致性方面面临着更大的挑战。NGINX 为这种数据管理提供了重要支持，主要有三个方面：
+基于微服务的存储方式涉及大数量和各种数据存储，访问和更新数据将变得更加复杂，DevOps 在维护数据一致性方面面临着更大的挑战。NGINX 为这种数据管理提供了重要支持，主要有三个方面：
 
 1. **数据缓存与微缓存（microcaching）**
 
     使用 NGINX 缓存静态文件和微缓存应用程序生成的内容可减轻应用程序的负载、提高性能并减少问题的发生。
 2. **数据存储的灵活性与可扩展性**
 
-    一旦将 NGINX 作为反向代理服务器，您的应用程序在创建、调整大小、运行和调整数据存储服务器的大小时可获得很大的灵活性，以满足不断变化的需求 - 每个服务都拥有自己的数据存储是很重要的。
+    一旦将 NGINX 作为反向代理服务器，您的应用程序在创建、调整大小、运行和调整数据存储服务器的大小时可获得很大的灵活性，以满足不断变化的需求 — 每个服务都拥有自己的数据存储是很重要的。
 3. **服务监控与管理，包括数据服务**
 
     随着数据服务器数量的增加，支持复杂操作和具有监控和管理工具显得非常重要。[NGINX Plus](https://www.nginx.com/products/) 内置了这些工具和应用程序性能管理[合作伙伴](https://www.nginx.com/partners/)的接口，如 Data Dog、Dynatrace 和 New Relic。
 
-微服务相关的数据管理示例可在 NGINX [微服务参考架构](https://www.nginx.com/blog/introducing-the-nginx-microservices-reference-architecture/)的三大模型中找到，其为您设计决策和实施提供了起点。
+微服务相关的数据管理示例可在 NGINX [微服务参考架构](https://www.nginx.com/blog/introducing-the-nginx-microservices-reference-architecture/)的三大模型中找到，其为您设计决策和实施提供了起点。