对Web应用程序使用单独的API和UI服务器的好处
在工作中，我们已经开发了将近两年的大型内部应用程序；我最近才刚加入该项目，有些架构使我有些困惑，所以我希望这里的人可以在我问建筑师这些同样的问题之前提供一些建议（这样我可以与他们进行有见地的讨论）。 如果下面的内容过长，我深表歉意，我只想在问我的问题之前，先对系统的外观有一个很好的了解：) 设置系统的方式是，我们有一个主要的Web应用程序（asp.net，AngularJS），该应用程序主要只是聚合来自其他各种服务的数据。因此，基本上，它是AngularJS应用程序的宿主。实际上，有一个MVC控制器引导客户端，然后每个其他控制器都是WebAPI控制器。 这些控制器处理来自客户端的调用，这些控制器始终部署到仅托管Web应用程序的主机上。我们目前有4个这样的盒子。 但是，这些调用最终会路由到另一组WebAPI应用程序（通常是每个业务领域，例如安全性，客户数据，产品数据等）。所有这些WebAPI也会一起部署到专用盒中。我们也有四个这样的盒子。 除了一个例外，我们组织的任何其他部门均未使用这些WebAPI。 最后，这些WebAPI对“后端”服务进行了另一组调用，这些服务通常是遗留在各种ERP系统和数据存储（我们无法控制）之上的传统asmx或wcf服务。 我们应用程序的大多数业务逻辑都在这些WebApi中，例如转换旧数据，对其进行汇总，执行业务规则以及通常的事情类型。 我感到困惑的是，在WebApplication和为其提供服务的WebAPI之间进行这样的分离可能带来什么好处。由于没有其他人在使用它们，因此我看不到任何可伸缩性的好处（即，再放入4个API盒来处理增加的负载是没有意义的，因为API服务器上的负载增加必然意味着Web服务器上的负载增加-因此，Web服务器与Api服务器的比例必须为1：1） 我也看不到必须进行额外的HTTP调用的任何好处浏览器=> HTTP => WebApp => HTTP => WebAPI => HTTP =>后端服务。（我的问题是WebApp和WebAPI之间的HTTP调用） 因此，我目前正在寻求将当前的WebAPI从单独的解决方案迁移到WebApplication解决方案中的单独项目，并在它们之间使用简单的项目引用，并使用一个部署模型。因此，它们最终将成为类库。 在部署方面，这意味着我们将有8个“全栈” Web框，而不是4 + 4。 我看到的新方法的好处是 性能提高，因为Web应用程序和WebAPI服务器之间的序列化/反序列化周期减少了 在Web应用程序和WebApi服务器的传出和传入边界上，根据DTO和映射器可以删除（即无需维护/测试）的大量代码。 具有更好的能力来创建有意义的自动集成测试，因为我可以简单地模拟后端服务并避免中间层HTTP跳转带来的混乱。 所以问题是：我错了吗？我是否错过了将WebApplication和WebAPI框分开的一些基本“魔术”？ 我研究了一些N-Tier架构材料，但似乎找不到任何可以为我们的情况带来具体好处的东西（因为据我所知，可伸缩性不是问题，这是一个内部应用程序，因此WebAPI应用程序的安全性不是问题。） 而且，如果我将系统重组为建议的设置，那么在收益方面我将损失什么？