在决定为公共网站使用 3T 或 2T 架构之前，是否有任何标准应该知道/考虑，以避免在这里出现任何混淆，我将 Tier 称为独立的物理服务器，而 Web 浏览器确实 不算作一个等级，所以说 3T：
这里的2T仅指Web服务器和DB，业务仍然是分开的，但在运行Web服务器的同一个进程中执行。
有人可能会说 3T 更具可扩展性。如果我们是垂直思考，那是真的，但我们不会通过将更多 Web 服务器实例放在负载均衡器后面来实现水平可扩展性吗？是否有任何标准或备忘单应该知道，感谢专家对此的意见
如果stackoverflow不适用于这些类型的问题，我不知道还剩下什么？ int 交换？
【问题讨论】：
我发现这个博客讨论了我认为的某个产品，但我相信同样的原则 http://www.ektron.com/billcavablog/your-questions-answered-3tier-or-2tier/
作者列出了五个标准（属性）来帮助做出决定：
- 安全性 - 某些组织（例如金融机构）的网络策略规定前向网站无法直接与数据库通信。这些组织要求数据库位于前向网站无法访问的网络上。在这种情况下，需要 3 层架构，因为它满足此网络策略，因为前向前端网站仅与中间层通信，不了解任何数据库。
- 可扩展性 - 您可能正在开发一个需要能够处理季节性流量高峰的营销网站。为了满足这个要求，您可能需要在短时间内扩展可用的前端机器的数量。由于前端的 Ektron 占用空间非常小（无需安装 Ektron，DLL 很少，没有工作区），因此水平扩展非常简单。例如，使用 Amazon EC3，您可以通过启动前端的新机器实例轻松地进行水平扩展。
- 性能 - 为了最大限度地减少 3 层架构中前端和中间层服务器之间的干扰，Ektron 提供了一个位于框架 API 下方并驻留在前端的缓存层。该层处理其数据的透明存储、检索和过期。从技术上讲，此缓存层也可用于 2 层架构 - 但在使用 3 层时尤其需要牢记这一点，因为它可以最大限度地减少对中间层的网络请求并提高性能。
- 可用性 - 如果您对正常运行时间有特别高的要求，您可以考虑使用 3 层，因为它能够从前端内存提供缓存数据，即使在中间层或数据库不可用的情况下也是如此。
- 互操作性 - 使用 3 层打开了在交付层上使用任何 Web 应用程序框架的可能性，例如 ASP.NET Web 窗体（Web 应用程序）、Web 窗体（网站），甚至 ASP.NET MVC。任何可以与 WCF 服务层（Java 等）通信的前端应用程序也可以使用该服务层。
【讨论】：
stackoverflow 上有类似的问题：Addressing scalability ,performance in a .net web application。 为了实现可扩展性，大多数答案都指向 DONT go for 3T。默认情况下考虑两层，除非出现除可扩展性之外的其他因素。
【讨论】：