3 层架构与 3 服务器架构
我正在构建一个传统的 .NET MVC 站点，因此我有一个自然的 3 层软件架构设置（以视图形式表示、控制器中的业务层、模型中的数据层和数据访问层）。
当我部署此类站点时，它通常位于一台服务器（网站和数据库所在的位置）或两台服务器（一台 Web 服务器和一台单独的数据库服务器）上。
如何构建 3 服务器架构（WEB、APP 和 DB）？ Web 服务器是否只有演示文稿（例如物理视图/aspx 页面），应用程序服务器将保存配置文件和 bin 文件夹，而数据库服务器将保持原样？
我的问题本质上是，您可以简单地将 /bin 和所有应用程序逻辑从演示文稿视图移到单独的服务器上吗？如果是这样，您如何配置服务器以知道在哪里查找？如果某处有一本好的入门书或者有人可以告诉我内幕，我将永远感激不已。
I'm building a traditional .NET MVC site, so I've got a natural 3-tier software architecture setup (presentation in the form of Views, business layer in the controller, and data layer in the models and data access layer).
When I've deployed such sites, it usually goes either on one server (where the web site and db live), or two servers (a web server and a separate db server).
How does one go about a 3-server architecture (WEB, APP, and DB)? Would the web server just have the presentation (e.g. the physical View/aspx pages), the app server would hold the config file and bin folder, and the db server would remain as is?
My question is essentially, can you simply move the /bin and all app logic onto a separate server from the presentation views? If so, how do you configure the servers to know where to look? If there's a good primer somewhere or someone can give me the lowdown, I'd be forever indebted.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（5）
MVC不是一个三层架构。并非每个解决方案都需要是 3 层或 n 层，但理解其中的区别仍然很重要。 MVC 恰好有 3 个主要元素，但这些元素并不以“分层”方式工作，它们是相互依赖的：
视图依赖于模型。控制器依赖于视图和模型。因此，这些多个依赖路径不充当层。
通常，3 层解决方案如下所示：
Presenter/Controller 在某种程度上是可选的 - 例如，在 Windows 窗体开发中，您通常看不到它，而是有一个“智能客户端”UI，这也没关系。
这是一种 3 层架构，因为 3 个主要层（数据、域、UI）中的每一层都只有一个依赖项。传统上，UI 取决于域模型（或“业务”模型），而域模型取决于 DAL。在更现代的实现中，域模型不依赖于 DAL；相反，这种关系是相反的，并且稍后使用 IoC 容器注入抽象映射层。无论哪种情况，每个层仅依赖于前一个层。
在 MVC 架构中，C 是控制器，V 是 UI（视图），M 是域模型。因此，MVC是一种表示架构，而不是一种系统架构。它不封装数据访问。它不一定完全封装领域模型，可以将其视为外部依赖项。它不是分层的。
如果您想要物理地分离各层，那么通常可以通过将域模型公开为 Web 服务（即 WCF）来完成。这为您提供了改进的可扩展性和更清晰的关注点分离 - 领域模型实际上可以在任何地方重用，并且可以部署在许多机器上 - 但需要大量的前期开发成本以及持续的维护成本。
服务器架构反映了上面的 3 层图：
“应用程序”是您的 MVC 应用程序，它与 Web 服务共享域模型（通过 SOAP 或 REST）。 Web 服务在专用服务器（或多个服务器）上运行，而数据库显然托管在其自己的服务器上。这是一个 3 层、3 服务器架构。
MVC is not a 3-tier architecture. Not every solution needs to be 3-tier or n-tier, but it is still important to understand the distinction. MVC happens to have 3 main elements, but those elements do not work in a "tiered" fashion, they are interdependent:
The View depends on the Model. The Controller depends on the View and Model. These multiple dependency paths therefore do not function as tiers.
Typically a 3-tier solution looks like:
Presenter/Controller is somewhat optional - in Windows Forms development, for example, you usually don't see it, instead you have a "smart client" UI, which is OK too.
This is a 3-tier architecture because each of the 3 main tiers (Data, Domain, UI) has only one dependency. Classically, the UI depends on the Domain Model (or "Business" model) and the Domain Model depends on the DAL. In more modern implementations, the Domain Model does not depend the DAL; instead, the relationship is inverted and an abstract Mapping layer is injected later on using an IoC container. In either case, each tier only depends on the previous tier.
In an MVC architecture, C is the Controller, V is the UI (Views), and M is the Domain Model. Therefore, MVC is a presentation architecture, not a system architecture. It does not encapsulate the data access. It may not necessarily fully encapsulate the Domain Model, which can be treated as an external dependency. It is not tiered.
If you wanted to physically separate the tiers then it is usually done by exposing the Domain Model as a Web Service (i.e. WCF). This gives you improved scalability and a cleaner separation of concerns - the Domain Model is literally reusable anywhere and can be deployed across many machines - but comes with a significant up-front development cost as well as an ongoing maintenance cost.
The server architecture mirrors the 3-tier diagram above:
The "Application" is your MVC application, which shares a Domain Model with the Web Services (through SOAP or REST). Web Services run on a dedicated server (or servers), and the database is, obviously, hosted on its own server. This is a 3-tier, 3-server architecture.
在某些圈子中，我看到这种讨论被表述为 n 层和 n 层之间的差异，其中在此上下文中的“层”可能代表另一台机器。为了让中间层使用这个定义，它必须被托管。例如，如果您有一个服务层，表示层调用该服务层来获取其数据，那么该服务层可能位于与表示层或数据库不同的计算机上。但是，该服务层作为 Windows 服务或 Web 服务托管。即，有一个进程正在侦听该机器上的请求。因此，您不能简单地将 bin 文件夹移动到不同的计算机并希望完成此操作。我会使用 WCF（Windows Communication Foundation）来创建这些类型的服务。
In some circles, I have seen this discussion phrased as the difference between n-tier and n-layer where a "layer" in this context potentially represents another machine. In order to have a middle layer using this definition, it must be hosted. For example, if you had a service layer which the presentation layer called to get its data, then the service layer could be on a different machine than the presentation or database. However, that service layer is hosted either as a windows service or as a web service. I.e., there is a process listening for requests on that machine. Thus, you cannot simply move the bin folder to different machine and hope to have this work. I would look at WCF (Windows Communication Foundation) for creating these types services.
ASP.NET MVC 不能帮助您设置 3 层系统。这实际上只是一个前端模式。
实施多层系统时必须解决的主要问题是将对象从一台服务器传输到另一台服务器。您必须找到一种根据传输通道序列化所有对象的方法。这会变得缓慢并且开发变得更加复杂。
拥有单独的应用程序服务器是有原因的：您可能有其他应用程序需要的逻辑，或者应用程序服务器可能具有与 Web 服务器不同的权限。但很难想象一个高流量的网站，所有请求都会调用远程应用程序 - 服务器。
ASP.NET MVC does not help you in setting up a 3tier system. This is realy only a frontend pattern.
The main issue you have to solve implementing a multi tier system is the transport of objects from one server to another. You have to find a way to serialize all objects depending on the transport channel. This gets slow and development gets more complicated.
There are reasons to have a separate app-server: You might have logic in it that other application need or the app-server might have different permissions than the Webserver. But its hard to imagine a high traffic website, where all requests lead to a call to a remote app - server.
下一个逻辑扩展将是两台 Web 服务器和一台数据库服务器。
最终，在添加许多 Web 服务器之后，可能值得添加一个服务层。
在扩展时，您可能还想在某个时候添加分布式缓存、会话状态服务器、电子邮件服务器和其他专用服务器。
Next logical scale up would be two web servers and one database server.
Eventually after adding many web servers it might be worth adding a service layer.
You might also want to add a distributed cache, session state server, email server, and other specialized servers at some point too as you scale.
所以你的问题似乎是......
“你可以简单地将 /bin 和所有应用程序逻辑从演示文稿视图移到单独的服务器上吗？”
如果我理解正确的话，我相信你的 bin 文件夹中的文件将是你的 asp.net 页面的编译后代码。如果是这样的话，不，我相信它们需要与 asp 页面位于同一台机器上。
如果您希望将业务逻辑放在与表示层不同的计算机上，则需要将该代码包装到一个单独的 dll 中，并通过soap或其他协议公开它。然后从其他服务器上调用这些 SOAP 公开的 dll表示层中的代码。
So your questions seems to be ...
"can you simply move the /bin and all app logic onto a separate server from the presentation views?"
If I am understanding correctly, I believe the files in your bin folder will be the compiled code behinds for your asp.net pages. If that is the case then, no, I believe they need to be on the same machine as the asp pages.
If you want to have your business logic on a seperate machine from the presentation layer you would need to wrap that code into a seperate dll and expose it via soap or some other protocol .. and then call those SOAP exposed dlls on the other server from the code in your presentation layer.