扩展 ASP.NET 应用程序
这是一个非常广泛的问题，但希望我能得到有用的提示。目前我有一个在单个服务器上运行的 ASP.NET 应用程序。我现在需要进行扩展以适应不断增加的客户负载。所以我的计划是：
1) 将 ASP.NET 和 Web 组件扩展到五台服务器上。
2) 将数据库移至场中。
我不认为数据库会出现问题，因为就应用程序而言，它只是一个 IP 地址。然而，我现在担心 ASP.NET 和 Web 层。我已经担心的一些问题：
最简单的模型是否是仅实现一个负载均衡器，该负载均衡器将以循环方式将请求分派给五台服务器中的每一个？
既然每次发出请求时，HTTPS 和 SSL 连接都可以在不同的物理服务器上终止，那么它们是否存在任何问题？ （例如，性能？）
对于通过 cookie 进行会话维护（登录）是否有任何担忧？我的猜测是否定的，但无法完全解释为什么...;-)
会话数据本身（存储的服务器端）是否有任何问题？显然，我需要在服务器之间复制会话状态，或者以某种方式强制请求仅发送到单个服务器。不管怎样，我在这里看到一个问题...
This is a very broad question, but hopefully I can get useful tips. Currently I have an ASP.NET application that runs on a single server. I now need to scale out to accommodate increasing customer loads. So my plan is to:
1) Scale out the ASP.NET and web component onto five servers.
2) Move the database onto a farm.
I don't believe I will have an issue with the database, as it's just a single IP address as far as the application is concerned. However, I am now concerns about the ASP.NET and web tier. Some issues I am already worried about:
Is the easiest model to implement just a load balancer that will farm out requests to each of the five servers in a round-robin fashion?
Is there any problem with HTTPS and SSL connections, now that they can terminate on different physical servers each time a request is made? (for example, performance?)
Is there any concern with regards to session maintanence (logon) via cookies? My guess is no, but can't quite explain why... ;-)
Is there any concern with session data itself (stored server side)? Obviously I will need to replicate session state between servers, or somehow force a request to only go to a single server. Either way, I see a problem here...
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（5）
正如 David 所指出的，这个问题的大部分实际上更多的是管理问题，并且可能对 ServerFault 有用。他发布的链接有很好的信息值得仔细研究。
对于您的
Session问题：您需要查看会话状态服务（作为 IIS 附带的独立服务，用于维护多个服务器之间的公共状态）和/或存储 asp.net 会话状态在 SQL 数据库中。我确信，您可以在 David Stratton 的链接中找到这两个选项。很大程度上来说，一旦设置了进程外会话状态，它就变得透明了。不过，它确实要求您在 Session 中存储可序列化对象。
是的，循环 DNS 是这种情况下最简单的负载平衡方法。它没有考虑每台服务器的实际负载，也没有规定一台服务器何时可能停机维护；任何获得该特定 IP 的人都会看到该站点“已关闭”，即使其他四台服务器可能正在运行。
负载平衡和处理 SSL 连接可能都受益于反向代理类型的情况；代理处理所有传入的连接，但它所做的只是加密和平衡 Web 服务器的实际请求负载。 （当然，这些问题更多地出现在管理端，但是……）
只要所有 Web 服务器都将自己宣传为同一网站（通过主机标头等），Cookie 就不会成为问题。每个服务器都会很乐意接受使用相同域名的任何其他服务器设置的cookie，而不知道或关心哪个服务器发送它；它基于 Web 浏览器获取 cookie 值时所连接的服务器的主机名。
As David notes, much of this question is really more of an Administrative thing, and may be useful on ServerFault. The link he posts has good info to pore over.
For your
Sessionquestions: You will want to look at either the Session State Service (comes with IIS as a separate service that maintains the state in common between multiple servers) and/or storing asp.net session state in a SQL database. Both are options you can find at David Stratton's link, I'm sure.Largely speaking, once you set up your out-of-process session state, it is otherwise transparent. It does require that you store
Serializableobjects in Session, though.Round-Robin DNS is the simplest way to load-balance in this situation, yes. It does not take into account the actual load on each server, and also does not have any provision for when one server may be down for maintenance; anyone who got that particular IP would see the site as being 'down', even though four other servers may be running.
Load balancing and handling SSL connections might both benefit from a reverse proxy type of situation; where the proxy handles all the connections coming in, but all it's doing is encryption and balancing the actual request load to the web servers. (these issues are more on the Administration end, of course, but...)
Cookies will not be a problem provided all the web servers are advertising themselves as being the same web site (via the host headers, etc). Each server will gladly accept the cookies set by any other server using the same domain name, without knowing or caring what server sent it; It's based on the host name of the server the web browser is connecting to when it gets a cookie value.
这是一个相当广泛的问题，在这样的论坛上很难得到完整的回答。我什至不确定这个问题是否属于这里，或者是否应该在 serverfault.com 上。然而......
微软在这个主题上提供了大量的指导。 BING 的“缩放 asp.net 应用程序”的第一个结果就是这样。
http://msdn.microsoft.com/en-us/magazine/cc500561.aspx
That's a pretty broad question and hard to answer fully in a forum such as this. I'm not even sure if the question belongs here, or if it should be at serverfault.com. However....
Microsoft offers plenty of guidance on the subject. The first result for "scaling asp.net applications" from BING comes up to this.
http://msdn.microsoft.com/en-us/magazine/cc500561.aspx
我只是想提出您应该关注数据库的方面。
首先，大多数仅考虑单个数据库服务器而构建的数据模型需要进行大量更改才能支持多主机模式下的数据库场。
如果您对主键使用自动递增整数（大多数人都会这样做），那么您基本上就被淘汰了。有几种方法可以暂时缓解这种情况，但即使是这些方法也需要大量的猜测，并且很有可能发生冲突。一种缓解措施是将每台服务器上的种子值设置为足够高的数字，以减少冲突的可能性……这通常会暂时起作用。
当然，您必须弄清楚如何跨服务器对用户进行分区...
我的观点是，这个领域不应该被轻易忽视，而且几乎总是比简单地通过放置数据库服务器来“扩展”它更难实现。更大的硬件。
如果您故意构建具有多主机角色的数据模型，请忽略。 ;)
关于会话：不要相信“粘性”会话，粘性并不能保证。坦率地说，我们的东西通常部署到服务器场，因此我们从一开始就完全禁用会话状态。一旦迁移到场，几乎没有理由使用会话状态，因为必须在每次页面加载时从状态服务器检索数据、反序列化、序列化并存储回状态服务器。
考虑到数据库和网络流量，以及他们的目的是减少数据库和网络流量，那么您就会明白他们如何不再向您购买任何东西。
I just want to bring up areas you should be concerned about with the database.
First off, most data models built with only a single database server in mind require massive changes in order to support a database farm in a multimaster mode.
If you used auto incrementing integers for your primary keys (which most people do) then you're basically screwed out of the gate. There are a couple ways to temporarily mitigate this but even those are going to require a lot of guesswork and have a high potential of collision. One mitigation involves setting the seed value on each server to a sufficiently high number to reduce the likelihood of a collision... This will usually work, for awhile.
Of course you have to figure out how to partition users across servers...
My point is that this area shouldn't be brushed off lightly and is almost always more difficult to accomplish than simply scaling "up" the database server by putting it on bigger hardware.
If you purposely built the data model with a multi-master role in mind then kindly ignore. ;)
Regarding sessions: Don't trust "sticky" sessions, sticky is not a guarantee. Quite frankly, our stuff is usually deployed to server farms so we completely disable session state from the get go. Once you move to a farm there is almost no reason to use session state as the data has to be retrieved from the state server, deserialized, serialized, and stored back to the state server on every single page load.
Considering the DB and network traffic from just and that their purpose was to reduce db and network traffic then you'll understand how they don't buy you anything anymore.
我看到了一些与循环 http/https 会话相关的问题。我们过去常常在进程中使用会话，并告诉负载均衡器使会话保持粘性。 （我认为他们为此使用了cookie）。
它让我们避免了 SQL 会话，但这意味着当我们从 http 切换到 https 时，我们的 F5 框无法保持粘性。我们最终更改为 SQL 会话。
您可以研究将加密推送到负载均衡器。我记得这是解决我们问题的一种可能的解决方案，但可惜的是，我们没有研究过。
I have seen some issues related to round robin http/https sessions. We used to use in process sessions and told the load balancers to make the sessions sticky. (I think they use a cookie for this).
It let us avoid SQL sessions but meant that when we switched from http to https, our F5 boxes couldn't keep the stickiness. We ended up changing to SQL sessions.
You could investigate pushing the encryption up to the load balancer. I remember that was a possible solution for our problem, but alas, not one we investigated.
SQL 服务器上的会话数据库可以轻松地横向扩展，只需很少的代码和操作。配置更改。您可以将 ASP.NET 会话粘贴到会话数据库，并且无论场中的哪个 Web 服务器负责处理请求，基于会话 ID 的 SQL 状态服务器映射都可以完美运行。这可能是使用 SQL Server 扩展 ASP.NET 会话状态的最佳方法之一。有关详细信息，请阅读链接 True Scaleout会话状态模型
The session database on an SQL server can be easily scaled out with little code & configuration changes. You can stick asp.net sessions to a session database and irrespective of which web server in your farm serves the request, your session-id based sql state server mapping works flawless. This is probably one of the best ways to scale out the ASP.NET Session state using SQL server. For more information, read the link True Scaleout model for session state