今天我开始阅读微服务架构 - 它看起来非常有趣！ 但我有一个疑问，我需要一些exlanation： 假设我想创建一个博客并为此构建4个微服务：用户/登录服务，文章服务，评论服务和报告/分析服务（不是一个现实的例子，我知道......）。 报告/分析服务纯粹是后端 - 这里没有问题可供我理解。 但其他三个涉及一些UI部分 - 至于我的理解，这个UI部分也应该是微服务本身的一部分，对吧？ UI集成将如何工作？那么我是否会有第5个“前门”服务收集用户请求，将它们转发给其他服务，然后用HTML / CSS回答，然后前门服务会将个别响应组合成返回给用户的内容？ / p>
您是否有针对此类情况的示例/用例的任何更改？
谢谢和问候！
答案 0 :(得分：5)
根据我的经验，在微服务架构中，拥有一个像API网关一样的服务通常很有用，它可以前面加载到更多特定于域的微服务来完成工作。 API网关的职责可能是聚合结果并将它们返回到前端，但是整合从微服务返回的响应将耦合两个服务的知识并将一些领域知识泄漏到API网关层。 API网关应该尽可能地薄，并且应该与服务联系以实现某些目标。
您在此处描述的用例将尝试在联系登录服务，然后是文章或评论服务之前对用户进行身份验证。如果它们是同一应用程序的一部分，那么前端仍然会保持整体状态。
如果应用程序变得足够大，应用程序将被产品分开，但可能仍然依赖于一组核心服务。在这种情况下，他们可能会生活在不同的UI中，这样就不会那么复杂（有点像后端的微服务）。同样需要注意的是，微服务架构通常会引入一组核心服务，这些服务可以被不同的团队使用，因此可以使用具有不同UI的不同应用程序。一个例子是电子商务应用程序，其具有客户服务部门编辑订单，用于使用订单服务来为客户和客户进行购买。实际上，这些是两个应用程序，它们将具有两个不同的UI。希望这有帮助！
我想指出的另一件事是，当应用程序变得太大而复杂时，微服务架构才会很好。微服务架构需要更多资源，因为它有一些额外的开销。首先从单片开始:)。
答案 1 :(得分：0)
您可以采用几种不同的方法。如果有意义的话，每个微服务都可以拥有自己的可以呈现的页面。然后，您只需要一个前端即可为所涉及的服务创建适当的导航。该菜单是为应用程序构建的，每个服务都呈现自己的UI。当您需要基于应用程序（例如，基于许可）需要从应用程序中包含或排除服务时，此方法很好用。
或者，每个微服务都可以提供一组HTML片段。然后，您需要一个前端服务来构成页面和导航。片段必须全部使用相同的CSS词汇表或用于定义外观的任何手段。当编写HTML片段而没有可能包含的一项或多项服务时，这种方法可能导致页面奇怪。
最后，可以在微服务之上构建完整的应用程序UI。这样可以使UI更加“紧密”，流程更流畅。随着新服务的添加，通常也将花费更长的时间并且更难更改。
什么是最好的？与软件开发中的大多数情况一样，这取决于您要构建的内容。对于Blog应用程序，您描述了我怀疑每个服务都可以有一个完整的页面UI。我看到的方法更常见的是拥有完整的UI。 HTML Fragment方法更通用，但是最初需要花费更长的时间进行开发。一旦构建完成，您将在部署应用程序方面拥有更大的灵活性。对于软件产品公司来说，这可能是真正的好处。
希望有帮助。