|
锁定老帖子 主题：内部系统间调用效率的讨论
精华帖 (0) :: 良好帖 (2) :: 新手帖 (0) :: 隐藏帖 (0)
|
|
|---|---|
| 作者 | 正文 |
|
发表时间：2012-08-22
我觉得想复杂了。能不能就简单通过http呢。不需要考虑队列，每个请求无状态。如果是内网，我并不认为http调用会很慢。
|
| 返回顶楼 | |
|
发表时间：2012-08-22
allwefantasy 写道 我觉得想复杂了。能不能就简单通过http呢。不需要考虑队列，每个请求无状态。如果是内网，我并不认为http调用会很慢。
你想得太简单了，再说，同一台服务器之间，你还通过http去互相访问，通过httpClient这类东西去请求，这么个折腾法效率不是一般的浪费。 同一台机器，你有必要按照互联网之间的通信方式来进行么？ |
| 返回顶楼 | |
|
发表时间：2012-08-22
瞬间是：某人一按按钮，另外一个地方的警报器就马上响起来，绝对不能漏接，绝对不能等待。
纳秒？毫秒？有指标吗。 |
| 返回顶楼 | |
|
发表时间：2012-08-22
vlinux 写道
偶不是大牛，不过跳出来吐槽下
统一调用平台，实际上你要做的是业务总线咯。用JMS的方式不是说不ok，但从执行效率来说绝对不是高效的。因为你的业务总线（也就是你的统一调用平台啦）是一个绝对的单点，这就意味着你的这个平台必须保证至少一组热备。另外由于是所有业务都接入，每个业务自身都有优先级，所以你的前置接口机必须根据业务优先级进行物理隔离，防止低级业务挤占高级业务的线程池。物理隔离还必须延伸到JMS，防止不同优先级的业务事件相互挤占。此外基于JMS的QoS你还很不好做。
还有JMS消息的重复投递、无序投递，服务的幂等被迫做得很细，如果业务上无法做幂等，你还得在技术上判重。 当JMS的Producer全部下线（server端故障）时，做为Consumer无法及时感知，无法立即返回业务方失败，只能活生生的等待超时。
看了下相关的源码，Profiler.java里面似乎是 Michael Zhou的神作啊。。。不过借鉴下倒无妨 |
| 返回顶楼 | |
|
发表时间：2012-08-22
liyebing 写道
vlinux 写道
偶不是大牛，不过跳出来吐槽下
统一调用平台，实际上你要做的是业务总线咯。用JMS的方式不是说不ok，但从执行效率来说绝对不是高效的。因为你的业务总线（也就是你的统一调用平台啦）是一个绝对的单点，这就意味着你的这个平台必须保证至少一组热备。另外由于是所有业务都接入，每个业务自身都有优先级，所以你的前置接口机必须根据业务优先级进行物理隔离，防止低级业务挤占高级业务的线程池。物理隔离还必须延伸到JMS，防止不同优先级的业务事件相互挤占。此外基于JMS的QoS你还很不好做。
还有JMS消息的重复投递、无序投递，服务的幂等被迫做得很细，如果业务上无法做幂等，你还得在技术上判重。 当JMS的Producer全部下线（server端故障）时，做为Consumer无法及时感知，无法立即返回业务方失败，只能活生生的等待超时。
看了下相关的源码，Profiler.java里面似乎是 Michael Zhou的神作啊。。。不过借鉴下倒无妨
慢慢深入的看代码。确实不错呢！！！加油！！很不错的实现 |
| 返回顶楼 | |
|
发表时间：2012-08-22
最后修改：2012-08-22
liyebing 写道
liyebing 写道
vlinux 写道
偶不是大牛，不过跳出来吐槽下
统一调用平台，实际上你要做的是业务总线咯。用JMS的方式不是说不ok，但从执行效率来说绝对不是高效的。因为你的业务总线（也就是你的统一调用平台啦）是一个绝对的单点，这就意味着你的这个平台必须保证至少一组热备。另外由于是所有业务都接入，每个业务自身都有优先级，所以你的前置接口机必须根据业务优先级进行物理隔离，防止低级业务挤占高级业务的线程池。物理隔离还必须延伸到JMS，防止不同优先级的业务事件相互挤占。此外基于JMS的QoS你还很不好做。
还有JMS消息的重复投递、无序投递，服务的幂等被迫做得很细，如果业务上无法做幂等，你还得在技术上判重。 当JMS的Producer全部下线（server端故障）时，做为Consumer无法及时感知，无法立即返回业务方失败，只能活生生的等待超时。
看了下相关的源码，Profiler.java里面似乎是 Michael Zhou的神作啊。。。不过借鉴下倒无妨
慢慢深入的看代码。确实不错呢！！！加油！！很不错的实现
那代码，是该好好调整下了，省得又被阿里的童鞋认出来 |
| 返回顶楼 | |
|
发表时间：2012-08-22
方世玉 写道 瞬间是：某人一按按钮，另外一个地方的警报器就马上响起来，绝对不能漏接，绝对不能等待。
纳秒？毫秒？有指标吗。 要求没那么精确，反应在五秒以内就是正常。 反应不是最关键的，我怕java端宕掉，但是C++端得不到结果不知道该怎么处理后续步骤； 更担心Java端的Socket Server出现大规模线程等待，导致C++新请求进不来。 |
| 返回顶楼 | |
|
发表时间：2012-08-22
你这个场景典型的用ICE啊，绝对的合适啊
|
| 返回顶楼 | |
|
发表时间：2012-08-23
youarestupid 写道
方世玉 写道
瞬间是：某人一按按钮，另外一个地方的警报器就马上响起来，绝对不能漏接，绝对不能等待。
纳秒？毫秒？有指标吗。 要求没那么精确，反应在五秒以内就是正常。 反应不是最关键的，我怕java端宕掉，但是C++端得不到结果不知道该怎么处理后续步骤； 更担心Java端的Socket Server出现大规模线程等待，导致C++新请求进不来。
5ms，折腾那么多做啥，socket，妥妥的。 |
| 返回顶楼 | |
|
发表时间：2012-08-23
allwefantasy 写道 我觉得想复杂了。能不能就简单通过http呢。不需要考虑队列，每个请求无状态。如果是内网，我并不认为http调用会很慢。
系统相互之间直接调用，连接就太多了 比如10个应用都要调用对方，结果需要100种连接，网络也不好保证啊 |
| 返回顶楼 | |
