我正在构建基础架构以支持我们打算扩展到数十万用户的游戏平台。由于这是在娱乐/游戏行业，我们期望每个用户会话负担很重，因此，性能至关重要。
我们正在尝试尽可能多地并行化架构，这意味着API，数据库和应用程序可以在不同的服务器上运行，这些服务器可以横向扩展。其中一个应用程序是一个Web应用程序，由于特定方案涉及旧版浏览器上的相同原始策略，我们遇到的问题最多。
在Web浏览器中运行的此应用程序需要快速访问仅通过集中式API提供的模型。虽然这对我们专用的移动客户端非常有用，但遗憾的是浏览器需要完全支持CORS才能直接与我们的API接口。这是有问题的，因为所有浏览器都不支持某些HTTP谓词（put / delete）。我们唯一已知的解决方法是，重写API以创建更多抽象（我们认为这不是最佳实践并且会增加开发时间和潜在性能）并且仅使用POST使用JSONP或创建代理（这将增加额外的两条腿）旅行和延迟性能加倍）。
最重要的是，我们已经将这个问题归结为......这些是唯一的两个选项，还是我们还没有考虑其他问题，如果是这样的话，哪些解决方案更适合游戏平台。
答案 0 :(得分：0)
另一个需要考虑的选择是JSONP。通过包装JSON响应以使其能够作为脚本标记加载，您可以避免使用相同的源策略出现问题。
如果不详细了解应用，我无法谈论您的特定应用的性能问题。我认为你会在使用JSONP的服务器上看到类似的性能，因为你与其他方法的主要区别在于你要连接一个额外的字符串。
答案 1 :(得分：0)
SOP应该不是问题。将JSONP用于跨域请求。在回调方法中包含答案不应该是服务器端部件的问题，并且对于应用程序的其余部分应该是透明的。不会破坏REST风格。在客户端库中，JSONP的使用对于应用程序的其余部分也应该是透明的 那么，关于PUT和DELETE的内容是什么？只需执行POST并使用预期的方法设置X-HTTP-Method-Override标头。服务器端的webservice处理程序应识别标头，并使用标头中的方法暗示请求。对应用程序的其余部分都是透明的。
答案 2 :(得分：0)
虽然JSONP肯定有“普遍”的支持 - 它仍然有点hacky并且有一些负面的副作用：主要是你无法捕获错误。
JSONP无处不在的原因是因为脚本标记发出的请求属于“简单请求”的范围，如CORS规范所定义。
我的观点？您也可以修改您的API（或至少是最常访问的部分），而不是使用JSONP，以适应简单请求的范围。然后，您就可以完全处理错误，而不会产生任何预检请求对性能的影响。
对于必须使用预检请求的地方，您可以缓存预检响应。
我在Two Strategies for Crossing Origins with Performance in Mind
对这项技术进行了全面的记录