微服务与多层架构

时间:2017-01-24 19:45:25

标签: asp.net-web-api architecture microservices multi-layer

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

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

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

2 个答案:

答案 0 :(得分:11)

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

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

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

关于这个

  

多层架构已经过时了吗?

不,它们既可以使用,也可以使用微服务,因为规则层应该比整体应用程序更薄。

  

为我的这些架构设计带来哪些好处和问题   应用

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

答案 1 :(得分:0)

感谢分享!

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

如果以下任何一种与您有关,请确保整体结构良好且足以满足您的应用需求

  • 小应用。您的应用程序非常简单,并且在部署后无法满足严重的负载,或者已经投入生产,但尚未遇到任何性能问题。

  • 快速启动。您有一个新鲜的想法或应尽快启动的初创公司,因为目前它没有任何竞争对手,您的项目将有所有机会获得成功。想法实施的紧迫期限。预算有限。

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

  • 没有使用微服务的经验。您的团队规模不够大,无法分离人员来设计单独的微服务,或者您的团队没有构建它们的经验。当然,开始学习和实践微服务会更好,但是应成为应用程序框架的功能并不是实现它的最佳机会。

如果您知道在哪种情况下选择后者,那么,相对于微服务体系结构,Monolithic与微服务体系结构是一个更容易回答的问题。

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

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

  • 微服务体验。您的团队中有一些开发人员,他们在将微服务设计和部署到生产中具有丰富的经验,并且您肯定在开发微服务的过程中会有一部分团队支持和开发主应用程序。

  • 乌托邦。您有足够的钱,忠实的经理和延长的期限。

现在,选择整体还是微服务应该更容易。