PHP：如何在两个服务器之间进行最佳通信
我正在为一个复杂的业务解决方案编写规范；它基本上是一组都在自己的服务器上的网络应用程序。我希望他们能够独立，这样如果其中一个人遇到问题或变得非常忙碌，那么其他人就不会受到影响。
将有一个中央服务器充当应用程序的支付网关，并向应用程序本身提供数据。数据很少；用户 ID、他们是否为该应用程序付费等。我们
的想法是，当购买应用程序时，我们只需将该数据传递给相关应用程序即可。
问题是如何在等待应用服务器响应时不影响用户体验的同时做到这一点。这个想法是将其输入队列并在 cron 作业上一一处理它们。然而，有人担心这速度不够快，用户可能必须等待才能访问该应用程序。
另一个想法是，当用户尝试使用应用程序时，应用程序只会联系主服务器。然后，主服务器可以批准用户，这将保存在应用程序服务器数据库中，因此不必再次检查。
对于这些想法，大家有什么看法呢？有明显最好的方法吗？
该系统应该能够扩展到 100 多个应用程序以及每小时数万个应用程序购买。
非常有兴趣看看大家的想法！非常感谢
I am writing the spec for a complex business solution; it is basically a set of web apps that are all on their own servers. I want them to be independant so if one has a problem or becomes very busy then the rest are not affected.
There will be a central server that will act as the payment gateway for the apps as well as providing data to the apps themselves. The data is minimal; user ids, have they paid for that app etc.
The idea was that when an app was purchased then we'd just pass that data to the app in question.
The question is how to do this while not holding up the user's experience while we wait for the app server to resoned. The idea was to enter it into a queue and process them one by one on a cron job. However there are concerns that this will not be fast enough and the user could have to wait before accessing the app.
The other idea is that the app just contacts the main server when the user tries to use it. The main server can then approve the user and this will be kept on the app server DB so it doesn't have to check again.
What do you all think about these ideas? Is there an obviously best way of doing it?
The system should be able to scale to 100+ apps and tens of thousands of app purchases an hour.
Very interested to see what you all think! Many thanks
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
我在这里有类似但略有不同的情况，支持潜在的竞争对手......我疯了吗？哈哈
说到正题，我们一般使用 cURL 来连接服务器请求，特别是如果我们不希望信息被公开，我们有一个特定的 VPS 设置用于支付处理、帐户功能和财务功能，这将发布到集中式mySQL 数据库仅用于访问信息，因此它将支持多个服务器集群上的多个应用程序的单点登录。
为了确保用户立即转移到他们想要的应用程序并且它正常工作，我们使用 cURL 发布初始数据，在特定应用程序数据库中创建默认记录，然后我们设置一个 PHP 标头重定向，用于将用户转移到应用程序请求单点登录已经作为之前执行的 cURL 帖子的一部分。
访问密钥对我们很重要，因为它可以确保单点登录的安全。每个帐户都会生成 1 次，并且永远不会更新，即使在发生安全违规时我们可以更新。然后，我们在用户身份验证过程中使用 cURL，以确保用户仍然使用其密钥和用户 ID 登录。该密钥实际上从未公开传递，但始终使用 cURL 方法将其隐藏在 PHP 中发布到服务器端。
我希望这有帮助。
I have a similar but slightly different situation here, supporting a potential competitor... have I gone mad?? haha
To the topic, we use cURL to connect the server requests generally, especially if we don't want information to be public, we have a specific VPS set up for payment handling, account functions and financial functions, this will post to a centralized mySQL database for access information only so it will support a single sign on for multiple apps on multiple server clusters.
To ensure the user is immediately moved to the app they want and it works correctly, we use cURL to post initial data creating the default records in the specific app database, we then set up a PHP header redirect using to move the user to the app requested with the single sign-in already working as part of the cURL post preformed earlier.
An access key is important to us as it enables the single sign-on to be secure. It is generated 1 time per account and never updated even though we can if there is ever a security violation. We then use cURL in the user auth process to ensure the user is still signed in using their key and user id. The key is never actually passed publicly but always posted server side using a cURL method hiding it in the PHP.
I hope this helps.