Web Services开发体会和项目教训

去年，在一个大型项目(1500w)中用到Web Services，现在项目进入了尾声，所以对以前的开发经历做一个总结。
我想大家一定会问？为什么你们项目中要用到Web Services，因为客户有如下需求：
1、客户要求项目用C/S架构，并且服务器端是IBM那一套：WebSphere AppServer＋DB2＋AIX5.3＋RS/6000。
2、最终用户上报数据，因为网络原因，譬如Modem上网，可以离线操作，等填写了几十张报表后，可以一次提交。同时，在登录时，可以将服务端数据同步到本地Access或MSSQL数据库，这样提高客户端响应速度。
3、由于有些报表以后可能需要修改，或添加一些新报表，又不想重新开发，这样客户那边工作人员可以通过客户端自定义。

如果有以上需求，我想大家应该都比较认同这种异构分布式解决方案：客户端用C# .Net开发，通过Web Services调用服务器端Java组件。

其实，上面的解决方案太过于理想，最后我们不得不面对残酷的现实：三种客户端中的两种最后被迫改为B/S。
在项目中，我主要负责Web Services和服务器端组件开发中所遇到的种种问题，相当于技术支持吧，以及部分模块的开发。

以下是我们开发中遇到的实际问题，虽然最终都一一解决，但遇到了几个无法突破的瓶颈：客户端不稳定，客户端响应迟缓，后期测试和维护困难巨大。

一、异构平台的Web Services兼容性
开发过程中，我们用Axis做Web Services引擎，Tomcat做容器。因为我们只有IBM提供的RAD6.0的60天试用版。该工具超级占内存，用内置的WebSphere开发测试极其缓慢，严重影响开发效率，经过我初期试用后，基本废弃了。推荐项目组二三十开发人员用Lomboz eclipse3.12开发，基本满意。

由于Axis是一个嵌入式引擎，所以可以将其打包到最终的WebSphere AppServer（WAS）上，也就是说，我们没有用到WAS提供的Web Services引擎，这引出了后面会谈到的一个问题：Web Services安全性怎么部署？

用Axis时，Axis一直都有一个bug或是说缺陷，官方文档也详细注明，只是我们当时没有发现而走了很多弯路：用Axis发布的Web Services给.net客户端调用时，必须用RPC风格，不能用Web Services标准的跨平台风格Document，而后者是Lomboz axis插件的默认方式。也就是说，我们发布的Web Services总是莫名其妙的不好用。我们用JBuilder2007自带的Axis插件发布，竟然非常顺利。

二、Web Services开发中服务器端组件问题
我们服务器端开发，是用Spring＋Hibernate，在Spring的Service层上再封装一层，也就是façade模式了，该façade直接发布为Web Services，必须经过这个转换，一是因为性能，二是因为Hibernate的复杂Model对象，在wsdl描述后，被.net客户端识别有些问题，List、Map也会有问题，总之这些对象太复杂了，我们包装成简单的VO对象。

另外一个问题是，我们的service方法，如果直接给WebWork这样的框架在服务端用的的话，是不会出问题，当提供给.net客户端用时，就会出现lazy loading的错误，因为.net客户端不能接收Proxy对象，必须将数据全部load出来，但这时Hibernate的session已经关闭。项目组很多人遇到这些问题，最后大家不约而同的全部用eager模式，导致了最后的恶果：严重的的性能问题。由于我不是leader，所以当时这个问题发现了，也没法要求别人，毕竟很大的一个团队。
切身体会：一个团队，如果不熟悉Hibernate就随便上，技术风险非常大。Hibernate带来的开发效率，是以团队成员掌握它为前提。

当然，性能问题不只是由Hibernate引起，Web Services本身的性能也非常严重：XML的序列化和反序列化耗时，XML文件的膨胀导致的网络传输，HTTP的无状态导致网络IO性能。切身体会：如果系统必须用分布式，而不是追求所谓的SOA架构，Web Services应该是下下策，因为还有很多协议和方式可以选择：IIOP、RMI、Hessian、burlap、RPC，另外，做系统集成还有Message方式。

Web Services开发中其它问题比较少，因为Web Services本身不用编程，只是部署的事情，开发工具和服务器会自动为我们做，我们只需要理解SOAP引擎的原理和使用就够了，真的遇到问题，可以通过Axis的TcpMonitor监视SOAP数据包。
开发过程中，.net客户端那边，VSStudio做得很智能，它会根据wsdl文件生成我们所要的一切，当然，wsdl文件的变化，会导致VSStudio重新生成所有的类和接口，也很耗时，并且容易出问题。

