首页
下载
文档
社区
视频
捐赠
源代码
赞助商
AOT 编译器
AI 助理
商业产品
PHP AOT 原生编译器
Swoole-Compiler 代码加密器
CRMEB 新零售社交电商系统
登录
注册
全部
提问
分享
讨论
建议
公告
开发框架
CodeGalaxy
发表新帖
为什么不只把swoole当作socket服务器用？
最近想做个socket服务器,看了下文档和论坛 , 不知道为什么看起来好像大伙都是把业务逻辑写到socket里面 还没具体实现我要做的东西，只是画了个图 不过。。这论坛居然不能传图片。。 大致流程如此 用户-> lvs -> socket 服务器层 -> 队列层(任务队列) -> 任务处理层 -> 队列层(结果队列) -> 转发层 -> socket 服务器层 -> 用户 socket服务器层只需要保证稳定的长连接即可 业务逻辑让后面处理不就好了？ 把业务逻辑写到socket server的task中跑。这种强耦合,后期完全没办法维护的吧
发布于9年前 · 0 次浏览 · 来自
提问
I
IT人士
最近想做个socket服务器,看了下文档和论坛 , 不知道为什么看起来好像大伙都是把业务逻辑写到socket里面 还没具体实现我要做的东西，只是画了个图 不过。。这论坛居然不能传图片。。 大致流程如此 用户-> lvs -> socket 服务器层 -> 队列层(任务队列) -> 任务处理层 -> 队列层(结果队列) -> 转发层 -> socket 服务器层 -> 用户 socket服务器层只需要保证稳定的长连接即可 业务逻辑让后面处理不就好了？ 把业务逻辑写到socket server的task中跑。这种强耦合,后期完全没办法维护的吧
赞
0
收藏
提问
分享
讨论
建议
公告
开发框架
CodeGalaxy
登录
后参与评论
评论
2017-05-31
V
Victor
你的思路是对的，从架构层面全部使用socket通信是非常好的选择。`task`功能设计之初并不是为了执行业务逻辑。实际上`task`是为了辅助Swoole的异步Worker完成一些`慢速的`的代码。如 foreach大循环、广播、必须要阻塞的任务等等。但在实际的服务器程序场景中，`Task`承担了更多的责任，比如使用Task做为任务分配、Task实现Redis代理存储功能、Task实现应用程序内的`Map-Reduce` 如你所说业务逻辑处理使用消息队列构造生产者消费者模型是很好的方案。一个`GateW
赞
0
回复