微服务与多层架构 [关闭]

Posted 2023-03-08

技术标签:

【中文标题】微服务与多层架构 [关闭]【英文标题】：Microservices vs multi-layered architecture [closed] 【发布时间】：2017-06-09 19:25:57 【问题描述】：

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

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

我没有微服务架构方面的经验，所以我的问题是：多层架构已经过时了吗？这样的架构设计能给我的应用带来什么好处和问题？

【问题讨论】：

【参考方案1】：

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

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

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

关于这个

多层架构已经过时了吗？

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

这样的架构设计能给我带来什么好处和问题申请？

我建议您查看comparison between microservice and monolithic architecture 样式和此post。要划分与否，您应该考虑项目的规模和复杂性，以及团队的规模。划分必须为整个应用程序带来好处，使开发更容易。 Monolithic 应用程序有其自身的优势，并且在项目规模达到一定规模时，它可能是一个不错的决定。当然，与庞大的单体应用程序以及一百个非常小的（纳米）服务一起工作是一场噩梦。

【讨论】：

【参考方案2】：

感谢分享！

总之，单体结构和微服务结构各有利弊，选择正确的选项取决于您的截止日期、开发团队以及您的应用在部署后将面临的负载。

如果以下任何选项与您有关，请确保整体结构对于您的应用来说是好的且足够的：

小应用程序。您的应用非常简单，部署后不会遇到严重的负载，或者它已经投入生产，但还没有遇到任何性能问题。

快速启动。你有一个新的想法或一个初创公司，应该尽快推出，因为目前它没有任何竞争对手，你的项目将有机会成功。想法实施的最后期限紧迫。预算有限。

概念证明。您想通过为目标受众构建基本产品来检查您的想法是否可行和有用。

没有微服务经验。您的团队不够大，无法将人员分开来设计单独的微服务，或者您的团队没有构建它们的经验。当然，最好开始学习和实践微服务，但应该成为应用骨架的功能并不是最好的机会。

如果您知道在什么情况下选择后者，那么单体架构与微服务架构比较容易回答。

复杂的应用程序。您的应用足够复杂，无法集成新工具，或者遇到无法通过垂直扩展解决的负载问题，或者在这种情况下无利可图。

计划发展和扩展应用程序。您的项目经历了稳定的负载增长，并且您计划集成新工具，但当出现扩展问题时，应用程序可能会达到临界点。