关于WebService 在网络不稳定的情况下使用方法讨论

[无语孩童]

各位兄弟姐妹。

我现有一个WebService，里面的方法逻辑比较复杂，一般运行需要3-4秒钟。
现在客户网络定测试偶尔有丢包的情况，现出现一个奇葩情况，客户端可以成功调用WebService，方法也执行成功（我的方法有记录日志的功能），客户端在调用WebService时，返回结果丢失了，引发客户端的程序报错。

不知道在程序上有什么好的解决办法？？？？

[shoppo0505]

timeout的时间放长一点试试。 或者提高webservice的效率

[以专业开发人员为伍]

你可以首先定义一个规则，凡是在服务器端运行超过5秒的，都不要把问题推卸到客户端，这一定是服务器端效率太低；凡是返回内容超过2M的（或者你可以适当加大一点点），也不要吧问题推卸到客户端，这是服务接口协议设计问题，应该分块（页）处理数据。 刨除这些问题，再来重现所谓“不稳定问题”的这种说法，看看还能不能重现？！如果能重现，那么就应该放弃你们的所谓“WebService”方式，而改为更加轻量更加简单的方式，例如直接使用 http post 原始形式上传下载自定义数据，不要用过度封装的那些方式。

[以专业开发人员为伍]

关于“返回”，要注意这些返回跟服务器端耗时到底有多大关系？！！ 初学者可能使用一个简单的同步“函数式”思维方式，以为服务器做完了所有处理、什么都不干的时候才返回（输出）函数结果。 实际上真正实用的大系统不是这样设计的。比如说你在阿里的大系统上下个订单，后边有上百个工序，但是人家可能几十毫秒就返回了，只做必要的一点事情（例如安全审核、接受订单）就返回了，瞬间就返回了，后边的上百个工序都是异步处理的。因此 3-4 秒的操作实际上往往是几十毫秒就可以给前端反馈主要查询“部分”信息了，不让那些本可以异步的信息去 hang 住前端。 假设真的要取得一个需要耗时很长时间的结果，那么等后台异步已经产生了前端订阅的快报结果之后才去通知前端来“取”结果，而并不是前端始终死等结果。

[以专业开发人员为伍]

基本上，如果你说“我现有一个WebService，一般运行需要3-4秒钟”，假设你这个服务是面对越来越多并发客户端而设计的，那么这应该就算是一个很不好的服务了。应该调整思维方式，定一个不超过1秒钟的“规矩”，不管“里面的方法逻辑有多么复杂，哪怕要运行3-5分钟”，让客户端平均访问这个服务的等待时间在一秒钟以下。

[无语孩童]

引用 2 楼 sp1234 的回复:

你可以首先定义一个规则，凡是在服务器端运行超过5秒的，都不要把问题推卸到客户端，这一定是服务器端效率太低；凡是返回内容超过2M的（或者你可以适当加大一点点），也不要吧问题推卸到客户端，这是服务接口协议设计问题，应该分块（页）处理数据。 刨除这些问题，再来重现所谓“不稳定问题”的这种说法，看看还能不能重现？！如果能重现，那么就应该放弃你们的所谓“WebService”方式，而改为更加轻量更加简单的方式，例如直接使用 http post 原始形式上传下载自定义数据，不要用过度封装的那些方式。

我使用过一个WebService的简单方法测试，代码逻辑就是判断数据是否存在，不存在插入数据，存在给出文本提示。 也出现过我上诉的问题。 我现在的处理办法是，WebService的方法全部采用线程，主方法直接返回文本“调用成功”。现在不知道到底执行结果是什么了！！！

[武江伟]

这个问题解决了？我这也出现了这类似情况。