rest - 使用RESTful服务和应用程序API实现SOA？

Question

目前，我们的后台，前端以及公共(public)API都使用了一个庞大的API。

这使我很头疼，因为在构建新的端点时，我在代码中发现了很多特定于应用程序的逻辑，而这些逻辑我不一定要包含在端点中。例如，创建用户的代码可能包含发送欢迎电子邮件的代码，但是由于后台端点不需要这样做，因此我将需要添加一个没有该逻辑的新端点。

我当时正在考虑进行大型重构，以将我们的代码基础分解为许多较小的高度特定的服务API，然后在这些基础之上构建一组小型应用程序API。

因此，例如，在重构之后，用于创建新用户的应用程序端点可能会执行以下操作:

customerService.createCustomer();
paymentService.chargeCard();
emailService.sendWelcomeEmail();

应用程序和服务API将完全是独立的代码库(每个服务可能是独立的代码库)，也可以使用不同的语言来构建它们。它们将仅通过REST API调用进行交互。它们将位于同一本地网络上，因此延迟不是一个大问题。

这是一个坏主意吗？我从未见过/曾经在将两者分开的代码库上工作过，所以也许有更好的体系结构可以实现我想要的灵活性和可维护性？

忠告，链接或评论将不胜感激。

Answer 1

您提供多个定义明确的服务的想法是正确的，并且确实是实现此目的的最佳方法。不管看起来多么流行，采用纯微服务方法经常被证明是一种过大的杀伤力。这就是为什么我会正确地重新设计现有的API/服务，并遵循以下扎实可靠的SOA设计原则的原因。在serviceorientation.com和soapatterns.org上都可以找到良好的资源，我在职业生涯中一直将它们用作引用。

考虑您需要什么类型的服务

(图片来自serviceorientation.com)

实体服务通常是您的客户，即付款服务-例如服务围绕您域中的实体。它们应该与业务无关，并且能够在所有情况下重用。如果客户有足够的需求，有时可以直接致电他们。任务服务可以调用它们。

实用程序服务包含您可能会在其他服务中重用的逻辑，但通常不会被客户端直接调用。相反，它们将由Task和Entity服务调用。一个示例可能是音译服务。

任务服务将实体和实用程序服务组合并重用为有意义的任务。大多数情况下，它们不是那么不可知论，并且确实实现了一些特定的业务逻辑。他们拥有有意义的业务运营，而这正是客户最常要求的。

重新设计时应遵循的原则

我强烈建议您使用 over this cheat sheet并确保在进行重新设计时将所有内容都包括在内。这是很大的帮助。

通常，您应确保:

每个服务都有一个公共(public)上下文，并遵循关注点分离原则。例如。 Clients服务仅适用于与客户相关的操作等。

每个Entity和Utility服务都是业务无关的，并且是足够基本的。因此，它可以在多种情况和上下文中重用而无需更改。契约(Contract)必须简单-CRUD，并且只有在大多数使用情况下才有意义的常见操作。

服务遵循通用数据模型-确保在所有服务中统一使用您使用的所有数据结构，以防止将来需要进行集成工作，并促进服务组合以供客户利用。如果您需要接收其他服务返回的客户，则无需转换

就可以实现

好的，但是在哪里放置非不可知论逻辑呢？

现在，当您需要复杂的业务功能时，可以有多种选择来抽象业务逻辑。这取决于您的方案要选择什么:

将逻辑留给所有客户端。让他们结合您的简化服务

如果存在通常在多个应用程序中实现并且可能被大量重用的业务逻辑，则可以实现复合服务，该服务可重用多个现有基础服务并公开该逻辑。

服务可组合性。对多个API的关注会导致通信开销。

好吧，这是一个古老的问题-当它们可能会产生一些通信开销时，您应该进行多个API调用吗？答案是-它取决于您的方案的复杂程度，期望的重用程度和希望的灵活性。速度也很关键吗？到什么程度？但是，在面向服务的体系结构中，这是一种非常常见的方法-重用您现有的服务，并根据需要将它们组合到新的配置中。是的，它确实增加了一些开销，但是我已经看到了在非常复杂的环境中的实现，例如电信，在这些环境中，由于使用了ESB解决方案，消息队列等，与 yield 相比，开销可以忽略不计。这是一种常见的体系结构方法(来自serviceorientation.com):



强制性的传统重构注意

通常，更改多个现有客户端系统的既定契约(Contract)是一件很麻烦的事情，很可能导致大量重构，并且需要寻找(可能是)遗留代码中深处的“针刺堆栈”功能。业务逻辑可能分散在各处。因此，请确保您已做好准备并掌握控制权，时间和意愿来领导这场战斗。

希望这可以帮助