多服务器不同WebSocket 链接间怎么相互通信呢？

[???518]

现在想实现多服务器、多客服、多用户的的Web在线客服功能，并实现消息的服务器主动推送。Web客户端 用flash socket（因为要兼容不支持Html5的浏览器，c# 的WebSocket 需要浏览器Html5的支持才能实现） 和 WebSocket 实现，客服端用WebSocket 实现。

现在的问题是，如果客户和客服不是连接的同一台服务器，客户的Socket消息怎么推送给客服呢？就是 客户是通过WebSocket 和服务器保持链接，客服也是通过WebSocket 和服务器保持链接，但这两个链接可能不在一台服务器上，怎么让客户和客服间传递消息呢？

一点头绪没有现在。有牛人能给点思路么？谢谢！

[以专业开发人员为伍]

具体给你个（伪）代码式的简单说明吧。 假设你有一个 Master 服务器，在上海。假设另外有5个应用服务器，也在上海；2个应用服务器，在昆明；1个应用服务器（并且从外网无法访问，在某个NAT路由器和防火墙之后），在新疆乌鲁木齐。现在，一个上海的用户账号a要发送一个信息给用户b，那么a所已经连接好会话通道的上海的一台应用服务器向Master发送了这样一个指令（随便举例） { s: 2342882306, t: "发消息", d: { t: "757423189", myhtml: "<span style=color:red>嗨！</span>在么？"; } } 这个消息给了Master之后，Master会询问几个Worker“谁能完成这个任务？”，比如说2个位于上海的一个服器分别返回了false，而那个位于新疆乌鲁木齐的服务器是第3个有响应的，并且返回了true，那么这个Worker就获取到了这个任务，去做了任务。其它的Worker服务器就捞不到这个任务去做了（不管是返回false，还是响应较慢，或者干脆就“坏了”，都不做这个任务）。 如果Master超时还没有收到Worker的回应，或者全都返回false，那么次任务路由失败。 这种功能框架写上几十行代码足以，关键是要自己去写，或者就像有些公司那样到互联上拼命找各种开源系统。关键是先要有这个框架的意思（如果只知道临时去分解需求，那么没有框架平台意识，就对这种几十行的小系统永远都觉得陌生）。

[???518]

sp1234 说的是！其实我做系统好多年了，但主要是web的，这种分布式的系统，没怎么搞过，现在需要恶补。 我先研究分布式的服务，再去找方案。能给几个需要研究的重要的点么？这样看的时候着重注意下。

引用 4 楼 sp1234 的回复:

任何一个实际的业务系统集群（哪怕只有2台负责接入业务的应用服务器）都是需要设计服务器端的分布式任务管理系统的（哪怕只写100行代码）。你可以找一个做过服务系统的公司实习一下。 我看到许多很想做点事业的人只是以为只要知道点“单个服务器知识就够了”，这往往决定了他们的软件能力的天花板。其实从1个服务器到2个服务器（数据库服务器不算），是个“质变”的阶段，这是一个服务系统开发人员从业余走向专业的必经之路。虽然可能最少只写100行代码就能实现一个非常稳定、较好效率的分布式服务系统了，但是这是需要“观念”的概念。而观念比技术难10倍。

[以专业开发人员为伍]

当然对于有上万台Worker服务器的系统，例如腾讯的系统，那是需要优化的情形。它可能会把 Worker分成3层（而不是1层），也可能采取“先查询出 757423189 所在的服务器，然后 Master 只向目标用户所在的（1台或者多台）服务器发询问的方式来优化。但是这只是一些后话，没有框架理念就没有后话。

[???518]

嗯，我再研究下，至少现在有个方向了。看来与我的知识结构需要大量的扩充。谢谢！

引用 5 楼 Z65443344 的回复:

引用 3 楼 wangzhe_518 的回复:

客户端<---->服务器<---->服务器<---->客服 是这样的结构，服务器间怎么通信呢？ [quote=引用 1 楼 wangzhe_518 的回复:] 或者在线客服还有什么高效率的实现方案么？主要是要实现多服务器间推送消息，而不是用AJAX 轮询等低效率的方式去获取新的消息:)

