update content

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

@@ -11,7 +11,7 @@
 
 因此，您的应用程序可以很容易地开始事务、更改（插入、更新和删除）多个行，并提交事务。
 
-使用关系数据库的另一大好处是它提供了 SQL，这是一种丰富的、声明性的和标准化的查询语言。您可以轻松地编写一个查询来组合来自多个表的数据，之后 RDBMS 查询计划程序确定执行查询的最佳方式。您不必担心如何访问数据库等底层细节。因为你所有的应用程序数据都存放在同个数据库中，所以很容易查询。
+使用关系数据库的另一大好处是它提供了 SQL，这是一种丰富的、声明性的和标准化的查询语言。您可以轻松地编写一个查询来组合来自多个表的数据，之后 RDBMS 查询计划程序确定执行查询的最佳方式。您不必担心如何访问数据库等底层细节。因为您所有的应用程序数据都存放在同个数据库中，所以很容易查询。
 
 很不幸的是，当我们转向微服务架构时，数据访问将变得非常复杂。这是因为每个微服务所拥有的数据[对当前微服务来说是私有的](http://microservices.io/patterns/data/database-per-service.html)，只能通过其提供的 API 进行访问。封装数据可确保微服务松散耦合，独立演化。如果多个服务访问相同的数据，模式（schema）更新需要对所有服务进行耗时、协调的更新。
 
@@ -91,4 +91,37 @@ Order Service 将一行记录插入到 ORDER 表中，并将一个 Order Created
 事务日志挖掘有各种好处与坏处。一个好处是它能保证被发布的事件每次更新都不依赖于 2PC。事务日志挖掘还可以通过将事件发布与应用程序的业务逻辑分离来简化应用程序。一个主要的缺点是事务日志的格式对于每个数据库来说都是专有的，您甚至可以在数据库版本之间进行更改。而且，从事务日志中记录的低级别更新可能难以对高级业务事件进行逆向工程。
 
 事务日志挖掘消除了应用程序在做一件事时对 2PC 的依赖：更新数据库。现在我们来看看另一种可以消除更新并仅依赖于事件的不同方式。
-**待续……**
+
+## 5.6、使用事件溯源
+[事件溯源](https://github.com/cer/event-sourcing-examples/wiki/WhyEventSourcing)通过使用完全不同的、不间断的方式来持久化业务实体，实现无 2PC 原子性。应用程序不是存储实体的当前状态，而是存储一系列状态改变事件。该应用程序通过回放事件来重建实体的当前状态。无论业务实体的状态何时发生变化，其都会将新事件追加到事件列表中。由于保存事件是一个单一的操作，因此具有原子性。
+
+要了解事件溯源的工作原理，以 Order （订单）实体为例。在传统方式中，每个订单都与 ORDER 表中的某行记录相映射，也可以映射到例如 ORDER_LINE_ITEM 表中的记录。
+
+但当使用事件溯源时，Order Service 将以状态更改事件的形式存储 Order：Created（创建）、Approved（批准）、Shipped（发货）、Cancelled（取消）。每个事件包含足够的数据来重建 Order 的状态。
+
+![图 5-8、事件有完整的数据](resources/5-8.png)
+
+事件持久化在一个事件存储中，事件存储是一个事件数据库。该存储有一个用于添加和检索实体事件的 API。事件存储还与我们之前描述的架构中的 Message Broker 类似。它提供了一个 API，使得服务能够订阅事件。事件存储向所有感兴趣的订阅者派发所有事件。可以说事件存储是事件驱动微服务架构的支柱。
+
+事件溯源有几个好处。它解决了实现事件驱动架构的关键问题之一，可以在状态发生变化时可靠地发布事件。因此，它解决了微服务架构中的数据一致性问题。此外，由于它持久化的是事件，而不是领域对象，所以它主要避免了[对象关系阻抗失配问题](https://en.wikipedia.org/wiki/Object-relational_impedance_mismatch)。事件溯源还提供了对业务实体所做更改的 100％ 可靠的审计日志，可以实现在任何时间点对实体进行时间查询以确定状态。事件溯源的另一个主要好处是您的业务逻辑包括松散耦合的交换事件业务实体，这使得从单体应用程序迁移到微服务架构将变得更加容易。
+
+事件溯源同样有缺点。这是一种不同而陌生的编程风格，因此存在学习曲线。事件存储仅支持通过主键查找业务实体。您必须使用[命令查询责任分离](https://github.com/cer/event-sourcing-examples/wiki)（CQRS）来实现查询。因此，应用程序必须处理最终一致的数据。
+
+## 5.7、总结
+在微服务架构中，每个微服务都有自己私有的数据存储。不同的微服务可能会使用不同的 SQL 或者 NoSQL 数据库。虽然这种数据库架构具有明显的优势，但它创造了一些分布式数据管理挑战。第一个挑战是如何实现维护多个服务间一致性的业务事务。第二个挑战是如何实现从多个服务中检索数据。
+
+大部分应用使用的解决方案是事件驱动架构。实现事件驱动架构的一个挑战是如何以原子的方式更新状态以及如何发布事件。有几种方法可以实现这点，包括了将数据库作为消息队列、事务日志挖掘和事件溯源。
+
+## 微服务实战：NGINX 与存储优化
+
+by Floyd Smith
+
+基于微服务的存储方法涉及大数量和各种数据存储，如何访问和更新数据将变得更加复杂，DevOps 在维护数据一致性方面面临着更大的挑战。NGINX 为这种数据管理提供了重要支持，主要有三个方面：
+
+1. **数据缓存与微缓存** - 使用 NGINX 缓存静态文件和微缓存应用程序生成的内容可减轻应用程序的负载、提高性能并减少问题的发生。
+2. **数据存储的灵活性与可扩展性** - 一旦将 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/)的三大模型中找到，其为您设计决策和实施提供了起点。
+
+**待全文校对……**

README.md

@@ -62,9 +62,9 @@
 - [5.3、实现原子性](5-event-driven-data-management-for-microservices.md#53实现原子性)
 - [5.4、使用本地事务发布事件](5-event-driven-data-management-for-microservices.md#54使用本地事务发布事件)
 - [5.5、挖掘数据库事务日志](5-event-driven-data-management-for-microservices.md#55挖掘数据库事务日志)
-- 5.6、使用事件溯源
-- 5.7、总结
-- 微服务实战：NGINX 与存储优化
+- [5.6、使用事件溯源](5-event-driven-data-management-for-microservices.md#56使用事件溯源)
+- [5.7、总结](5-event-driven-data-management-for-microservices.md#57总结)
+- [微服务实战：NGINX 与存储优化](5-event-driven-data-management-for-microservices.md#微服务实战nginx-与存储优化)
 
 ### 6、选择微服务部署策略
 - 6.1、动机