三、Web Services的安全问题
当时解决Web Services安全问题，花了我将近一个月的时间，主要是学习和处理如下四个问题：
XML和Web Services安全规范
WAS的 Web Services引擎的安全部署
Axis和参考的Xfire引擎的Web Services安全
.net客户端WSE3.0的安全以及和WAS的通讯

最后这些问题基本上都解决了，不过还是没有用上，因为在我们已经开发的几种客户端和服务器端部署上很麻烦，还要测试，另外，客户也没法验收这个啊。

当然，我们还回避了一个严肃的问题：我们的Web Services是发布在Axis引擎上，还没有移植到WAS的Web Services引擎，而发布在这个平台，必须有RAD这类开发工具支持，几乎没法手动做。WAS引擎的Web Services安全配置异常复杂：我们当时只配置了Authentication和Integration，没有做Encryption，但完全够用。我当时用Sun的NetBean开发工具发布了一下Web Serivces，也是挺好用的，不过没有配置安全。顺便说一下，Sun的web Services引擎jwsdp2.0设计有点类似于EJB容器，很不好用，移植性特差。
我们当时用Axis引擎是1.3版本，而该版并不支持标准的OASIS的WS-Security，只有到2.0版才开始，而且几乎都是手写配置文件。

WAS的Web Services安全配置，对照IBM的红皮书，不是很难，但很复杂，安全相关的xml代码都好几百行，好几个文件。配置过程中，和.net客户端通讯时遇到一个问题，怎么也不能互通，但.net和.net客户端可以互通，Java和Java客户端也可以互通,最后我通过拦截soap包,找到了解决办法: 必须手动更改http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-x509-token-profile-1.0#X509v3 后的v3，IBM工具生成的是v1，这是标准不兼容引起的，因为当时RAD是04年底,而微软的WSE3.0比较新。后来发现这篇文章有相似的经历：[url]http://pluralsight.com/blogs/kirillg/archive/2005/04/13/7315.aspx [/url]

在处理Web Services安全过程中，我通过emule和IBM网站下载了上10本这方面的书籍，我觉得以下资料对我帮助最大：

Axis的若干文档：Reference、developers-guide、architecture-guide等，非常详细
IBM的红皮书：《WebSphere Version 6 Web Services Handbook Development and Deployment.pdf》、《WebSphere Application Server V6 Security Handbook.pdf》，它专门讲述了Web Services安全的原理和具体配置，非常深入浅出。
《Securing Web Services with WS-Security》：这本书很理论化，但我认为非常好，虽然Amazon排行不高。
WSE3.0的MSDN文档。

四、开发过程中的的沟通问题
这应该不是一个技术问题，而是一个软件开发方法学的问题，但对整个软件开发过程影响极大。
我们面对的现实：.net客户端开发人员不懂服务器端Java，服务器端Java开发人员不懂.net。
除了技术壁垒外，还有业务衔接性的问题，因为我们不是纵向分模块开发，而横向开发的前提是我们服务器端开发人员很熟悉业务，知道客户端需要的接口，但实际上，业务主要由客户端推动。所以，两端的开发人员都遇到很大的沟通壁垒。

从技术的角度表达就是：客户端开发人员需要的接口，服务器端开发人员不清楚；服务器端开发人员也不知道怎么把握粒度。譬如，有个updateUser方法，但更新用户信息时，可能需要更新很多信息：用户信息、用户角色、用户所属组….。loadUser时也有同样的按需加载问题。

当然，从技术角度，开发Web Serivces有Bottom-up和Top-down两种开发模式。我们选择了前者，也是最常见的方式，也许用后者更适合我们的项目：从定义的wsdl文件开始，客户端和服务器端开发都遵循它。但问题是：我们怎么确定wsdl，也就是我们所要求的接口，因为我们自己对业务都不是很熟。

五、客户端和服务端开发测试方法
我们当时做得很笨，也最直接：等服务器端组件发布完毕后，通知客户端开发人员，然后客户端开发人员通过VSStudio提供的Web Services生成工具，根据Axis发布的wsdl文件，生成所需的.net对象，然后像本地调用一样使用。

