菜鸟也谈架构之C/S三层架构的轮回

菜鸟也谈架构

本人06年毕业 一直做JavaWeb应用的项目 大大小小做了5、6个吧

感觉B/S结构的应用 项目实施下来都不是很理想 虽然都验收了 但我觉得这些项目也顶多能给个百分制及格分 60分

主要弊端：

（1）实时响应速度差
    （尽管已经做了集群、机器是小型机）

（2）人机交互能力太弱，有些特殊的地方还不得不借助鸡勒技术ActiveX和Applet。使得B/S仅有的一点点部署方便的优势荡然无存。
     （尽管现在已经有很多RIA技术手段,比如EXT、Flex等~ 但都有各种问题。论证下来实施这些技术还是性价比不够理想。）

我的想法：

C/S三层架构应该要轮回崛起了。
理论上说,B/S其实也是属于C/S三层架构的应用。但他的C这一层实在让人不爽。

扪心自问，你为什么要选择B/S来做行业应用系统(特质运行在专用网里的特定行业应用系统)
(1)、为了跟时髦。觉得JavaEE(B/S)代表了时尚潮流，代表了先进。
     扯淡。JavaEE并非就得把C做成浏览器应用。评价系统优劣最直接的三要素：方便、快捷、稳定（我一客户和我说话聊的，我决定很有道理）
(2)、为了数据和业务逻辑集中，实现部署、升级的方便。
     这恐怕是针对C/S原始2层架构而言.而且是因为你技术部到位不能做到完美的自动升级而把这一功能通过b/s模式变相解决吧。至于数据和业务逻辑的集中如果是C/S三层架构的话，B/S根本没有这一优势可言。C/S三成架构一样可以做到。
(3)、为了应用服务器集中、方便做集群和各种负载均衡。
    C/S三层一样可以。

居然如此：我们为什么还要选择B/S 。

我的想法：
做一个c/s三层架构。总的方向还是基于Java。

方案一：用SWT/Jface和EclipseRCP技术做为UI层技术。实现一个纯粹的UI客户端。通过RPC调用JavaEE应用服务器发布的方法进行业务处理。此方案的问题：选择一种高性能且易于异构系统集成的RPC方法。（初定的方法是使用httpinvoker作为架构内部的RPC调用，并支持 webservice满足其他异构系统调用需求）不知道hprpse是否能同时兼顾高性能且易于异构系统集成？

方案二：用SWT/Jface和EclipseRCP技术做为UI层技术。实现一个纯粹的UI客户端。然后自己实现一个类似中间件或者应用服务器概念的东西，但不走http协议。考虑其他通信方式。我的业务逻辑组件也不希望再借助于Java应用服务器。而是直接将我的业务逻辑组件发布到这个中间件上作为服务提供给客户端调用。这只是偶的想法，不知具体怎么实现 不知道hprose是否能再这方面做点什么？

你的想法跟我们的不谋而合！

你最后说的两个方案都是 hprose 目前和将来要解决的问题。

目前方案一，已经可以用 hprose 来解决了，hprose序列化在性能上可以超过java序列化（序列化后的数据量远远小于java序列化，而反序列化时间也短于java序列化，而序列化速度也是远远超过其他RPC的序列化速度，看附件图），另外，在传输时采用流式协议，没有二次编码解码问题，速度更快。目前支持 9 种常用语言，将来会支持更多（计划中的已经多达30种，另外，以后也可能还会增加一些新出头的语言支持，例如 Google 的 go 等），所以异构系统调用不是问题，因为这就是 hprose 要解决的问题。

你说的方案二，也是我们计划中的，我们在推出 hprose on http 1.0 之后（现在已经推出了），下一步我们就开始实现对 tcp 协议的绑定支持，这样速度更快，也不再依赖Web服务器。而且用法跟 http 版本基本上没有区别，所以，同样的服务，既可以采用 http 绑定发布，也可以采用 tcp 绑定发布，当然也可以同时绑定发布，同时满足企业内部和互联网的应用需求。

托吧。。。。。

晕死 第一次被人说成托~~~~~~~~~

枪吧。。。。。。

hprose 是什么啊？
百度和javaeye上都搜不到，楼主怎么知道的。
晕倒，又搜到了。

hprose又不是只lz说的，不是那个1楼的讲的起劲麽

嗯，lz 提问中提到了 hprose，而 hprose 正好是我们公司的产品。我来回答没什么不妥吧。讲的起劲也是错吗？

选择B/S架构可能更多考虑到的是集中服务的模式。毕竟一台一台机器去安装客户端，实施起来不是特别方便。

B/S 优势大大的

最起码几亿人不要重新安装客户端了