微服务与多层架构

Posted 2021-03-29

我的项目有一个后端服务（Web API）和一个前端SPA应用程序。后端服务具有位于不同.net程序集中的表示，应用程序服务，域和基础结构层。域层具有业务域对象，基础架构 - 与外部数据和其他东西的通信，应用程序服务 - 表示层使用的服务集，表示 - Web API控制器。我认为这是非常常见的分层架构。

我们的新架构师宣布，我们将移动后端到微服务架构，制动我们的层并将域，应用服务和基础设施层划分为少数服务，并将表示层转换为后端以用于前端层（如here所述）。在功能方面，我们将有移动应用程序。 Sql Server数据库将暂时保留原样。

我没有微服务架构的经验，所以我的问题是：多层架构已经过时了吗？哪些优点和问题可以为我的应用程序带来这样的架构设计？

答案

微服务和分层架构有点不同。微服务架构，它是关于如何构建应用程序，它具有哪些组件（服务）以及这些服务如何相互通信，如何开发，部署等等。

多层架构是关于逻辑将应用程序划分为多个层，其中每个层都有自己的逻辑功能（表示，域等）。通常，多层体系结构与单片体系结构和服务设计有关。

根据您的描述，您不会分解您的层，您的架构师希望将逻辑分成不同的服务。这两种架构风格可以一起使用。例如，您可以拥有3项服务，每项服务都可以拥有演示，域和服务层。如果您在一个服务中的当前层足够重，那么将它们分开是有意义的，这使得开发和测试更容易。前端风格的后端也有其优点，特别是如果你想添加一个移动应用程序。

对这个

多层架构已经过时了吗？

不，它们都被使用，但是使用微服务作为规则层应该比单片应用薄得多。

哪些优点和问题可以为我的应用程序带来这样的架构设计？

我建议你看看comparison between microservice and monolithic architecture风格和这个post。要划分与否，您应该考虑项目的规模和复杂程度，以及团队的规模。划分必须为整个应用程序带来好处，使开发更容易。单片应用程序有其自身的好处，并且在项目的某个大小上，它可以是一个很好的决定。当然，这是一个噩梦，使用巨大的单片应用程序以及一百个非常小的（纳米）服务。

另一答案

感谢分享！

总之，单片和微服务结构都有其优点和缺点，选择正确的选项取决于您的截止日期，开发团队以及部署后应用程序将面临的负载。

如果您有以下任何选项，请确保整体结构对您的应用程序而言足够好且足够：

• 小应用程序。您的应用程序非常简单，在部署后无法满足严重负载，或者它已经在生产中但尚未遇到任何性能问题。
• 快速启动。你有一个应该尽快推出的新想法或创业公司，因为目前它没有任何竞争对手，你的项目将有机会获得成功。想法实施的截止日期紧迫。预算有限。
• 概念证明。您想通过为目标受众构建基本产品来检查您的想法是否可行且有用。
• 没有微服务经验。您的团队不够大，无法将人员分开设计单独的微服务，或者您的团队没有构建它们的经验。当然，最好开始学习和练习微服务，但应该是应用程序骨架的功能并不是最好的机会。

如果你知道在什么情况下选择后者，单片与微服务架构是一个更容易回答的问题。

• 复杂的应用。您的应用程序非常复杂，可以集成新工具，或者遇到无法通过垂直扩展解决的负载问题，或者在这种情况下无法盈利。
• 计划增长和扩展应用程序。您的项目经历了稳定的负载增长，并且您计划集成新工具，但是当可能出现扩展问题时，应用程序可能会达到临界点。
• 微服务经验。您的团队中有开发人员在设计和部署微服务到生产方面经验丰富，并且您确信团队的一部分将在他们处理微服务时支持和开发主应用程序。
• 乌托邦。你有足够的钱，忠诚的经理和延长的期限。

现在，monolith与微服务的选择应该更容易。