architecture - 将微服务推广到公共(public) API 的良好做法是什么？

Question

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

我的软件有一个 UI，我们称它为基于 Web 的组件。该组件需要在内部协调/编排对 10-20 个不同微服务的调用(我们称之为“私有(private)微服务”)并将数据返回给 AJAX 调用。在这个组件中耦合编排逻辑是一个好的设计吗？或者我应该创建另一个完成这项工作的微服务，并且基于 Web 的组件应该非常薄以将调用委托(delegate)给这个微服务？

我需要公开一些公共(public) API。我应该有一个单独的层来委派上述情况下的调用吗？

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

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

2015 年 4 月 9 日更新 :

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

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

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

Answer 1

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