客户机和服务器怎么通信,服务器之间就也怎么通信 所谓客户端还是服务端,都是相对而言的 你完全可以在自己的软件里同时实现[/quote]

[???518]

感谢sp1234 !正在研究分布式编程，刚开始搞，可能需要一个熟悉的过程。但方向有了就好说了。

引用 7 楼 sp1234 的回复:

有了基本的分布式系统的基础知识，有了框架，那么这种功能的设计就可以“一点就透”了。分布式任务发布不外乎两种形式：一种是在集群中只要有一个服务器执行那么其它服务器就不再去执行的形式，另外一种是可以让所有的（能执行的）服务器都执行一下的方式。并且任何任务都可以指定自己在什么服务器（节点id）上执行。 而这个功能，可以采取第一种方式，指定“凡是目标用户会话id所连接的服务器才推送信息”，那么就只有一台机器做这个事情。或者也可以先从统一的会话系统上查询到目标用户会话id所在的服务器id，然后发一个“只有目标服务器id才能执行”的任务给集群。

[???518]

你说的这个给了我一个思路，我刚开始想的是,客户链接负载服务器，客服只链接到主服务器，消息通过主服务器中转，但这样看来我想的不对。 应该是客户负载服务器建立链接通知主服务器， 主服务器告诉哪个客服去链接哪个负载服务器，然后 客服和负载服务器建立链接，这样就可以通过WebSocket双向通信。

引用 7 楼 sp1234 的回复:

有了基本的分布式系统的基础知识，有了框架，那么这种功能的设计就可以“一点就透”了。分布式任务发布不外乎两种形式：一种是在集群中只要有一个服务器执行那么其它服务器就不再去执行的形式，另外一种是可以让所有的（能执行的）服务器都执行一下的方式。并且任何任务都可以指定自己在什么服务器（节点id）上执行。 而这个功能，可以采取第一种方式，指定“凡是目标用户会话id所连接的服务器才推送信息”，那么就只有一台机器做这个事情。或者也可以先从统一的会话系统上查询到目标用户会话id所在的服务器id，然后发一个“只有目标服务器id才能执行”的任务给集群。

[以专业开发人员为伍]

不管客户端client与应用服务器Worker之间使用什么方式连接（例如websocket、http1.1等），但是服务器联邦之间一定是稳定、高效、双向的长连接形式的。服务器联邦内，其实也就相当于一个S/C结构的网络。上面举的“乌鲁木齐的服务器”的例子也许比较刻意（它说明有些服务器放在较远地区的加盟商的房间里，而且可能被主管部门严格控制在局域网内）。一般来说，一开始集群里的所有服务器都是放在同一个局域网里边的。 说几点这类系统的低级的（与业务无关的）常见扩展功能： 这往往需要收集各个服务器上的本地文件系统保存的一些信息，例如日志信息，然后产生一个汇总之后发给某个主机保存在数据库里，或者在界面上展示（收到的报告）。 当然许多网络在 Master 服务器垮掉之后，各个 Worker 系统会相互联系，然后所有可以连在一起的Worker之间重新动态地选择一个Worker升级为临时的Master。这在集群规模不大时可以不考虑（因为完全可以人工对Master进行切换）。 如果需要更新服务器系统，你可以先给1/3的机器发送一个“批处理指令”（把要执行的批处理文件发布给指定的一批机器），于是那1/3的机器就会执行批处理去“下载文件、重启机器、安装服务、重启服务”。等你看到那1/3机器的状态都基本上更新好了，你可以再去另外1/3的服务器去进行“系统热升级”。 当然你可以干任何分布式计算的事情。例如一个用户进入了某个群之后，你可能需要决策“（根据多条规则判断）是否需要在群里广播欢迎信息”，甚至你可能根据此信息的提示即时重计算此群的用户画像。而这类功能（用户的每一个动作都可能触发上百个这类操作）就不应该占用接入此用户会话的那个服务器的CPU资源，而应该随机地找其它更加空闲的机器来做计算。

