我应该为这个...使用队列吗？

Question

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

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

的基本流程是：

1. 从客户端数据 - >发送到API
2. API服务器将数据放入 '请求' 的对象 - >入队
3. 工（对 '内部' 网络）拿起请求，写入数据库，没有工作，更新数据库，然后排入一个“响应”对象
4. API服务器接收到这个响应对象，然后发送回响应客户

本质上，我希望数据会回到相同的'请求'，因此整个过程可以在一个请求中完成，但这似乎违背了消息队列的异步性质，可能更多适合于“Web服务”作为一个严格的“协议”本身......

编辑我应该proabably补充一点，我需要以下：

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

那么，我该怎么处理这个错误的方法呢？

Answer 1

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

队列会给你一个组件之间的隔离级别。如果这是通过认证的必要物理要求，则可以显示两台机器通过特定网络连接，并且只有特定端口是开放的等。

耐用性是排队软件的一个常见功能，并且运输级别的安全性同样。

速度是一个模糊的问题。一般来说，队列系统中的消息（无论是商业还是开放源代码）都需要几毫秒的时间才能通过持久性等进行传输 - 为加密增加了额外的开销。假设消息的粒度是正确的（即它们不是“太小”而协议不是“太琐碎”），那么你应该做的很好。

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

一个左边的替代方案是使用现代的类REST架构。其中一个最好的完整的示例是DayTrader

好运

Answer 2

我可能会被误解的问题，而是要熬下来，我想你可能会在得太多问题。有一些方法可以将Web应用程序服务器公开到Internet上，同时使数据库在防火墙后面保持安全，使用某种SOA可以增加隔离度，并有望减少某种SQL注入攻击的可能性，但它不是自动。引入一个可配置为持久的队列，为您提供所需的恢复，一些可配置为同步，以便符合“一步”或至少一步操作。但事实是，持久性会增加另一个“安全漏洞”，因为队列中的信息是写入某处的，通常是数据库或文件系统，直到事务提交。因此，在您发生崩溃的情况下，可以恢复，但可能会被企业内部的人员访问临时存储该信息的文件系统区域。