将微服务推广到公共 API 的良好做法是什么？答案

【问题标题】：What is a good practice to promote a microservice to a public API?将微服务推广到公共 API 的良好做法是什么？
【发布时间】：2015-05-18 05:41:00
【问题描述】：

在观看并阅读了 Martin Fowler、Sam Newman、Adrian Cockcroft 和 Sudhir Tones 的大量文章之后，微服务似乎非常适合我的软件。但是，在深入考虑实施时，存在一些问题：

我的软件有一个 UI，我们称它为基于 Web 的组件。该组件需要在内部协调/编排对 10-20 个不同微服务的调用（我们称之为“私有微服务”）并将数据返回给 AJAX 调用。在这个组件中耦合编排逻辑是一个好的设计吗？或者我应该创建另一个完成这项工作的微服务，并且基于 Web 的组件应该非常薄以将调用委托给这个微服务？
我需要公开一些公共 API。我应该有一个单独的层来委派上述情况下的调用吗？

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

解决上述问题的好模式是什么？

2015 年 4 月 9 日更新：

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

进一步扩展我的发现，我认为 Netflix 架构具有所谓的“边缘服务”，它是服务来自基于 Web 或设备的请求的前端，而中间层服务实际上是你的微服务。所以我认为将中间层服务推广为边缘服务，这必须是一个代表。它将保持中间层的清洁和一致。

查看https://github.com/cfregly/fluxcapacitor#project-overview 以获得更多想法。

【问题讨论】：

标签： architecture microservices

【解决方案1】：

这些决定将由两个问题驱动：状态和安全（这是状态的特定情况）。
状态：你将如何保持瞬态（即你会塞进会话数据的东西）？如果您想尝试将它们保留在 UI 中，那么您可以考虑保留纯微服务，否则您将需要一个协调的“服务”来保持该状态，并且必然也将成为调度中心。

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

【讨论】：

【解决方案2】：

您可以将长时间运行的事务之间的所有编排逻辑放在流程管理器中。流程管理器可以订阅事件，从事件派生命令并将此命令委托给您的另一个 MS。您可以在 Saga 中处理的所有故障。当您的长时间运行的逻辑抛出一些异常时，Saga 应该执行补偿操作。

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

【讨论】：

【解决方案3】：

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

【讨论】：

确实，我最近才知道。我会用更多细节更新答案。