asp.net-web-api - 微服务与多层架构

Question

关闭。这个问题是opinion-based .它目前不接受答案。












想改善这个问题吗？更新问题，以便可以通过 editing this post 用事实和引文回答问题.

11 个月前关闭。




Improve this question




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

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

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

Answer 1

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

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

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

对这个

Is multi-layered architecture out of fashion already?

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

What benefits and problems can bring such architecture design for my application?

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