您制定多个明确定义的服务的想法是明智的,这确实是处理此问题的最佳方法。然而,纯微服务方法无论看起来多么时髦,往往都会证明过度杀伤。这就是为什么我会重新设计现有的API/服务,并遵循坚实和可靠的SOA设计原则。可以在
serviceorientation.com和
soapatterns.org上找到好的资源。在我的职业生涯中,我一直将它们用作参考。
考虑您需要哪些类型的服务
(图片来源于serviceorientation.com)
实体服务通常是您的客户端、支付服务等,即以您领域中的实体为中心的服务。它们应该与业务无关,并且能够在所有情况下重复使用。如果满足其需求,有时客户可以直接调用它们。任务服务可能会调用它们。
实用程序服务包含您可能会在其他服务中重复使用的逻辑,但通常不会由客户直接调用。相反,它们将由任务和实体服务调用。例如,转换服务可能是一个例子。
任务服务将实体和实用程序服务组合并重复使用,形成有意义的任务。它们通常不那么通用,并且实现一些特定的业务逻辑。它们具有有意义的业务操作,并且是客户主要调用的服务。
重新设计时应遵循的原则:
我强烈建议您
查看这份备忘单,确保您的重新设计覆盖了其中的所有内容。这是很有帮助的。
总的来说,您应该确保:
每个服务都有一个共同的上下文,并遵循关注点分离原则。例如,客户服务仅用于与客户相关的操作等。
实体和实用程序服务都是业务无关且基本的。因此,它们可以在多种情境和上下文中重复使用而不需要更改。合同必须简单-只有CRUD和在大多数使用场景中有意义的常见操作。
服务遵循通用数据模型-确保您使用的所有数据结构在所有服务中都统一使用,以防止未来需要进行集成工作,并促进客户端利用服务的组合。如果您需要接收另一个服务返回的客户,则应该无需转换即可完成。
好的,但是哪里放置非通用逻辑?
现在,每当您需要复杂的业务功能时,您有多个抽象业务逻辑的选项。选择哪个取决于您的情况:
- 让所有客户端都遵循逻辑。让他们组合您的简化服务。
- 如果有业务逻辑在多个应用程序中通常实现并且具有重复使用的潜力,您可以实现一个组合服务,该服务重复使用多个现有的底层服务并公开逻辑。
服务可组合性。关注多个API调用通信开销。
好吧,这是一个古老的问题 - 当它们可能会创建一些通信开销时,您是否应进行多个API调用?答案是 - 这取决于您的场景有多么复杂,您期望多少重用以及您希望有多大的灵活性。速度是否至关重要?在多大程度上?在面向服务的架构中,这是一种非常常见的方法 - 重用现有服务并根据需要将它们组合在新配置中。是的,它确实增加了一些开销,但我已经看到过在非常复杂的环境中(例如电信)的实现,由于使用ESB解决方案,消息队列等,开销与收益相比微不足道。这里是一种常见的架构方法(来自serviceorientation.com的图像):
![Composing Web Services to Solve a Bigger Problem](https://istack.dev59.com/b4jCn.webp)
必要的遗留代码重构提醒
往往情况下,改变多个现有客户系统的既定合同是一项混乱的任务,可能需要进行大量的重构并需要查找深藏在(可能)遗留代码中的功能。业务逻辑可能分散在各个地方。因此,请确保您已经准备好并具备控制、时间和意愿来领导这场战斗。
希望这可以帮到您。