将微服务推广到公共API有什么好的做法？

Question

在观看和阅读Martin Fowler，Sam Newman，Adrian Cockcroft和Sudhir Tones的文章后，微服务似乎非常适合我的软件。但是，在深入思考实施时，有许多问题：

1. 我的软件有一个用户界面，我们称之为基于网络的组件。该组件需要在内部协调/编排调用10-20个不同的微服务（让我们调用它＆＃34;私有微服务＆＃34;）并将数据返回到AJAX调用。在这个组件中耦合编排逻辑是一个好的设计吗？或者我应该创建另一个完成工作的微服务，基于Web的组件应该非常薄，以便将调用委托给这个微服务吗？
2. 我需要公开一些公共API。我应该有一个单独的层来委托调用，就像上面的情况一样吗？

我认为这可能或多或少与公共/私人微服务的设计模式有关。

解决上述问题的好方法是什么？

2015年4月9日更新：

API网关模式实际上解决了我的问题。我也同意有关EAI模式或安全考虑的其他答案。

为了进一步扩展我的发现，我认为Netflix架构正在拥有所谓的边缘服务＆＃34;，它是服务来自基于网络或设备和中间的请求的前端层 - 服务实际上是您的微服务。所以我认为将中间层服务推广为边缘服务，这必须是一个代表。它将保持中间层的清洁和一致。

看看https://github.com/cfregly/fluxcapacitor#project-overview有更多想法。

Answer 1

这些决定将由两个问题驱动：国家和安全（这是国家的具体情况） 状态：你将如何保持瞬态（即你将会推入会话数据的东西）？如果你想尝试将它们保存在UI中，那么你可以考虑保留纯粹的微服务，否则你需要一个协调的服务＆＃34;保持这种状态，并且必要时也将成为调度中心。

安全性：身份验证是状态的特定情况，通常无法存储在客户端中。通常是推动人们使用有状态应用程序的东西。它也将是API层与Web应用程序层的驱动因素。需要保护API层，可能是通过某种Auth令牌方案（查看OAuth或类似方法）。此令牌的验证以及用户凭据的检索可能相当慢（相对而言）。这通常在集中服务中最有效，而不是在每个微服务调用上完成。

Answer 2

您可以在Process Manager中的长时间运行的事务之间放置所有编排逻辑。进程管理器可以订阅事件，从事件派生命令并将此命令委派给您的另一个MS。您在佐贺可以处理的所有失败。当你的长期运行逻辑抛出一些例外时，佐贺应该执行补偿行动。

有关Process Manager 模式和Saga模式的更多信息。

Answer 3

API网关模式是在一组微服务之前实现公共API的好方法：http://microservices.io/patterns/apigateway.html