我有几个关于单体和n层架构的问题。
首先，Monolith 和 n 层架构有什么区别？
其次，假设我有一个包含多个项目的 Visual Studio 解决方案，例如：
这被认为是单体架构还是 n 层架构？
如果我的微服务包含（比如说）3 个 Web API，并且我在单个单独的 Visual Studio 解决方案中构建每个服务，可以实现我以前的项目结构（服务层、业务层、数据层等）？
非常感谢你，对不起我的英语不好。
【问题讨论】：
标签： architecture microservices n-tier-architecture n-layer
好的，所以Monolith 解决方案基本上是在一个解决方案中拥有一个项目的旧方法，其中包含所有代码。
假设你正在做一个网站。
这意味着您将使用单个项目创建单个解决方案，并且所有数据库调用（持久性）、逻辑（业务逻辑/服务）以及最终弄清楚如何显示计算数据（表示）都混合在在那个单一项目中的混乱方式。有时人们试图将关注点拆分到文件夹中，但通常情况下是一团糟。这使得应用程序的支持/维护成为一场噩梦。如果您希望对网站/应用程序进行单一更改，整个应用程序将离线/重新启动。
对
n-tier / n-layered 解决方案/应用程序。这是我们在一个解决方案中有多个项目（通常）的地方，它将我们的应用程序的关注点分成更多的小组件。这使我们能够将问题空间保持在单个区域，使其更易于维护和支持。这也使您的各种组件/项目/dll 更容易重用到应用程序的各种其他子系统中。它比旧的单体架构模式要好得多。但是，如果您希望对网站/应用程序进行一次更改，整个应用程序仍将离线/重新启动。
最后，我们有microservices。这是一个更现代的概念，并随着monolith -> n tier -> microservices 的发展而继续发展。这是当我们将应用程序关注点拆分为单独的应用程序时，以便在需要更新一个微服务时，整个应用程序不会停止。当然，依赖于微服务的应用程序的部分可能会停止/受到影响，但整个应用程序可能不会。
举个例子：
我有一个销售宠物（猫/狗/等）的网站。 我可能会将这个网站拆分为单独的微服务迷你网站：
因此，它们中的每一个都是一个单独的网站，就像 n 层架构的应用程序一样。所以它会有一个表示层（MVC 网站）。一些数据库项目和一些基本服务。
现在 4 个微服务（迷你网站）中的每一个都这样做。
现在，您需要使用网站的管理部分更新一些内容。您将其脱机，主网站将保持正常运行。人们仍然可以浏览和购买动物。
所以，是的，如果您的应用程序足够大，并且具有您可能想要分割的区域，那么实现微服务是一件好事。它确实增加了一些复杂性，但也带来了它自己的优势。
是的，你的微服务应该遵循 n 层模式如果你的应用程序不是一些愚蠢的 hello-world 应用程序或一些研究项目。
【讨论】：
microservice 方法主要用于类似平台的应用程序，如果我没记错的话 - 这意味着您可以轻松地创建另一个例如。将与所有现有微服务交互的前端应用程序，而使用monolith，您必须编辑您的单个解决方案并将新应用程序合并到其中。此外，微服务及其所有服务、前端应用程序等可以托管在不同的服务器上，这是单体应用无法做到的。关于n layered 架构 - 没关系，所有单体或微服务现在都应该实现它。
您的问题的简短答案是 - 技术堆栈的水平分区（n 层架构） 对比 技术栈的垂直分区（微服务）
【讨论】：