我应该为此使用队列......？

Question

我正在处理一个处理“敏感”数据（即信用卡号码）的应用程序，为了达到PCI合规性，我们需要确保我们的数据库与公共服务器分开。

为了让数据进入并存储，中间需要有一些东西 - 我不希望直接从Web / app服务器上写入或读取数据 - 所以我想知道是否有队列/工作者架构可能是合适的。

基本流程是：

1. 来自客户的数据 - ＆gt;发送给API
2. API服务器将数据放入“请求”对象 - ＆gt;入队
3. 工作人员（在'内部'网络上）接收请求，写入数据库，确实有效，更新数据库，然后将“响应”对象排入队列
4. API Server收到此响应对象，然后发送回客户端

基本上我希望数据将返回到同一个'请求'，这样整个过程就可以在一个请求中完成，但这似乎违背了消息队列的异步性质，可能是更适合作为严格“协议”本身的'网络服务'......

编辑我应该可以补充一点，我需要以下内容：

• 持久性 - 如果队列或其他任何“崩溃”它应该能够恢复“排队”项目
• 安全性 - 需要保护敏感数据 - 传输很好，因为我们可以在传输层（TLS，SSL，IPSec）上使用某些东西，但是在发送方（公共网络）上存储卡号并不理想。 ..
• 速度 - 当然。

那么，我是否采取了错误的方式？

Answer 1

虽然我不能说你应该，但肯定听起来你可以使用一个效果良好。

队列将为您提供组件之间的隔离级别。如果这是通过认证的必要物理要求，则可以显示两台计算机通过特定网络连接，并且只打开特定端口等。

持久性是队列软件的常见功能，同样也是传输级安全性。

速度是一个模糊的关注点。一般来说，队列系统中的消息，无论是商业消息还是开源消息（单独使用自己的卷）只需要几毫秒的时间来传输，具有持久性等等 - 为加密添加一些额外的开销。假设你的消息的粒度正确（即它们不是“太小”而协议不是“太唠叨”）那么你应该做得很好。

有许多商业和开源消息和队列系统，谷歌是你的朋友找到它们。

一个左场替代方案是使用类似现代REST的架构。最好的充实示例之一是DayTrader

祝你好运

Answer 2

我可能会误解这个问题，但是为了把它弄清楚，我想你可能会过度思考这个问题。有一些方法可以将Web应用程序服务器暴露给Internet，同时保持数据库安全在防火墙后面，使用某种SOA可以增加隔离，并希望减少某种sql注入攻击的可能性，但它不是自动。引入一个队列，可以配置为持久，为您提供所需的恢复，有些可以配置为同步，这样就可以满足“一步”或至少一步操作。但事实是，持久性增加了另一个“安全漏洞”，因为队列中的信息被写入某处，通常是数据库或文件系统，直到事务被提交。因此，在您发现崩溃的情况下，是可以恢复的，但企业内部的某个人可以查看该文件系统区域，该文件系统区域可以临时存储该信息。