web-applications之基于微服务的 Web 应用程序的架构_编程设计

我对 Web 应用程序分化为微服务的点感到困惑 - 是在 url 级别还是模型级别？
例如，假设我有一个提供 3 个页面的整体式应用程序。假设每个页面都有一个单独的用例，我想用他们自己的微服务来支持每个页面。现在，以下哪一种是实现基于微服务的架构的正确方法:

我创建了三个不同的应用程序(微服务)，每个应用程序都包含其中一个页面的(路由、 Controller 、模型、模板)。然后根据请求的页面，我将请求路由到该特定应用程序。这意味着从数据库到 HTML 的整个页面都由单独的应用程序提供。基本上，同一网站中的不同页面完全由后端的不同应用程序提供服务。

这 3 个微服务不处理 UI 内容，而只处理其用例(模型、 Controller 、无模板)的数据，并通过 REST api 公开它。我有一个面向公众的应用程序。该应用程序仅查询三个不同的应用程序(微服务)以获取数据，然后构建要返回给浏览器的 html 页面。在这种情况下，Web 应用程序中的所有页面都由一个应用程序提供服务，该应用程序在内部使用三个不同的微服务。

请您参考如下方法:

您的问题在于如何为您的微服务建模。

就微服务而言，第二种方法是最合适的，它通过 API 公开其逻辑。

在为微服务建模时，请始终牢记以下事实。

松耦合 :当服务松散耦合时，对一项服务的更改不应要求对另一项服务的更改。微服务的全部意义在于能够对一个服务进行更改并部署它，而无需更改系统的任何其他部分。这真的很重要。

强凝聚力 :我们希望相关的行为坐在一起，而无关的行为坐在其他地方。为什么？好吧，如果我们想改变行为，我们希望能够在一个地方改变它，并尽快发布该改变。