14

我有几个关于单体和n 层架构的问题。

首先，Monolith 和 n 层架构有什么区别？

其次，假设我有一个包含多个项目的 Visual Studio 解决方案，例如：

  1. 表示层
  2. 服务层
  3. 业务层
  4. 跨层
  5. 数据层
  6. 单元测试

这被认为是单体架构还是 n 层架构？

如果我有包含（比如说）3 个 Web API 的微服务，并且我在单个单独的 Visual Studio 解决方案中构建每个服务，是否可以实现我以前的项目结构（服务层、业务层、数据层等）？

非常感谢你，对不起我的英语不好。

4

2 回答 2

27

好的，所以Monolith解决方案基本上是在一个解决方案中拥有一个项目的旧方法，其中包含所有代码。

所以假设你正在做一个网站。

这意味着您将使用单个项目创建单个解决方案，并且所有数据库调用（持久性）、逻辑（业务逻辑/服务），最后弄清楚如何以混乱的方式显示计算数据（演示文稿）在那个单一的项目中。有时人们试图将关注点拆分到文件夹中，但通常情况下是一团糟。这使得应用程序的支持/维护成为一场噩梦。如果您希望对网站/应用程序进行一次更改，整个应用程序将离线/重新启动。

对比

n-tier / n-layered解决方案/应用程序。这是我们在一个解决方案中有多个项目（通常）的地方，它将我们的应用程序的关注点分成更多的小组件。这使我们能够将问题空间保持在单个区域，使其更易于维护和支持。这也使您可以更轻松地将各种组件/项目/dll重用到应用程序的各种其他子系统中。它比旧的单体架构模式要好得多。但是，如果您希望对网站/应用程序进行一次更改，整个应用程序仍将离线/重新启动。

最后，我们有microservices. 这是一个更现代的概念，并随着monolith -> n tier -> microservices. 这是当我们将应用程序关注点拆分为单个应用程序时，这样当需要更新一个微服务时，整个应用程序就不会停止。当然，依赖于微服务的应用程序部分可能会停止/受到影响，但整个应用程序可能不会。

让我们举个例子：

我有一个销售宠物（猫/狗/等）的网站。我可能会将这个网站拆分为单独的微服务迷你网站：

  • 验证
  • 管理/后端管理（想想：只有管理员才能看到的东西）
  • 公共网站
  • 动物库存
  • 购物车

因此，它们中的每一个都是一个网站，就像 n 层架构的应用程序一样。所以它会有一个表示层（MVC 网站）。一些数据库项目和一些基本服务。

现在 4 个微服务（迷你网站）中的每一个都这样做。

现在，您需要使用网站的管理部分更新一些内容。您将其脱机，主网站将保持正常运行。人们仍然可以浏览和购买动物。

所以，是的，如果您的应用程序足够大以至于它具有您可能想要分割的区域，那么实现微服务是一件好事。它确实增加了一些复杂性，但也带来了它自己的优势。

是的，如果您的应用程序不是一些愚蠢的 hello-world 应用程序或某个研究项目，那么您的微服务应该遵循 n 层模式。

于 2017-08-13T14:09:31.503 回答
0

您的问题的简短答案是 - 技术堆栈的水平分区（n 层架构）与技术堆栈的垂直分区（微服务）

于 2019-10-01T13:33:31.250 回答