但问题是：
wsdl随时都在变，这意味着客户端生成的组件总在变化，经常出现编译错误。
客户端开发过程中遇到的问题，一会是客户端自己，一会是服务器端组件：我要的方法包含的信息不够啊。

服务器组件测试一次，起容器特慢，而且客户端调用也慢。
我们的测试，最后走入了一个怎样的泥潭：譬如测试一张报表，都是在客户端手工填写，然后观察服务器端日志和响应。有人会问，用LoadRunner或Function Tester这类自动测试工具不就ok了吗？我都用过，它们对Web UI确实好用，后者对Swing客户端也好用，但对.net客户端，像是不太现实。
另外，Debug非常困难，因为它要求两端开发人员必须在一起密切配合。

我自己认为的解决方案，但未必真的好用：
服务器端Service方法必须写单元测试TestCase，可能代码量非常大，测试好后方发布为Web Services。
同时，服务器端提供同一套接口的Mock实现，供客户端开发测试，解决并行开发的问题。

六、其它问题
当然，上面的几点，具体到细节，我都省略了，总之问题非常非常多：技术问题、管理问题、方法和过程问题。

特别提的一点是，我们几乎开发了两套“业务层＋持久化”解决方案，因为离线客户端也用了NHibernate持久化，这样导致开发测试工作量巨大，就说一点吧:两边同步是通过打包的sql语句，通过SOAP传输，但Access和DB2的sql有不兼容问题，如果要兼容，就会以牺牲性能和灵活性为代价。

另外，我们写项目建议书时很被动，但也没办法，因为有好几家公司竞争。对我们影响极大的几个问题：

1、IBM的WAS比起WebLogic Server易用性差远了，导致部署时极其耗时。而且还有一些bug，譬如连接池资源，当时不得不和IBM工程师咨询。实际上，我们只用到强大的WAS的一个非常小的部分：Web容器。
2、我们没有针对WAS的开发工具RAD。但说实话，那试用版的RAD也是一个字：慢，而且安装时超级大，约4个G。而且和我们已经在用的版本控制工具VSS没法集成。
3、项目的C/S架构不是很合理，就是原来客户的B/S架构，也运行挺好的，而且用asp，跑在一个pc server上。我们一定程度上为了技术而技术。最后也达不到客户需求：性能＋稳定。
4、自定义报表最后没有投入使用，只是一个半成品。本来自定义报表就很难，要是容易，一个软件外行人员，就可以把表现层到持久化轻松搞定，那一般MIS开发人员不要失业了，MDA也没那么强。很多OA平台一直在解决这个问题，也没有发现特别好用的。我们做技术调研期间试过MS的InfoPath和Adobe Designer，以及Excel Server，都不能满足需求。

当然，这个子系统只是我们那个庞大系统的一个部分。上面也就算我做的一点点总结吧，也是教训啊！不过，从个人角度考虑，学到的东西还是很多的。

这个子系统花去了我们将近200个人月，如果说那浪费的部分，估计至少是100个人月的工作量。是什么导致？从我这篇文章只能窥其一角，因为整个系统涉及CMS、OA、BI、E-commerce、GIS、IM、MIS。我自己总结一下，有以下原因：
1、项目建议书空洞，不切实际：公司也很无奈，客户也不成熟。
2、需求调研后的需求分析闭门造车：客户的合同是分阶段，我们上交需求说明书后付20％款，上交设计书后又付20％。全一个瀑布开发，虽然按RUP文档写。到半年后的实际开发时，发现很多需求都不合理。
3、整个过程都没有和客户沟通，到最后开发完毕才让客户看，那时客户也懵了：这不是我要的产品啊。改呀，改呀，熬夜啊。
4、项目团队整体技术实力薄弱，当时调来做Java开发的人员，只有少数几个以前做Java，大多数是临时学。想起那Hibernate使用，心寒啊。另外，WAS问题、AIX问题在产品环境下都出来了：系统不稳定、宕机。
5、整个开发阶段流程没有把握好，像项目规范、测试方法、日志、版本控制，这些后期都出现了，而且非常严重。就说那日志吧，最后出问题都不知道怎么查，日志一遍混乱。
6、缺乏做大项目经验，整个系统架构都比较松散，项目开始时很多都不知从何入手，也很仓促。
7、项目持续一年多，人都换了几批了，工作交接很大问题。
.....