[???518]

好的，这些扩展的方案是应该有的,具体实现的用到的技术点或者框架我还要去看。多谢sp1234！

引用 14 楼 sp1234 的回复:

不管客户端client与应用服务器Worker之间使用什么方式连接（例如websocket、http1.1等），但是服务器联邦之间一定是稳定、高效、双向的长连接形式的。服务器联邦内，其实也就相当于一个S/C结构的网络。上面举的“乌鲁木齐的服务器”的例子也许比较刻意（它说明有些服务器放在较远地区的加盟商的房间里，而且可能被主管部门严格控制在局域网内）。一般来说，一开始集群里的所有服务器都是放在同一个局域网里边的。 说几点这类系统的低级的（与业务无关的）常见扩展功能： 这往往需要收集各个服务器上的本地文件系统保存的一些信息，例如日志信息，然后产生一个汇总之后发给某个主机保存在数据库里，或者在界面上展示（收到的报告）。 当然许多网络在 Master 服务器垮掉之后，各个 Worker 系统会相互联系，然后所有可以连在一起的Worker之间重新动态地选择一个Worker升级为临时的Master。这在集群规模不大时可以不考虑（因为完全可以人工对Master进行切换）。 如果需要更新服务器系统，你可以先给1/3的机器发送一个“批处理指令”（把要执行的批处理文件发布给指定的一批机器），于是那1/3的机器就会执行批处理去“下载文件、重启机器、安装服务、重启服务”。等你看到那1/3机器的状态都基本上更新好了，你可以再去另外1/3的服务器去进行“系统热升级”。 当然你可以干任何分布式计算的事情。例如一个用户进入了某个群之后，你可能需要决策“（根据多条规则判断）是否需要在群里广播欢迎信息”，甚至你可能根据此信息的提示即时重计算此群的用户画像。而这类功能（用户的每一个动作都可能触发上百个这类操作）就不应该占用接入此用户会话的那个服务器的CPU资源，而应该随机地找其它更加空闲的机器来做计算。

[IE11下面经常卡到爆]

你这个其实就ESB（Enterprise Service Bus）要解决的事，.Net下也有开源的框架和商业框架(MS的Biztalk ) 不过，MS的东西一向不便宜，中小企业基本不用考虑，只能用用开源的，或者根据自己理解去开发一个轻量级的

[???518]

恩，我这个并发应该不会很大，最多几十万，所以用开源的或者自己开发就可以的。

引用 17 楼 dongxinxi 的回复:

你这个其实就ESB（Enterprise Service Bus）要解决的事，.Net下也有开源的框架和商业框架(MS的Biztalk ) 不过，MS的东西一向不便宜，中小企业基本不用考虑，只能用用开源的，或者根据自己理解去开发一个轻量级的

[???518]

或者在线客服还有什么高效率的实现方案么？主要是要实现多服务器间推送消息，而不是用AJAX 轮询等低效率的方式去获取新的消息:)

[Poopaye]

客户端<---->服务器<---->客服 这样的结构吗？ 两两之间都能双向通讯，可以直接推送，不需要轮询

[???518]

客户端<---->服务器<---->服务器<---->客服 是这样的结构，服务器间怎么通信呢？

引用 1 楼 wangzhe_518 的回复:

或者在线客服还有什么高效率的实现方案么？主要是要实现多服务器间推送消息，而不是用AJAX 轮询等低效率的方式去获取新的消息:)

[越过越咸]

引用 18 楼 wangzhe_518 的回复:

恩，我这个并发应该不会很大，最多几十万，所以用开源的或者自己开发就可以的。 [quote=引用 17 楼 dongxinxi 的回复:] 你这个其实就ESB（Enterprise Service Bus）要解决的事，.Net下也有开源的框架和商业框架(MS的Biztalk ) 不过，MS的东西一向不便宜，中小企业基本不用考虑，只能用用开源的，或者根据自己理解去开发一个轻量级的

