问微服务:如何集成UI？

EN

根据我的经验，在微服务体系结构中，让服务充当API网关，将其前端加载到执行工作的更特定于域的微服务中，通常是很有用的。API网关的职责可能是聚合结果并将它们返回到前端，但是合并从微服务返回的响应将耦合这两个服务的知识，并将一些领域知识泄漏到API网关层。API网关可能应该尽可能地精简，并且应该伸手到服务来完成一些事情。

您描述的这里的用例将尝试在访问登录服务和文章或评论服务之前对用户进行身份验证。总而言之，如果它们是同一应用程序的一部分，前端仍将保持整体式。

如果应用程序变得足够大，应用程序将按产品分离，但可能仍然依赖于一组核心服务。在这种情况下，它们可能生活在不同的UI中，所以这将使其更简单(有点像后端的微服务)。顺便说一句，微服务架构通常引入一组核心服务，不同的团队可以利用这些服务，因此具有不同UI的不同应用程序也可以利用这些服务。一个例子是电子商务应用程序，它让客户服务部门编辑订单，为客户提供服务，客户使用orders服务进行购买。实际上，这是两个应用程序，它们将具有两个不同的UI。希望这能有所帮助！

我想指出的另一件事是，只有当应用程序变得太大和太复杂时，微服务架构才是伟大的。微服务架构需要更多的资源，因为它有一些额外的开销。首先从一个整体开始:)。

您可以采用几种不同的方法。如果有意义的话，每个微服务都可以有自己的页面来呈现。然后，您只需要一个前端，它可以为所涉及的服务创建适当的导航。菜单是为应用程序构建的，每个服务都呈现其自己的UI。当您需要能够在应用程序中包含或排除服务时，这种方法效果很好，例如，基于许可。

或者，每个微服务可以提供一组HTML片段。然后，您需要一个前端服务来组合页面和导航。这些片段必须都使用相同的CSS词汇表，或者使用您用来定义外观的任何方法。当HTML片段没有包含一个或多个可能包含的服务时，这种方法可能会导致奇怪的页面。

最后，可以在微服务之上构建完整的应用程序UI。这可以产生一个“更紧凑”的UI和更好的流程。随着新服务的添加，它通常也会花费更长的时间，更难改变。

什么是最好的？与软件开发中的大多数情况一样，这取决于您正在构建的是什么。在博客应用程序的情况下，您描述了我怀疑每个服务都可以有一个完整的页面UI。更常见的是拥有完整的UI是我所见过的方法。HTML片段方法用途更广，但最初的开发时间较长。但是，一旦构建完成，您将在如何部署应用程序方面拥有更大的灵活性。对于软件产品公司来说，这可能是一个真正的好处。

希望这能有所帮助。