当需要大量输入数据时，如何在微服务架构中使用规则引擎？

12

现在的情况

我们正在微服务架构中实现（现在正在维护）在线购物Web应用程序。

要求之一是，企业必须能够对客户添加到购物车中的商品应用规则，以自定义其体验和最终订单。很显然，必须建立业务规则引擎，并且为此我们实现了一个特定的“微服务”（如果仍然可以这样）。

在过去的一年中，此规则引擎变得越来越复杂，需要越来越多的数据（例如购物车的内容以及用户信息，他的角色，他的现有服务，一些账单信息等）才能计算这些规则。

目前，我们的shopping-cart微服务正在从其他微服务收集所有这些数据。即使部分资料已由所使用shopping-cart，大部分时间主要还是用来提供规则引擎。

新要求

现在，需要其他应用程序/微服务来重用规则引擎以实现类似的需求。因此，在当前情况下，他们将必须传输相同类型的数据，调用相同的微服务并构建（几乎）相同的资源才能调用规则引擎。

照原样继续，我们将面临几个问题：

每个人（称为规则引擎）都必须重新实现对数据的获取，即使他们自己不需要数据也是如此。
对规则引擎的请求很复杂；
继续朝这个方向发展，我们将不得不在整个网络上传输许多请求的数据（想想μsA调用μsB调用规则引擎，但是A已经有了规则引擎需要的一些数据）；
shopping-cart 由于所有数据的获取而变得巨大；
我可能会忘记很多……

我们怎样做才能避免这些麻烦？

理想情况下，我们将避免为规则引擎增加更多的复杂性。我们还必须确保它不会成为瓶颈-例如，某些数据的获取速度相当慢（10 s甚至更多），因此我们实施了预提取，shopping-cart以便在调用规则之前数据更有可能存在引擎，并保持可接受的用户体验。

一些想法

让规则引擎获取所需的数据。这将增加它的复杂性，违反了单一责任原则（甚至更多……）；
在规则引擎获取数据之前实施代理μs；
实施规则引擎调用的“数据获取程序”μs，以一次获取其所需的所有数据（复合查询）。

— 迪迪尔
source

让我总结一下（有问题）：您为商店实现了几种微服务。其中之一是购物车。集成到购物车中的是规则引擎（自制软件或某些产品），对吗？当用户将商品添加到购物车时，规则引擎会作为业务逻辑的一部分加入，并以某种方式修改购物车（例如，折扣或捆绑商品），对吗？现在，另一个微服务也希望使用可能基于相似输入数据的规则，对吗？输入数据是由其他微服务提供的，对吗？为什么数据获取如此复杂？

— 安迪

3

避免这些麻烦的最佳选择是摆脱规则引擎。

— whatsisname

@Andy规则引擎是一个单独的微服务。它的API专门针对shopping-cart，但我们可以很容易地使其适应其他微服务的需求（它们仍然与用户，产品和订购有关）。正如我们所看到的，他们将需要相同的输入数据，尤其是因为企业能够选择要应用的谓词。除了购物车内容本身之外，所有其他其他微服务都提供了数据。数据的获取本身并不复杂，但是当您必须调用约10个其他微服务并维护规则引擎期望的结构时，获取数据就变得很复杂。

— Didier L

@whatsisname我也不是一般而言拥有规则引擎的忠实拥护者，但是目前无论如何我们都必须处理它，并且该业务每天都在改变其配置。即使我们摆脱了它，我们仍然需要一些可配置的组件来做同样的事情，需要同样的输入数据……它仍然是规则引擎，只是名字不同，我们仍然会面临同样的问题。

— Didier L

8

让我们退后一步，评估一下我们的出发地，然后写下这个可能是新颖的答案。你有：

大型整体（规则引擎）
大量非模块化数据批量发送
很难在规则引擎之间获取数据
您无法删除规则引擎

好的，这对于微服务来说不是那么好。一个迫在眉睫的问题是你们似乎误解了什么是微服务。

每个人（称为规则引擎）都必须重新实现对数据的获取，即使他们自己不需要数据也是如此。

您需要定义微服务使用的某种API或通信方法，并使其通用。这可能是他们都可以导入的库。它可能正在定义消息协议。它可能正在使用现有工具（寻找微服务消息总线是一个很好的起点）。

服务间通信的问题本身并不是一个“已解决”的问题，但目前还不是一个“自己动手”的问题。许多现有的工具和策略可以使您的生活更轻松。

不管你做什么，选择一个单一的系统，并尝试去适应你的通信API来使用。如果没有某种确定的服务交互方式，那么您将拥有微服务和单片服务的所有缺点，而这两种优点都不存在。

您的大多数问题都源于此。

对规则引擎的请求很复杂；

使它们不那么复杂。

寻找使它们不那么复杂的方法。说真的通用数据模型，将您的单个规则引擎拆分为较小的模型，或类似的东西。使您的规则引擎更好地工作。不要采用“将所有内容塞入查询中并使它们变得复杂”的方法，而是认真查看您的工作及其原因。