不过，说实话，项目团队，特别是进公司一、两年的员工都很努力，没有人抱怨什么，我和他（她）们一起合作，还是很开心的。

评论

37 楼 intolong 2007-04-25  

楼主很踏实，一定会成功。

BTW，
1. Web Service只是为了异构系统调用，performance在任何文档上都表明可能会存在问题。

2. IBM的产品易用性确实比较差，而且某些时候比较莫名其妙，记得刚来公司的时候，一位band10说过一句经典的话“使用IBM的产品就像在变魔术，你永远不知道它为什么会工作和为什么会不工作”。

36 楼 hocus 2007-04-25  

JavaVision 写道

rtdb 写道

这样的文章好，很有实用价值，尤其是项目教训部分。

不过， 1500W竟然是这样做出来的，

中兴软创千万的海外单子也差不多
可是算美刀的

35 楼 daquan198163 2007-04-25  

mmwy 写道

以前用xfire的时候，遇到过hibernate lazy的问题，解决的办法就是用spring的opensessioninview，让spring的这个filter对xfire的地址也生效。

同样的，用dwr的时候也有类似的问题，也是让opensessioninview对/dwr/*生效。

PO返回给客户端之后，难道这个opensessioninview filter还能起作用么？

34 楼 cskysnew 2007-04-25  

使用hibernate的确是一个很有风险的决定，我们在第一次使用hibernate时，整个项目组没有一个人会用，都是一边研究一边用，结果最后的运行效率还不如jdbc快。

33 楼 a3mao 2007-04-25  

谢谢楼主分享，增加不少见识

32 楼 yoyozhang 2007-04-25  

长了一下见识！

31 楼 mmwy 2007-04-25  

以前用xfire的时候，遇到过hibernate lazy的问题，解决的办法就是用spring的opensessioninview，让spring的这个filter对xfire的地址也生效。

同样的，用dwr的时候也有类似的问题，也是让opensessioninview对/dwr/*生效。

30 楼 zwchen 2007-04-24  

对前面几个帖子的回复：

web service有没有考虑异步？
考虑过，不过.net这块不是我负责，最终还是选择了默认的同步方式。但是异步并不是为了解决性能问题而设计的，不过可以提升用户体验。客户端很多需要即时交互的地方，异步不太可行。

难道客户投了1500万中途就没有看过系统？
请注意，Web Services部分是这个大项目的一个部分，约30％吧。当时客户是确认我们的需求说明书、以及后来的设计书，并且签字付款了。不过当时没有demo，所以客户可能自己也没看懂，要知道，上千页的文档两三天看完，可能吗？客户那边很多是领导呢，他们没到出乱子时，也不会太在意。真正的项目成功，不只决定于开发方，还决定于甲方，我们的甲方很不成熟，而且经费不是它们自己淘。另外，很多问题可能是客户关系处理的问题，也许比较灰色。


就一字:蒙！
说实话，我们并没有去蒙，我们这边的人也都尽力想做好，但确实对业务问题比客户理解肤浅得多，后来大约有一半的需求都有变更。当然，最根本的问题，可能是我们没有主动和客户密切沟通。但你要知道，客户那边也不怎么配合，一个北京，一个大连，沟通也不方便，我们后来还集体到那边开发。而且，他们那边恐怕没人对此项目承担直接责任。
另外，我们这个系统，相关子系统太多，20来个；半年下来才理出头绪，我开始进入项目，对业务也是一头雾水。

系统构架师水平太差
我承认，我们架构师也没有WS方面的项目经验，而且做技术架构时很仓促，leader在催，就给架构师几天时间，我当时就坐在架构师旁边。 差不多WS问题和很多技术问题都交由我去处理。
另外，架构师是一个技术职位，在我们这样的大公司，往往让位于行政leader，公司官僚气氛较浓。

httpClient 比web service 好使
解决一些简单的问题可能确实如此，我曾经负责一个SSO集成项目，客户端有php、java、ruby、ajax，当时就用它。
不过，当项目很大，很多对象调用问题，就不太好使：我们必须想办法去屏蔽这些底层通讯协议，对象序列化、反序列化的问题。另外我还碰到一个问题，就是分布式事务，补偿事务有时也不奏效，譬如网络超时。当然WS这类基于http的short connection协议本身也有这个问题。

29 楼 giscat 2007-04-24  

httpClient 比web service 好使
所有客户端都通用

28 楼 lgx522 2007-04-24  

zwchen 写道

3、项目的C/S架构不是很合理，就是原来客户的B/S架构，也运行挺好的，而且用asp，跑在一个pc server上。我们一定程度上为了技术而技术。最后也达不到客户需求：性能＋稳定。

Rod Johnson在“without EJB”中说了很多真诚的话，其中就有“以复杂性为生的行业”这样的说法。
说句实话，大多数B/S系统用asp、php就可以轻松搞定，而大多数C/S系统用传统的VB、PB、Delphi也很容易完成。硬件要求低，开发周期短。也就是说，90%的问题都可以用这些简单的技术解决。
可是，asp、VB太easy了，easy的东西自然就不值钱了。于是国际巨头们盯住了那10%，声称必须运用新一代的高级技术，如J2EE、.NET等等，可以轻松解决所有问题。新的价值链得以产生，巨头们又开心了。而程序员们怀着极大的期望投入新一轮的技术竞争。但结果是，为了那10%的复杂问题得以较容易地解决，我们把原先那90%的简单问题变得复杂。这正是笼罩在软件业头上的一道魔咒。

本人原先一直是新技术的狂热爱好者。好似一个新技术的追星族，精疲力尽之后才明白新老技术的共通性。其实做应用系统，你是用asp还是J2EE并不重要，重要的是你对业务的领悟能力和对技术的运用能力。有些业务是该用重型武器的，你得上J2EE；有些业务却是asp这样的小刀来得顺手，不可一概而论。asp用得精纯，也可以做到相当高的稳定和性能，以至于好的扩展性和可维护性；而生手弄出的J2EE，很多时候跑都跑不起来，再大的口号也是白费。
总之用什么技术并不重要，重要的是你熟不熟，精不精。整个IT技术圈子如果不能有这样的共识，就只能活跃着一大群满口新鲜术语的菜鸟，搞出一大堆费钱费力的豆腐渣工程。而国内的IT界也只能在这种烂泥潭中挣扎。

27 楼 pdw2009 2007-04-24  

系统构架师水平太差，这么大的系统并且开发人员都是从外面项目组调入的还用hibernate，N差！hibernate是建立在所有开发人员对该系统的领域建模都很理解并且有一定hibernate基础上的。

26 楼 hxirui 2007-04-24  

感觉象在说我们公司啊，是不是大部分中小软件公司都这样？

25 楼 ahuaxuan 2007-04-24  

zwchen 写道

ahuaxuan 写道

zwchen 写道

Web Services慢是确定的，我们测试过，另外Hibernate用得也不妥，都是eager loading。

不需要用的对象，都应该手动将其引用置空，这个我想大概是你在分布对象是hibernate的使用cglib增强关联对象造成的，这个时候应该就是手动将这个po转化为vo，特别说明，hibernate在分布式环境下会比较难用一些，很多在单jvm上能做的事在分布环境中确实是不能做的。比如说hibernate自己的集合包装类没有序列化id啊，等等，这时候就需要一个比较精通hibernate的人在团队中

是啊，当时就发现cglib这个问题，但我没怎么想着去解决，我当时正在我负责另一块开发：关于SSO的Web Services，因为我那块关联小，用VO比较多，这个没有什么影响，不过不知道你说的“手动将引用置空”，到 .net那边会不会出现问题，没试过。
如果用iBatis，是否可以辟开这个问题。iBatis我没有实际的项目经验。反正用Spring的Jdbc不会有这个问题，我们可以按需加载。

用ibatis是不会出现这种问题的，ibatis是半orm的，不会使用cglib来增强po，手动置空的问题我想还是试试吧，不过我想理论上是没有问题的，有可能出现我们想不到的问题，当时我们使用hibernate的时候也没有想到会出这些问题，但是问题还是解决了

24 楼 温柔一刀 2007-04-24  

zwchen 写道

3、整个过程都没有和客户沟通，到最后开发完毕才让客户看，那时客户也懵了：这不是我要的产品啊。改呀，改呀，熬夜啊。

这点我不能理解了，难道客户投了1500万中途就没有看过系统，真的这么不在乎？或者是对你们公司充分信任，认为你们是万能的，跟他们想的一样？

23 楼 ivici 2007-04-24  

请问你们的web service有没有考虑异步？如何做的？刚接触java，特此请教

22 楼 zwchen 2007-04-24  

<br/>
<strong>liping 写道：</strong><br/>
<div class='quote_div'>不是朝着SOA的话 就是要求分布式的话像ICE这个的分布式框架也可以的吧！WS的效率肯定是问题！归根到底是XML的问题<br/>
ajax中Json好像就是回应这个的吧！<br/>
不过1500W至少要有些噱头的！可能老大给客户做前期的时候把WS强调了一下！哈哈！<img src='/javascripts/fckeditor/editor/images/smiley/msn/tounge_smile.gif' alt=''/><br/>
</div>
以前像是做个测试，WS的效率是最低的，譬如EJB 0.5s，WS方式可能是6s。我看网上有人比较过WS、Burlap、Hessian等协议性能，WS也是最差的。不过对于我们，开始对解决方案的依据是，哪一种协议最方便开发：有很好的类库、多语言支持。对于性能问题，以及开发过程的技术、技艺风险，都没有放在首位。<br/>
<br/>
以前用过Caucho公司的Resin服务器，太棒了，是我见过的最好用的Web服务器！<br/>
Hessian协议：http://www.caucho.com/resin-3.0/protocols/index.xtp<br/>
<br/>
Hessian and Burlap are compact binary and XML protocols <strong>for applications needing performance without protocol complexity</strong>. Hessian is a small binary protocol. Burlap is a matching XML protocol. <br/>
Unlike older binary protocols, Hessian is both self-describing and portable across languages。<br/>
<br/>
我像是没有看到它为.net提供很好封装的类库，不过其官方规范还是蛮简单的，不知道要用它替代WS，开发效率如何？<br/>
<br/>
如果有人有Hessian的实际使用经验，不妨在这分享一下。

21 楼 zwchen 2007-04-24  

ahuaxuan 写道

zwchen 写道

Web Services慢是确定的，我们测试过，另外Hibernate用得也不妥，都是eager loading。

不需要用的对象，都应该手动将其引用置空，这个我想大概是你在分布对象是hibernate的使用cglib增强关联对象造成的，这个时候应该就是手动将这个po转化为vo，特别说明，hibernate在分布式环境下会比较难用一些，很多在单jvm上能做的事在分布环境中确实是不能做的。比如说hibernate自己的集合包装类没有序列化id啊，等等，这时候就需要一个比较精通hibernate的人在团队中

是啊，当时就发现cglib这个问题，但我没怎么想着去解决，我当时正在我负责另一块开发：关于SSO的Web Services，因为我那块关联小，用VO比较多，这个没有什么影响，不过不知道你说的“手动将引用置空”，到 .net那边会不会出现问题，没试过。
如果用iBatis，是否可以辟开这个问题。iBatis我没有实际的项目经验。反正用Spring的Jdbc不会有这个问题，我们可以按需加载。

20 楼 咖啡舞者 2007-04-24  

这个文章太受用了
以及每位的回复都对我帮助很大，长见识了。

19 楼 fishermen 2007-04-23  

ahuaxuan 写道

zwchen 写道

Web Services慢是确定的，我们测试过，另外Hibernate用得也不妥，都是eager loading。

不需要用的对象，都应该手动将其引用置空，这个我想大概是你在分布对象是hibernate的使用cglib增强关联对象造成的，这个时候应该就是手动将这个po转化为vo，特别说明，hibernate在分布式环境下会比较难用一些，很多在单jvm上能做的事在分布环境中确实是不能做的。比如说hibernate自己的集合包装类没有序列化id啊，等等，这时候就需要一个比较精通hibernate的人在团队中

    确实，hibernate用的稍微不好，对性能影响很大

18 楼 ahuaxuan 2007-04-23  

zwchen 写道

Web Services慢是确定的，我们测试过，另外Hibernate用得也不妥，都是eager loading。

不需要用的对象，都应该手动将其引用置空，这个我想大概是你在分布对象是hibernate的使用cglib增强关联对象造成的，这个时候应该就是手动将这个po转化为vo，特别说明，hibernate在分布式环境下会比较难用一些，很多在单jvm上能做的事在分布环境中确实是不能做的。比如说hibernate自己的集合包装类没有序列化id啊，等等，这时候就需要一个比较精通hibernate的人在团队中