从物理上分离安全和非安全 Web 请求
我们一直在研究如何将 Web 应用程序的安全部分和非安全部分物理隔离为两个应用程序。 所有“http”请求将由一台服务器（或集群）提供服务，所有“https”请求将由另一台服务器（或集群）提供服务。
我们研究这个问题的部分原因是为了应用程序的生存能力。 由于应用程序的安全部分是创收的，因此我们可以拥有更大和/或更强大的集群来服务请求。 相反，当我们升级安全应用程序中的硬件时，它可以重新用于服务非安全站点 - 基本上延长服务器的寿命。
有人使用过这种方法吗？ 去年，我们向一家（知名）供应商发出了 RFP 进行架构评估，这是推荐的可能路径之一。 虽然我看到了潜在的好处，但我担心诸如维护、部署、版本控制等问题。
We have been doing some research into physically isolating the secure and non-secure sections of our web application into two applications. All "http" requests would be served by one server (or cluster) and all "https" requests would be served by another server (or cluster).
The reason that we are looking into this is partially for the survivability of the application. Since the secure section of the application is revenue generating we could, for example, have a larger and/or more powerful cluster to serve the requests. Conversely, when we upgrade the hardware in the secure application, it could be re-purposed to serve the non-secure site - basically extending the life of the servers.
Has anyone worked with this approach? We had an RFP out to a (well known) vendor last year for an architectural assessment and this was one of the possible paths that was recommended. While I see the potential upside, I worry about things such as maintenance, deployment, version control, etc.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
根据您的应用程序的架构方式，在我看来，如果您使用虚拟化/负载平衡，您可以获得保证资源和付费区域隔离的相同优势，同时还能够动态爆发资源以应对负载峰值任一区域。 您当前的提案允许您保证资源并确定其优先级，但可能会导致其中一些资源闲置。
另外，通过配置管理负载会更容易，因为这将是一个纯粹的部署问题和一个完全独立的问题。 您还可以更加独立于硬件升级路径，因为您只需向新硬件添加/分配虚拟机。
Depending how your app is architected, it seems to me that if you used virtualisation / load balancing you could have the same benefits of guaranteed resources and isolation for the paid area, while also being able to dynamically burst resources to deal with spikes in load in either area. Your current proposal allows you to guarantee and prioritise resources, but it may result in some of them being idle.
Plus it would be easier to manage load through configuration, as it would then be a pure deployment issue and an entirely separate concern. You'd also be more independent of your hardware upgrade path as you'd just be adding/assigning virtual machines to the new hardware.