|
精华帖 (0) :: 良好帖 (0) :: 新手帖 (0) :: 隐藏帖 (0)
|
|
|---|---|
| 作者 | 正文 |
|
最后更新时间：2008-08-07
rq2_79 写道 原来不是给你们出过文档吗？
johnyq 写道 项目的大体架构是这样的：
服务段采用的是 java ，客户端采用的是c++。 以前的和客户端通讯采用的是webservice（AIXS），客户端（100+）和中心端的通讯很频繁，但是客户端的机器配置客户要求普通PC机(1G的内存)即可胜任 我们测试下来发现webservice的通讯对性能的影响很大，达不到原来的设计要求，java进程在每次通讯后基本看不到有明显回收的迹象，因此想把webservice去掉，改为http的通讯方式，即以字符串的拼接来完成数据。但是这样有一个问题，原来的服务端的很多返回数据都以如下格式组织的
public class User {
private String name ;
private String password ;
private int age;
private String sex ;
private boolean status ;
private ArrayList list ;
private UserInfo info ;
private byte[] photo ;
如果以字符串的方式返回，就势必使我们很多的地方要做大的修改，业务逻辑也会有大的拆分。 于是我想到了JSON，能够很好的使用原有的接口和返回对象，不过客户端那边似乎没有很好的JSON的C++的类库扩展， 解析起来很是麻烦。 不知道大家有什么好的建议？ 有吗？偶不知道呢。。 呵呵 你屁股拍拍跑路，我们擦PP。擦的好辛苦呢。。。 听说你在宁波回不来了？ 哈哈 莫非宁波也是个“你去了就不想走的地方。。。” |
| 返回顶楼 | |
|
最后更新时间：2008-08-08
johnyq 写道 rq2_79 写道 原来不是给你们出过文档吗？
johnyq 写道 项目的大体架构是这样的：不知道大家有什么好的建议？
有吗？偶不知道呢。。 呵呵 你屁股拍拍跑路，我们擦PP。擦的好辛苦呢。。。 听说你在宁波回不来了？ 哈哈 莫非宁波也是个“你去了就不想走的地方。。。” 哈哈，英雄穷路，挥泪之际，再见指引者；惺惺相惜，却不乏嗔怪！ 实际上我觉得用hessian挺好的；对你的系统改动不会太大。 我保留了一个文本，是javaeye某个主题的，你可以看看这个数据 Hessian serialize 1000000 users with hessian spend 7 seconds, total size:100000000 数据到了百量级别，区别更明显！ |
| 返回顶楼 | |
|
最后更新时间：2008-08-08
推荐使用hessian，即使改用xml，依赖需要服务两端的解析、封装操作，效率也提升不了多少。
|
| 返回顶楼 | |
|
最后更新时间：2008-08-08
我在尝试使用hessian的时候遇到了一个问题
我的service接口如下 public int getResult(); public User getUser(); User对象如下：
ublic class User {
private String name ;
private String password ;
private int age;
private String sex ;
private boolean status ;
private UserInfo info ;
测试代码如下： IBasic basic = (IBasic)factory.create(IBasic.class, url); System.out.println(basic.getUser().getName()); 当我输出的是result的时候，能够得到结果，但是输出User对象就会报如下异常： Exception in thread "main" com.caucho.hessian.client.HessianRuntimeException: com.caucho.hessian.io.HessianProtocolException: expected integer at 0x63 at com.caucho.hessian.client.HessianProxy.invoke(HessianProxy.java:232) at $Proxy0.getUserInfo(Unknown Source) at com.hessian.HessianTest.main(HessianTest.java:16) Caused by: com.caucho.hessian.io.HessianProtocolException: expected integer at 0x63 at com.caucho.hessian.io.Hessian2Input.error(Hessian2Input.java:2705) at com.caucho.hessian.io.Hessian2Input.expect(Hessian2Input.java:2686) at com.caucho.hessian.io.Hessian2Input.readInt(Hessian2Input.java:845) at com.caucho.hessian.io.Hessian2Input.readObjectDefinition(Hessian2Input.java:2024) at com.caucho.hessian.io.Hessian2Input.readObject(Hessian2Input.java:1674) at com.caucho.hessian.client.HessianProxy.invoke(HessianProxy.java:220) ... 2 more 我google了一把，把hessian的版本由3.1.6换成3.0.20就OK了。 我的开发环境是 jdk6.0 tomcat6.0 请问这个是本身的BUG还是有什么限制？ |
| 返回顶楼 | |
|
最后更新时间：2008-08-09
试试xfire啊，也许效率就不成问题了。
|
| 返回顶楼 | |
|
最后更新时间：2008-08-11
内在这么便宜,加内存不就完了.
|
| 返回顶楼 | |
|
最后更新时间：2008-08-12
islandoo 写道 试试xfire啊，也许效率就不成问题了。
xfire也是webservice，没有根本区别。。。 |
| 返回顶楼 | |
|
最后更新时间：2008-08-13
想到几个问题：
1.使用HTTP做数据传输是不是会存在不稳定的情况，我指报文丢失。 2.使用HTTP传输怎么提供事务支持，比如事物跨越多次传输，然后客户端回滚，服务器这头保持一致就很困难。 3.大的传输报文序列/反序列化会很耗时的。我想可以考虑验证些lib，看看哪个性能最好，不过这也是治标不治本的事。我看根本还是如何能有效从业务/设计层面上拆封消息。但是一旦拆封，那样会影响整个架构（你提的问题域内）就成有状态的了，如果使用了cluster就会影响横向扩展，不过好在可以配置session保持策略，用f5就方便了。 另外想问下，tuxedo支持负载均衡不？ |
| 返回顶楼 | |
|
最后更新时间：2008-08-13
加内存。
产品不一定满足所有的需求，满足主要客户的需要就行了。连个内存都不能加的客户是你们的主要服务对象么？ 完美主义需要付出代价的，不过有必要么？ |
| 返回顶楼 | |
|
最后更新时间：2008-08-17
lzy.je 写道 想到几个问题：
1.使用HTTP做数据传输是不是会存在不稳定的情况，我指报文丢失。 2.使用HTTP传输怎么提供事务支持，比如事物跨越多次传输，然后客户端回滚，服务器这头保持一致就很困难。 3.大的传输报文序列/反序列化会很耗时的。我想可以考虑验证些lib，看看哪个性能最好，不过这也是治标不治本的事。我看根本还是如何能有效从业务/设计层面上拆封消息。但是一旦拆封，那样会影响整个架构（你提的问题域内）就成有状态的了，如果使用了cluster就会影响横向扩展，不过好在可以配置session保持策略，用f5就方便了。 另外想问下，tuxedo支持负载均衡不？ 对于1，不知道楼主使用的是什么可靠性机制，还是利用了所谓规范中指定的标签？ 我做的时候分传输部分，容器和应用交互两部分的可靠性来分析，自己做可靠性安全机制。传输部分的可靠性主要是三次握手的应用层实现了 对于2，这个挺难的，或许ejb能做到，但是楼主说的是http，当时我用webservice的时候，是利用回滚也发送报文，从而达到分布式事务一致的模拟 |
| 返回顶楼 | |
