Microservices 使用Lagom的远程持久视图

在经典的微服务体系结构中，在某个消息传递系统上发布了相关的域事件，从而允许系统的其他部分做出反应

现在假设您有三个微服务：客户、订单和推荐。推荐微服务需要来自客户和订单的信息来提供其功能，如所有客户和所有订单的列表，这些信息将通过一些机器学习算法进行分析现在，您需要在推荐微服务上显示客户“加入”订单的状态：

您可以使用Recommandation microservice侦听客户和订单发布的域事件，并构建自己的状态。这会导致逻辑重复，因为在客户和订单中可能已经有了相同的逻辑

对于来自客户和订单的每个相关域消息，您只需访问他们并询问特定客户或订单的状态。这很好，但是如果您有N个服务，而不仅仅是一个需要构建物化视图的服务，那么您将给客户和订单带来很大的负担

您可以让客户和订单自己发布“重量级”事件（而不是域事件），允许任何其他微服务在不处理域事件的情况下构建物化视图。这允许你们两个a）不重复逻辑b）不继续询问相同的信息

---

模式n.3有一些我们无法解决的缺点，如果没有，您如何在Lagom中实现它？

我将尝试解释更多的内容，希望能让您对这个问题有更多的看法，以及如何在Lagom中以可靠的方式实现它

我们必须记住几个概念。最重要的来源是事件来源本身。事件源是指系统中的任何状态都有其事件源

我们要处理的第一个状态是持久性状态。这种状态之所以突出，是因为它与命令和事件处理程序一起定义了模型的一致性边界

但该体系中还有其他州。事实上，我们可以创建我们想要的，因为我们有事件日志。读取模型也是一种状态，也是从事件生成的

您不应该将持久性状态发布到其他系统的原因有很多。第一个问题是避免耦合。您不希望您的数据泄漏到其他服务。这一切都是关于拥有一个反腐败层（ACL）

因此，从这里我们可以说：在将订单和客户发布到推荐服务之前，我将把它转换为OrderView和CustomerView（ACL 101）

现在的问题是你什么时候做？如果在处理命令后尝试在Kafka中发布，则无法保证该状态将被发布。事件日志和卡夫卡主题之间没有XA事务。因此，这些事件有可能持续存在，但出于某种原因，国家并未在卡夫卡中公布

如果希望数据以可靠的方式从服务中传出，并且不在服务之间创建耦合，则可以使用以下选项：

使用代理API并将事件发布到主题。您不应该按原样发布事件，而应该将它们转换为外部API（ACL）的格式。 使用读取端处理器生成它的视图，同样是您希望提供的外部API格式。如果需要，可以将该ViewState发布到主题，以便其他服务可以直接使用它

这就是说，在一个不是真实事件，而是某种派生状态的主题中发布某些内容并没有错。问题是如何保证它有效地发布。从PersistentEntity内部这样做是有风险的，因为您最多只需要一次语义。最可靠的方法是读端进程，它至少提供一次语义

进一步评论内联

侦听来自客户和订单的域事件并重建状态 在推荐服务中。这是个可怕的主意，因为你 将需要复制处理跨不同系统事件的逻辑 有界上下文

这不是一个可怕的想法。这就是如何使您的服务相互独立。使用事件所需实现的逻辑不同。正如你所说，它是一个不同的有界上下文，因此它只得到它需要的东西

由于我上面提到的原因（反腐败层），将状态从一个BC泄漏到另一个BC的问题更大

要实现解耦，您确实需要更多的编码，这并没有错。归根结底，构建微服务的原因是为了避免耦合，并且能够让服务在不相互干扰的情况下发展和扩展。这是要付出代价的，代价就是写更多的代码。您需要评估线程

您可以使用自己的事件，生成OrderView和CustomerView并发布到Kafka，但这与直接在推荐服务上使用事件是一样的

请注意，您还需要在推荐服务中的某个位置存储OrderView和CustomerView。所以你最终把它存储了三次。在原始服务（视图表）、Kafka和推荐服务中

这就是为什么在主题中发布事件是在服务之间传播数据的最佳选择

每次我们收到客户或订单的域事件时，请转到 向他们询问情况。这很可怕，因为如果你有更多 不止一个微服务需要它们的状态，你最终会 对客户和订单产生负载

这的确是一个可怕的想法