为您的数据定义某种协议。我的猜测是，你们没有定义的API计划（如上所述），并已在需要时开始临时编写REST调用。这变得越来越复杂，因为您现在必须在每次更新时维护每个微服务。

更好的是，您还不是第一个实施在线购物工具的公司。去研究其他公司。

怎么办...

在此之后，您至少对一些最大的问题进行了分类。

下一个问题是您的规则引擎问题。我希望这是合理的无状态状态，以便您可以扩展它。如果是这样的话，虽然不是最佳选择，但您至少不会死于荣耀之光或建立疯狂的解决方法。

您希望规则引擎是无状态的。使其仅处理数据。如果您发现它是一个瓶颈，那么请使其成为代理/负载均衡器的后盾。不理想，但仍然可行。

花一些时间考虑是否应该将任何微服务真正放入规则引擎中。如果您要大幅增加系统开销，而仅是为了实现“微服务架构”，则需要花费更多时间进行规划。

另外，您的规则引擎可以分为几部分吗？您可能只是通过制作规则引擎特定的服务而获得收益。

我们还必须确保它不会成为瓶颈-例如某些数据的获取速度很慢（10 s甚至更多）。

假设在解决了上述问题后仍然存在此问题，则需要认真调查为什么会发生这种情况。您面临着一场噩梦，但您没有找出原因（10秒？发送购物门户数据的时间？嘲笑我，但是这有点荒谬），您似乎是在修补症状，而不是着眼于引起症状的原因。第一名。

您已经反复使用了短语“数据获取”。这些数据在数据库中吗？如果没有，请考虑这样做-如果您“手动”花费大量时间来获取数据，那么使用真实数据库似乎是个好主意。

您也许可以设计一个带有数据库的设计，以用于您所获取的数据（取决于它是什么，您已经多次提到过），一些规则引擎和您的客户。

最后一点是您要确保使用正确的API和服务版本。次要发行版不应破坏向后兼容性。如果您发现自己同时发布所有服务以使其正常工作，则说明您没有微服务架构，而是有分布式的整体架构。

最终，微服务不是万能的解决方案。拜托，为了所有神圣的事情，不要仅仅因为它是新事物而这样做。

— 恩德兰
source

感谢您的回答，@ enderland。实际上，微服务架构对我们来说还是一个相对较新的问题，因此是这个问题。这个规则引擎已经有机地发展了起来，可以带我们去这里，所以我们现在需要行车路线来解决它。（幸运的是）它是完全无状态的，因此它将作为输入的数据量。而我们首先要解决的是使其成为可重用的组件。但是如何在不减少可用谓词数量的情况下减少输入数据的数量呢？我猜想我们需要一个能够自己获取数据的API，但是如何正确构建数据呢？

— Didier L

关于性能问题，这些问题来自微服务，它们实际上调用了后端实现的慢速JMS和SOAP服务。他们有自己的数据库，但性能并不是他们的首要目标（只要能够处理负载）。而且有太多的人考虑复制自己的数据并进行维护（尽管有些人这样做了）。因此，我们能做的最好的事情就是缓存和预取。

— Didier L

因此，当您提到“ 少量规则引擎 ”时，我理解您的意思是专门的规则引擎，它们仅使用一种输入类型来评估谓词，对吗？您是否建议他们获取所需的数据，或者应该先获取它们？我们还需要一些组件来协调谓词的组合，对吗？并且要注意不要由于这种编排而增加过多的网络开销。

— Didier L

1

鉴于提供了有关规则引擎及其输入和输出的大量信息，我想您的建议是。2在正确的轨道上。

规则引擎的当前使用者可以将收集所需信息的过程外包给更专用的组件。

示例：您当前正在使用规则引擎来计算需要应用于购物车内容的折扣。以前的购买，地理位置和当前的报价因素都在其中。

新的要求是使用大量相同的信息，根据即将来临的特价和先前的购买，通过电子邮件将优惠发送给以前的客户。以前的购买，当前和即将提供的报价都包含在其中。

为此，我将提供两个单独的服务。他们每个人都将依靠规则引擎服务来完成一些繁重的工作。他们每个人都会收集向规则引擎提出请求所需的必需数据。

规则引擎仅应用规则，使用者不必担心规则引擎需要用于特定上下文的确切数据，而这些新的中间服务只做一件事：组装上下文并将请求传递给规则引擎并返回未修改的响应。

— 索伦·汉森
source

0

汇总决策所需的数据应在规则引擎之外进行。这是因为在可能的情况下，最好将它们设计为无状态服务。数据获取必然涉及异步处理和状态保持。提取是由决策服务之前的代理，调用方还是业务流程完成的，都没关系。

关于实施的实际问题，我将提到IBM Operational Decision Manager 开始记录文档，并且已经支持在Docker容器中使用该产品。我确信其他产品也会提供这种支持，并且它将成为主流。

— 大卫·威廉姆斯
source

0

以我的简单想法，我猜想，一旦客户开始购买和缓存数据，对数据检索服务进行一组异步调用，将有助于预取所有必需的数据。因此，当您必须调用规则服务时，数据已经存在。并在会话期间继续可用于其他服务。

— 阿肖克
source