30

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

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

在此处输入图像描述

4

4 回答 4

9

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

就微服务而言，第二种方式最为合适，通过 API 公开其逻辑。

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

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

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

于 2014-12-22T00:13:06.253 回答
5

与软件工程中的往常一样，答案是视情况而定。我现在无法想象一个原因，但选项 1 在某些特定情况下可能很有用。

但是，考虑到微服务的正式定义，选项 2 更好地说明了这一点。拥有微服务的主要优势之一是能够重用它。不同的应用程序对呈现信息有不同的要求和需求。让您的微服务返回您的数据的 JSON 表示将使您在如何格式化此信息方面具有更大的灵活性。

于 2014-11-25T13:08:23.260 回答
3

Microservice apigateway的 API 网关模式是您可以开始将调用分发或转发到不同服务的第一个点

于 2015-08-05T13:25:45.590 回答
1

我们目前正在实施类似于您的第二个选项的架构。我们在执行此操作时遇到了以下复杂性：（任何人都可以随意加入，因为它仍在进行中）

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

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

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