fix img

专栏/领域驱动设计实践（完）/081 发布者—订阅者模式.md.html

@@ -605,9 +605,9 @@ public class PaymentFailed extends ApplicationEvent {
 <p>若要追求微服务架构的一致性，保证微服务自身的自治性，可考虑在架构层面采用纯粹的事件驱动架构（Event-Driven Architecture，EDA）。遵循事件驱动架构，微服务之间的协作皆采用异步的事件通信模式。即使协作方式为查询操作，也可使用事件流在服务本地缓存数据集，从而保证在执行查询操作时仅需要执行本地查询即可。要支持本地查询，需要在每次发布事件时，对应的订阅者负责获取自己感兴趣的数据，并将其缓存到本地服务的存储库中。例如，下订单场景需要订单服务调用库存查询服务以验证商品是否满足库存条件。若要避免跨服务之间的同步查询操作，就需要订单服务事先订阅库存事件流，并将该库存事件流保存在订单服务的本地数据库中。库存服务的每次变更都会发布事件，订单服务会订阅该事件，然后将其同步到库存事件流，以保证订单服务缓存的库存事件流是最新的。</p>
 <p>既然限界上下文的协作方式发生了变化，意味着应用服务之间的调用方式也将随之改变。</p>
 <p>在买家下订单的业务场景中，考虑订单上下文与支付上下文之间的协作关系。如果采用<strong>开放主机模式</strong>，则订单上下文将作为下游发起对支付服务的调用。支付成功后，订单状态被修改为“已支付”，按照流程就需要发送邮件通知买家订单已创建成功，同时通知卖家发货。这时，订单上下文会作为下游发起对通知服务的调用。显然，在这个业务场景中，订单上下文成为了整个协作过程的“枢纽站”：</p>
-<p><img src="assets/f26b0090-f87d-11e9-85a1-8d79b502b71a" alt="70835542.png" /></p>
+<p><img src="assets/f26b0090-f87d-11e9-85a1-8d79b502b71a" alt="png" /></p>
 <p><strong>发布者—订阅者</strong>模式就完全不同了。限界上下文成为了真正意义上的自治单元，它根本不用理会其他限界上下文。它像一头敏捷的猎豹一般游走在自己的领土疆域内，凝神静听，伺机而动，一旦自己关心的事件发布，就迅猛地将事件“叼”走，然后利用自己的业务逻辑去“消化”它，并在满足业务条件的时候，发布自己的事件“感言”，至于会是谁对自己发布的事件感兴趣，就不在它的考虑范围内了。显然，采用事件风格设计的限界上下文都是各扫门前雪，彼此具有平等的地位：</p>
-<p><img src="assets/fcdb4620-f87d-11e9-96e2-434f7b8dff8e" alt="79256322.png" /></p>
+<p><img src="assets/fcdb4620-f87d-11e9-96e2-434f7b8dff8e" alt="png" /></p>
 <p>订单上下文既订阅了支付上下文发布的 PaymentCompleted 事件，又会在更新订单状态之后，发布 OrderPaid 事件。假定我们选择 Kafka 作为消息中间件，就可以在订单上下文定义一个事件订阅者，侦听指定主题的事件消息。该事件订阅器是当前限界上下文的北向网关：</p>
 <pre><code class="language-java">public class PaymentEventSubscriber {
     private ApplicationEventHandler eventHandler;