[/quote] 几十万的并发，也蛮大了！，没处理关相关的应用，希望楼主早日攻克难关！

[showjim]

楼主需要的是一个网络通讯框架，可以试试fastCSharp的TCP调用。

[???518]

好的，我看下。谢谢！

引用 18 楼 wangzhe_518 的回复:

恩，我这个并发应该不会很大，最多几十万，所以用开源的或者自己开发就可以的。 [quote=引用 17 楼 dongxinxi 的回复:] 你这个其实就ESB（Enterprise Service Bus）要解决的事，.Net下也有开源的框架和商业框架(MS的Biztalk ) 不过，MS的东西一向不便宜，中小企业基本不用考虑，只能用用开源的，或者根据自己理解去开发一个轻量级的

[/quote]

[???518]

恩，所以要多服务器。谢关注！

引用 20 楼 raokaichuan 的回复:

[quote=引用 18 楼 wangzhe_518 的回复:] 恩，我这个并发应该不会很大，最多几十万，所以用开源的或者自己开发就可以的。 [quote=引用 17 楼 dongxinxi 的回复:] 你这个其实就ESB（Enterprise Service Bus）要解决的事，.Net下也有开源的框架和商业框架(MS的Biztalk ) 不过，MS的东西一向不便宜，中小企业基本不用考虑，只能用用开源的，或者根据自己理解去开发一个轻量级的

[/quote] 几十万的并发，也蛮大了！，没处理关相关的应用，希望楼主早日攻克难关！[/quote]

[偶像-阿里巴巴-马云]

客户机和服务器怎么通信,服务器之间就也怎么通信

[S1ow]

开源分布式框架就可以了

[小竹z]

引用 15 楼 wangzhe_518 的回复:

好的，这些扩展的方案是应该有的,具体实现的用到的技术点或者框架我还要去看。多谢sp1234！ [quote=引用 14 楼 sp1234 的回复:] 不管客户端client与应用服务器Worker之间使用什么方式连接（例如websocket、http1.1等），但是服务器联邦之间一定是稳定、高效、双向的长连接形式的。服务器联邦内，其实也就相当于一个S/C结构的网络。上面举的“乌鲁木齐的服务器”的例子也许比较刻意（它说明有些服务器放在较远地区的加盟商的房间里，而且可能被主管部门严格控制在局域网内）。一般来说，一开始集群里的所有服务器都是放在同一个局域网里边的。 说几点这类系统的低级的（与业务无关的）常见扩展功能： 这往往需要收集各个服务器上的本地文件系统保存的一些信息，例如日志信息，然后产生一个汇总之后发给某个主机保存在数据库里，或者在界面上展示（收到的报告）。 当然许多网络在 Master 服务器垮掉之后，各个 Worker 系统会相互联系，然后所有可以连在一起的Worker之间重新动态地选择一个Worker升级为临时的Master。这在集群规模不大时可以不考虑（因为完全可以人工对Master进行切换）。 如果需要更新服务器系统，你可以先给1/3的机器发送一个“批处理指令”（把要执行的批处理文件发布给指定的一批机器），于是那1/3的机器就会执行批处理去“下载文件、重启机器、安装服务、重启服务”。等你看到那1/3机器的状态都基本上更新好了，你可以再去另外1/3的服务器去进行“系统热升级”。 当然你可以干任何分布式计算的事情。例如一个用户进入了某个群之后，你可能需要决策“（根据多条规则判断）是否需要在群里广播欢迎信息”，甚至你可能根据此信息的提示即时重计算此群的用户画像。而这类功能（用户的每一个动作都可能触发上百个这类操作）就不应该占用接入此用户会话的那个服务器的CPU资源，而应该随机地找其它更加空闲的机器来做计算。

[/quote] 只有一个Master服务器转发消息，会不会成为系统瓶颈？假设并发量10万，即一秒之内有10万个消息需要通过Master转发，Master能搞定，如果不能即时处理势必会带来消息的延时。