基于微服务的web应用程序的体系结构

Question

我对Web应用程序分散到微服务这一点感到困惑 - 它是在url级别还是在模型级别？ 举个例子，假设我有一个3页的单片应用程序。假设每个页面都有一个单独的用例，我想用他们自己的微服务来支持它们。现在，哪些是实现基于微服务的架构的正确方法：

• 我创建了三个不同的应用程序（微服务），每个应用程序包含其中一个页面的（路径，控制器，模型，模板）。然后根据请求的页面，我将请求路由到该特定应用程序。这意味着从数据库到HTML的整个页面由一个单独的应用程序提供。基本上，同一网站中的不同页面完全由后端的不同应用程序提供服务。
• 3个微服务不处理UI内容，只处理其用例（模型，控制器，无模板）的数据，并通过REST API进行公开。我有一个面向公众的应用程序。此应用程序仅查询三个不同的应用程序（微服务），然后构建要返回给浏览器的html页面。在这种情况下，Web应用程序中的所有页面都由一个内部使用三种不同微服务的应用程序提供服务。

Answer 1

你麻烦的是如何为你的微服务建模。

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

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

• 松散耦合：当服务松散耦合时，对一项服务的更改不应要求更改另一项服务。这个微服务的重点是能够对一个服务进行更改并进行部署，而不需要更改系统的任何其他部分。这非常重要。

• 强大的凝聚力：我们希望相关行为坐在一起，并且无关联的行为可以放在其他地方。为什么？好吧，如果我们想要改变行为，我们希望能够在一个地方更改它，并尽快释放该更改。

Answer 2

与软件工程一样，答案取决于它。我现在无法想象一个原因，但选项1在某些特定情况下可能会有用。

然而，考虑到微服务的正式定义，选项2更好地说明了它。拥有微服务的一个主要优点是能够重用它。不同的应用程序对呈现信息有不同的要求和需求。使您的微服务返回数据的JSON表示将使您更灵活地格式化此信息。

Answer 3

微服务apigateway的Api网关模式是您可以开始将呼叫分发或转发到不同服务的第一点

Answer 4

我们目前正在实施类似于您的第二个选项的架构。我们在做这件事时遇到了以下复杂问题:(任何人都可以随意参与其中，因为它仍在进行中）

• 您的系统（面向应用的用户）在技术上仍然是一个单一的应用程序。每次在REST API中进行更改时，您都必须更改前置应用程序以处理这些新更改。不要让我开始介绍如何在其背后引入新的微服务。所以从本质上讲，你提供的微服务越多，API网关就越大。 （https://www.nginx.com/blog/building-microservices-using-an-api-gateway/）

  

API网关也有一些缺点。它是另一个必须开发，部署和管理的高可用组件。 API Gateway也存在开发瓶颈的风险。开发人员必须更新API网关才能公开每个微服务的端点。重要的是，更新API网关的过程尽可能轻量级。否则，开发人员将被迫排队等待更新网关。然而，尽管存在这些缺点，但对于大多数实际应用来说，使用API​​网关是有意义的。

• 为了重新使用，我设计了一个抽象层，它定义了与每个微服务进行通信的独特行为。每个微服务的一个具体实现。这引入了另一层复杂性，因为现在我们必须维护我们所谓的＆＃34; RPC连接器＆＃34;以及相应的微服务。就个人而言，这需要很多开发人员的时间，因为除了维护他们各自的微服务之外，他们还必须维护连接器。如果其中任何一个过时，公共应用程序将失败。此外，连接器中的更改将需要公共应用程序重建（我们当前将连接器定义为jar依赖项）。
• 虽然在另一篇文章和博客中提到过，但在处理处理自己的数据库的多个微服务时，外键关系变得一团糟。 （每个服务模式的数据库）您面向前方的应用程序现在面临着必须将它们拼接在一起的问题。 （＆＃34;我需要这些数据，但我必须在每个微服务中查找这些键，看看谁有什么。＆＃34;）我并不是说这是正确的方法，但如果我们和＃39;重新处理返回的多行，然后必须从微服务中单独解析每个ID。我不确定这有多高效。我很高兴听到建议。