微服务中的上下文分离

Question

我在一家小公司工作，我们即将深入研究微型服务领域。不出所料，我们遇到了一些困难。

让我们集中讨论一个小范围的上下文:工作顺序。

这个有限的上下文由一个技术员、一个团队和实际的工作顺序组成。团队由一组技术人员和一名团队经理组成，他们也是一名技术员。

软件的一个方面:技术人员应该能够看到发给他们的所有工作命令，如果他们碰巧是团队的经理，他们应该能够看到发给该团队任何成员的所有工作命令。

我是否应该创建一个或两个服务:一个用于管理团队和技术人员，另一个用于实际管理工作订单。第二种方法的问题是，控制应该检索哪些订单的逻辑的一部分必须放在API网关/ BFF中。

由于工作订单不了解团队(我认为这实际上是正确的设计)，API网关必须检索技术员是经理的团队，以便检索这些团队所有成员的所有工作订单。

我在这里担心的是，似乎有一些业务逻辑泄漏到了API网关中，我不确定这是否正常。我也害怕创建贫血的微服务。另一方面，这个有限制的上下文可能在不同的软件上使用，这可能不使用团队的概念。

我还考虑过创建第三个服务来协调这项工作，但到目前为止，我还没有找到任何理由来支持这个想法。

因此，总结一下:我应该创建一个、两个或三个服务吗？我注定要创造两个，但似乎还不能决定。

Answer 1

我将与一个服务与精心设计的模块，因此它可以很容易地分裂成多个服务在未来。

此外，也不要将任何逻辑放入API网关，这将使您的系统混乱，并使未来的维护/资源平衡/更新变得更加困难。API网关应该只关心发送给什么服务的消息，而不应该关心那些服务的内部逻辑。

建立对服务的监控，注意开发/生产中的问题。如果您看到将服务拆分为多个可以产生比成本更多的好处，那么就去做吧。

我会寻找平衡/性能问题(例如工作订单是瓶颈和减缓整个系统)和开发问题--很多人在服务上工作，分成团队，只负责系统的一部分，并且他们之间有很多冲突。

一个一般性的注意事项--微服务将给您的系统增加大量的复杂性和成本。他们可以得到回报，但没有微服务的话，很多系统都能做得很好。到目前为止，我所见过的采用微服务的最佳方法是构建一个服务/ monolith，并在需要时进行拆分。并且始终要注意模块化服务/ monolith，这样您就可以轻松地拆分(或合并)。

Answer 2

服务是关于数据所有权和业务逻辑的，而不是关于实体的，您不想把不属于一起的相同的服务数据和逻辑放在一起。因此，不同的服务拥有与同一实体相关的不同数据。例如，服务将拥有技术人员的姓名和生日，而另一个服务将拥有每个技术员所属的团队。

在我看来，拥有团队结构逻辑的服务不应该是管理工作订单的服务，因为工作订单业务逻辑应该独立于团队。从你说的，工作订单是直接分配给技术人员，而不管他们的团队。

因此，在这些条件下，一方面，您有一个服务，允许您查询给定TechnicianId的工作订单或TechnicianIds列表。从哪里得到这些TechnicianIds并不是这个服务的问题。

另一方面，如果调用的TechnicianId是管理器，则有一个给出TechnicianIds的服务可以告诉您它所属的团队以及该团队的TechnicianIds列表。

现在您只需要将这些事情放在一起：-如果您是团队经理(服务知道)-调用第一个服务以获得团队TechnicianIds (服务知道)-调用传递TecnicianIds列表的第二个服务(如果您不是经理，则只调用一个服务)。

如何将这两个请求放在一起是一个技术问题，可以通过多种方式(直接从API网关上的UI )来解决，而且，由于这是一个技术问题，您没有泄露业务逻辑。最重要的是，这两个服务并不相互了解。它们是自主的和解耦的。

Answer 3

微服务的选择已经告诉您，这里需要多个服务。单一的服务可能是一个不错的选择，但它不是微服务。

API网关了解所有不同的服务。但它不应该知道任何细节。这就要求加强服务之间的沟通。但是API网关不知道这一点。它知道客户所知道的部分，以及如何将其路由到服务。它只知道这些。

你可能需要三个服务。

技术人员通过技术员服务要求他们的工作订单清单。技术员服务知道工作订单服务，但不知道它是如何工作的。它告诉工作订单服务是哪个技术人员提出的请求。

团队服务人员知道技术人员的存在，并且知道一些技术人员是经理。(或者您可以将它们分开，这在这里并不重要)并且它知道工作订单是存在的，但不知道它们的任何内容。因此，您可以在这里添加一个服务功能，将团队成员置于经理之下，然后，对于每个团队成员，它会与技术员服务联系，并请求该技术员的工作订单。然后技术员服务就可以去拿工作订单了。

网络流量比单块服务多得多，但这就是实现解耦的方法。如果您改变了团队的概念，以便您有子团队，或者在具有不同功能的团队中有不同的角色，那么您只需要更改团队服务。

如果您担心贫血的服务或模型或其他什么的，请列出这些关系，并在提出请求时从头到尾详细说明发生了什么。贫血的步骤将显示为额外无用的步骤，在中间，输入和输出只是通过，没有聚合，过滤，或副作用。