我正在构建一个将部署到4节点Web场的ASP.NET Web应用程序。
我的网络应用程序的服务器场位于加利福尼亚州。
我计划使用从纽约数据中心提供的一组Web服务,而不是用于后端数据的数据库。
我有一个页面/show-web-service-result.aspx,其工作原理如下:
1)用户请求页面/show-web-service-result.aspx?s=foo
2)Page's codebehind查询由纽约第三方托管的网络服务。
3)当Web服务返回时,返回的数据将被格式化并在页面响应中显示给用户。
此架构是否存在潜在的可扩展性问题?假设我每秒获得数百次独特的点击,例如
/show-web-service-result.aspx?s=foo1
/show-web-service-result.aspx?s=foo2
/show-web-service-result.aspx?s=foo3
等...
服务器场中的Web服务器是否通常使用Web服务来代替数据库?任何个人经历?
我应该对架构做出哪些改变以提高可扩展性?
答案 0 :(得分:4)
我没有看到这种方法有问题,我们在工作的地方使用了很多。但是,有些事情需要考虑:
在等待Web服务响应时,您的页面呈现是否会被阻止? 如果响应永远不会到来,即服务停止怎么办?
对于第一个问题,我将在您从Web服务获得响应后使用AJAX更新页面。您还需要考虑如何处理无响应或超时条件。
最后,您应该考虑如何在本地缓存Web服务数据。例如,如果您正在调用股票报价服务,那么除非您有实时订阅源,否则没有理由在您获得的每个请求中调用Web服务。将数据本地存储一段时间并将其返回,直到它变得陈旧。
答案 1 :(得分:4)
您肯定存在可扩展性问题:第三方Web服务。除非您与该服务签订了服务级别协议(同意您每秒可以提交的请求数量),否则您可能会使用预期的负载超载该服务。你自己有四个节点对你没有帮助。
所以你应该a)与第三方达成协议,b)测试他们可以承担的实际负荷。
此外,您需要确保您的框架可以使用并行连接来访问远程服务。假设您从加利福尼亚到纽约的往返时间为20毫秒(相当不错),您不能通过单个TCP连接发出超过50个请求。同样,为每个请求启动新的TCP连接也会破坏性能,因此您需要在这些并行连接上进行池化。
答案 2 :(得分:2)
您可能存在可扩展性问题,但大多数问题都可以仔细设计。
我建议您使用ASP.NET的异步任务,以便Web服务排队,在请求等待Web服务响应时释放线程,然后在Web服务完成时另一个线程启动请求。
MSDN Magazine - Wicked Code - Asynchronous Pages in ASP.NET 2.0
本地缓存是绝对必须的。从加利福尼亚到纽约的次数越少越好。您可能希望查看Microsoft的Velocity(尽管仍在CTP中)或NCache或其他分布式缓存,这样您的4个Web服务器中的每一个都不必从Web服务中生成和缓存相同的数据 - 一旦一个服务器得到它,它应该对所有人都可用。
你应该设计的其他可能出错的事情:
答案 3 :(得分:1)
时髦的答案是REST。任何GET请求都可以是HTTP响应缓存(有很多关于如何配置的选项),它将由互联网本身(您的ISP,本质上)缓存。
答案 4 :(得分:1)
您的项目有一个体系结构,反映了Microsoft和SOA世界中许多其他人想要带我们的方向。也就是说,许多人试图避免Web服务引入的这种类型的实时风险。
您的系统将以高效的方式对Web服务产生巨大的依赖。如果它不起作用或缓慢,人们只会看到您的页面无法正常工作。
至少,我会得到一个网络压力工具和性能测试您的网络服务至少达到您期望达到峰值的流量水平,并且可能超出此范围。它什么时候打破(如果有的话?),什么时候开始减速?这些都是很好的指标。
要查看的其他选项:也许您可以将每日批量数据从Web服务获取到本地数据库并访问您网站的数据库。然后,如果由于某种原因Web服务出现故障或变慢,您可以使用最近获得的数据(如果这对您的数据可行)。
总体而言,它应该是可行的,但您希望了解并衡量风险,并探索任何可能的选择,以尽量减少这些风险。
答案 5 :(得分:0)
没关系。存在一些可伸缩性问题。主要是,允许您每秒调用外部Web服务的次数。某些网络服务(例如雅虎购物)会限制您拨打服务的频率,如果您经常拨打电话,则会锁定您的帐户。如果您有一个大型农场和大量流量,您可能需要限制您的请求。
此外,在这些情况下,通常会使用插页式页面,该插页式页面会分离工作线程以进行Web服务调用,并在调用返回时重定向到结果页面。 (当您进行搜索时,请考虑旅行网站,当他们呼叫外部来源获取航班数据时,您会获得一个插页式页面,然后在呼叫完成时重定向到结果页面)。如果您的Web服务调用快速返回,则可能不需要这样做。
答案 6 :(得分:0)
我建议您确定使用WCF,而不是传统的ASMX Web服务技术作为客户端。使用“添加服务引用”而不是“添加Web引用”。
答案 7 :(得分:0)
您需要考虑的另一个问题,取决于您正在下拉的应用程序类型和/或数据:安全性。
具体来说,我指的是您的最终用户和Web应用程序本身的身份验证和授权。这些东西在哪里处理?所有在网络应用程序? WS?或者也许前端应用程序正在验证用户,并将用户的身份传递给后端WS,以便验证用户是否被允许?你怎么验证这个?由于这里的许多其他响应者都提到了前端应用程序上的本地数据缓存(一个优秀的想法,BTW),这变得更加复杂:你是否缓存了允许用户A的数据,而不是缓存用户B的数据?如果是这样,您如何验证userB无法访问缓存中的数据?如果WS检查授权怎么办,那么如何缓存权限呢?
另一方面,您如何验证只允许您的Web应用程序访问WS(例如,攻击者不会通过Internet直接访问您的WS数据)?就此而言,您如何确保您的Web应用程序与CORRECT WS服务器联系,而不是虚假的WS服务器?当然,我假设与WS的所有连接都只通过TLS / SSL ...(但当然也以编程方式验证证书是否适用于所访问的服务器......)
简而言之,它的复杂性和许多因素需要考虑......但它并非不可克服。
(就输入验证而言,实际上 NOT 是一个问题,因为这应该由 BOTH 前端应用和后端WS完成...... )
正如@Martin所提到的,这里的另一个方面是,您需要为NY WS提供任何提供商/托管服务的SLA,不仅仅是为了提高性能,还要提供可用性。即如果服务器无法访问它会如何快速恢复它会发生什么,如果它长时间停机会发生什么情况等等。这是合法地转移您的可用性的风险的唯一方法由外部性控制。