我应该为此使用队列吗？
我正在开发一个处理“敏感”数据（又名信用卡号）的应用程序，为了实现 PCI 合规性，我们需要确保我们的数据库与公共服务器分开。
为了让数据进入并存储，中间需要有一些东西 - 我不想直接从网络/应用程序服务器写入或读取数据 - 所以我想知道队列/工作人员是否架构可能是合适的。
基本流程是：
- 来自客户端的数据 ->发送到 API
- API 服务器将数据放入“请求”对象 -> Enqueue
- Worker（在“内部”网络上）接收请求，写入数据库，工作，更新数据库，然后将“响应”对象排队
- API 服务器接收此响应对象，然后将响应发送回客户端
本质上我希望有一些东西数据将返回到相同的“请求”，因此整个过程可以在单个请求中完成，但这似乎违背了消息队列的异步性质，并且可能更适合充当“Web服务”严格的“协议”本身...
编辑我可能应该补充一点，我需要以下内容：
- 耐用性 - 如果队列或任何“崩溃”，它应该能够恢复“排队”项目
- 安全性 -敏感数据需要受到保护 - 传输没问题，因为我们可以在传输层上使用某些东西（TLS、SSL、IPSec），但是在发送方（公共网络）存储卡号并不理想......
- 速度 - 的课程。
那么，我是否以错误的方式处理这个问题？
I am working on an application which is dealing with 'sensitive' data (aka Credit Card numbers), and in order to attain PCI Compliance we need to ensure that our database is separate from our public servers.
In order to have the data come in and be stored there needs to be something in the middle - I don't want to have the data being written or read directly from the web/app servers - so I was wondering if a queue/worker architecture might be suitable.
The basic flow would be:
- Data from Client -> Send to API
- API Server puts data into 'request' object -> Enqueue
- Worker (on 'internal' network) picks up request, writes to DB, does work, updates DB, then enqueues a 'response' object
- API Server receives this response object then sends back to response to client
Essentially I am hoping for something where the data will come back to the same 'request' so the whole process can be done in a single request, but this seems to be going against the Asynchronous nature of Message Queues, and might be more suited to a 'web service' acting as a strict 'protocol' per se...
Edit I should proabably add that I require the following:
- Durability - if the queue or whatever 'crashes' it should be able to recover 'queued' items
- Security - the sensitive data needs to be protected - transport is fine, because we can use something on the transport layer (TLS, SSL, IPSec), however storing card numbers on the sender side (public network) is not ideal...
- Speed - of course.
So, am I going about this the wrong way?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
虽然我不能说您应该，但听起来您确实可以使用其中一个来达到良好的效果。
队列将为您提供组件之间一定程度的隔离。如果这是通过认证的必要物理要求，那么您可以证明两台机器通过特定网络连接，并且仅打开特定端口等。
耐用性是队列软件的常见功能，传输级安全性也类似。
速度是一个比较模糊的问题。一般来说，队列系统中的消息，无论是商业的还是开源的（更不用说自己动手了）只需几毫秒的时间即可以持久性等方式传输 - 为加密增加了一些额外的开销。假设您的消息粒度正确（即它们不是“太小”并且协议不是“太闲聊”），那么您应该做得很好。
有许多商业和开源消息和队列系统，谷歌是您找到它们的朋友。
一种左翼替代方案是使用现代的类似 REST 的架构。最好的充实示例之一是 DayTrader
祝你好运
While I cannot say that you should, it certainly sounds like you could use one to good effect.
A queue will give you a level of isolation between components. If that is a necessary physical requirement to pass your certification, you can then show that the two machines are connected through a specific network, and only particular ports are open, etc.
Durability is a common feature of queue software, and transport level security similarly.
Speed is a fuzzier concern. In general, messages in a queue system, either commercial or open source (leaving alone roll-your-own) take mere milliseconds to transmit with durability and the like - add a bit of extra overhead for encryption. Assuming a correct granularity of your messages (i.e. they are not "too small" and the protocol not "too chatty") then you should do just fine.
There are many commercial and open-source message and queue systems, google is your friend to find them.
One left-field alternative would be to use a modern REST-like architecture. One of the best fleshed-out examples is DayTrader
Good Luck
我可能误解了这个问题，但归结起来，我认为你可能想得太多了。有多种方法可以将 Web 应用程序服务器暴露到互联网，同时保持数据库在防火墙后面的安全，使用某种 SOA 可以增加这种隔离，并有望减少某种 sql 注入攻击的可能性，但事实并非如此自动的。引入队列，可以配置为持久的，给你想要的恢复，有的可以配置为同步的，这样就满足了“一步操作”，或者至少是伪一步操作。但事实是，持久性增加了另一个“安全漏洞”，因为队列中的信息被写入某个地方，通常是数据库或文件系统，直到提交事务。因此，在您假设的发生崩溃的情况下，是的，它是可以恢复的，但企业内部有权访问临时存储该信息的文件系统区域的人员可能会查看它。
I might be misunderstanding the question, but to boil it down, I think you might be overthinking the issue. There are ways to expose a web application server to the internet, while keeping the database safe behind the firewall, using some sort of SOA can increase that isolation, and hopefully decrease the possibility of some sort of sql injection attack, but it isn't automatic. Introducing a queue, which can be configured to be durable, giving you the recovery you desire, and some can be configured to be synchronous, so that would meet the "One step", or at least psuedo one step operation. But the fact of the matter is, that durability add another "security vulnerability" as that info in the queue is written somewhere, usually either a database or file system, until the transaction is committed. So in your posited situation where there is a crash, yes its recoverable but it could possibly be viewed by someone inside the enterprise with access to the file system area where that information is temporarily stored.