高级的 C/S架构如何实现

mrsupersky 2011-06-21 05:29:56

体系可分为N层，

但要求是，Client端只有UI层，
所有业务逻辑和其他结构都放在Server端，

显然：
只有Server端直接访问数据库，Client端把需求给Server，Server返回结果
难点1，如何传递对象，答：序列化（这个我知道了）
难点2，如何实现并发式访问。

难点2.简单分析：
是实现，不是避免，用户必须可以同时访问同一条数据，
否则用户体验会很差，另一个用户比可能去等待当前用户的访问。
客户不是一个而是面向全球。

要求必须能够满足N个用户的并行访问，否则C/S架构的优势便不存在了

客户要求不使webService,不使用WCF，只能使用Socket（原因：影响速度）或remoting
可以使用remoting技术，但客户更希望使用Socket，并对程序有很高的性能要求

目前，关键所在，业务逻辑如何通过网络传输并与UI进行交互，充分使用Socket快速的特点，另外还有一个难点是数据加密问题。希望达人，谈谈看法，谈谈技术就更好了。

理论上多个用户访问同一数据，并具有写权限是不可能的，所以客户要求是至少达到几乎看不出来差异。

另外，关于UI，UI的位置全部使用动态，这又应该如何实现呢？
UI的美化等全部放在客户端，这是和B/S架构最大的区别之一。
避免一些不必要界面垃圾的数据的传输。

...全文

1225 45 打赏收藏转发到动态举报

写回复

用AI写文章

45 条回复

切换为时间正序

请发表友善的回复…

发表回复

mrsupersky 2011-07-13

打赏
举报

结贴了，再等也无意义，关键是也差不多了，至少在理论上懂了不少了。。。

xiweiwei 2011-07-13

打赏
举报

学习了……每个人的见解都很精辟，不错啊……

wxd024 2011-07-04

打赏
举报

帮顶，学习

Clear_Love 2011-07-04

打赏
举报

围观学习，！

足球中国 2011-07-04

打赏
举报

有本c++游戏开发的书籍是介绍。游戏的服务器端与客户端开发的。基本上和楼主的需求差不多。
wcf确实慢。比直接数据库至少在20倍以上。如果和直接用socket比。慢的更多。
关于难点1，如何传递对象，答：序列化（这个我知道了）象楼主这样传递对象使用序列化。可以说会把速度慢很多。
我们这段时间做的三个项目。都是工业无线数据采集的。客户端都是些设备。采集些压力，温度，湿度，电压，电流等一些数据。其中两个项目的服务器端是我写的。客户端数量不足一千台。有一个服务器程序已经运行9个月没有出现任何问题。
掌握了一些方法，还不至于做不出来。
我们还有一个项目是信息发布系统。客户要求客户端数量能达到几万。我们采用国外一个开源的框架（开源并不免费）。目前在使用客户端数量也只是在200~300。所以没看出什么，听我公司人说。印度有家公司在用。客户端已经有十几到二十万左右。

萨拉嘿 2011-07-04

打赏
举报

[Quote=引用 12 楼 shigaofei1 的回复:]
引用 11 楼 vrhero 的回复:
引用楼主 shigaofei1 的回复:
客户要求不使webService,不使用WCF，只能使用Socket（原因：影响速度）或remoting
可以使用remoting技术，但客户更希望使用Socket，并对程序有很高的性能要求

你这客户很蛋疼...WCF包含remoting，并且比remoting更开放更高效...再说WCF也还是基于Soc……
[/Quote]
帮忙顶下对于Framework问题期望有好的解决方法

mrsupersky 2011-07-04

打赏
举报

再顶顶呗。。。

以专业开发人员为伍 2011-06-25

打赏
举报

[Quote=引用 35 楼 shigaofei1 的回复:]

UI层只涉及数据的显示，简单地说就是
客户端解析，UI的排列顺序，位置，显示方式，数据提交,更改提交等，额SliverLight不错啊，可是对于与权限的限制实在是太大了呀。。。
[/Quote]
silverlight可以编译为桌面（out of browser）模式的，可以操作COM组件，可以随意访问磁盘。即使是浏览器内模式的，silverlight4也比之前的版本权限大了（版本5会更多权限）。

king_827 2011-06-25

打赏
举报

我是这样理解的.
查询业务是可以并发的.
修改业务是不能并发的.(需要队列,通知等手段)

okkk 2011-06-25

打赏
举报

客户面向全球时,网络上有太多东西不能保证.
所以我偏向老旧的命令模式.
客户端发送一个命令, 背后附带相关参数
服务器端执行后推送到客户端,验证操作的有效性.
一个序列化后的对象与文件从根本上讲都应该是一个stream
客户端接受数据后完成同步

就像邮件系统, 在规模,功能上都是很好的范例.

mrsupersky 2011-06-25

打赏
举报

UI层只涉及数据的显示，简单地说就是
客户端解析，UI的排列顺序，位置，显示方式，数据提交,更改提交等，额SliverLight不错啊，可是对于与权限的限制实在是太大了呀。。。

mrsupersky 2011-06-25

打赏
举报

我看MSDN上说TCP 的 remoting可要比WCF的快的哟。。。

mrsupersky 2011-06-25

打赏
举报

[Quote=引用 38 楼 sp1234 的回复:]
引用 35 楼 shigaofei1 的回复:

UI层只涉及数据的显示，简单地说就是
客户端解析，UI的排列顺序，位置，显示方式，数据提交,更改提交等，额SliverLight不错啊，可是对于与权限的限制实在是太大了呀。。。

silverlight可以编译为桌面（out of browser）模式的，可以操作COM组件，可以随意访问磁盘。即使是浏览器内模式的，silverlight……
[/Quote]

out of browser模式是？Sl的什么版本？4.0吗？

mrsupersky 2011-06-25

打赏
举报

哦，那可以考虑考虑，我以前一直盯着SL3看的，
这样就好办了，只要添加一个类似于WebBrowser控件。。。。
无限遐想。。。

速度应该不成问题的吧？

听说SliverLight也支持Socket？

龍月 2011-06-24

打赏
举报

cs + wcf 可以满足

shaofei830927 2011-06-24

打赏
举报

不要把客户端想得太简单除了UI 至少还应该有网络连接层和实体层客户端可以实现并发，如果业务上没有什么需求不实现也行
并发主要体现在服务器端采用多线程来完成可以多线呈扫描端口也可以单线程成扫描端口多线程执行请求另外可以采用队列来控制服务器处理请求顺序和防止请求丢失等

另外指正一个错误webService大多时候比Socket是要快的而且还可以绕过部分防火墙避免打洞你采取使用Socket并不是因为webService效率低而是因为客户要求你使用Socket 对不？
使用 Socket时服务器使用一个公网地址客户端是可以很简单的找到服务器，但如果倒过来服务器寻找客户端（比如广播）那就有些麻烦了特别是客户端为多级局域网内的一台机器另外电信和联通的线路来回跳两下会莫名其妙的丢包建议采用双线服务器

以专业开发人员为伍 2011-06-24

打赏
举报

假设说一个企业服务在当前第一期支持60个功能，那么你就可以找两个做前端交互界面程序开发的人，使用其中10个功能做出一个产品；再找另外4个人，再使用25个功能做出另外一套前端产品；同一套业务服务可以由不同人、用不同开发方法、在不同软硬件上开发许多套客户端..........你可以为同一个客户端小程序的创意，专门找两三个团队、花2周时间分别开发一个产品，然后你只最终采用一个团队的产品。你可以用纯粹外包的方法来开发客户端程序。而对于服务器端很少有搞多个的，一般都是找自己的最精英的开发人员来开发。所以前端开发和服务器开发是既有分离又有联系的，不是一个项目。

以专业开发人员为伍 2011-06-24

打赏
举报

关于第二点我再说明我的说法：使用.net封装的web service要比基于http post方式通讯慢许多，而http基本上是按照短连接方式设计的，要比长连接的tcp通讯方式慢数倍。将命令对象进行序列化和反序列化，编程上并不复杂，大多数人使用web service甚至wcf是图简单方便，而并不是真的图性能（因为它其实是慢的）。

以专业开发人员为伍 2011-06-24

打赏
举报

[Quote=引用楼主 shigaofei1 的回复:]
是实现，不是避免，用户必须可以同时访问同一条数据，
............

客户要求不使webService,不使用WCF，只能使用Socket（原因：影响速度）或remoting
............

目前，关键所在，业务逻辑如何通过网络传输并与UI进行交互，

............

另外还有一个难点是数据加密问题。

............

理论上多个用户访问同一数据，并具有写权限是不可能的，所以客户要求是至少达到几乎看不出来差异。

............

另外，关于UI，UI的位置全部使用动态，这又应该如何实现呢？UI的美化等全部放在客户端
............
[/Quote]简单说吧：
通讯当然是多个成千上万个用户同时访问的，任何产品都是。在服务器端，从aceept开始到receive（或者说对newworkstream的read操作），都可以采取异步的方法。.net的tcplistener的异步方法封装好了iocp技术。

假设你们双向通讯很频繁，实际上短连接和长连接的速度差别就是好几倍。而包装复杂的短连接，更比包装简单的短连接慢许多。

你的问题有点本末倒置。界面层不是与服务器通讯么？不是交换命令对象么？比如说有60个服务功能，那么UI就去尽情发挥想象力去做出好多种类的产品，可以使用各种开发工具、开发平台。是表现层去访问服务器，使用服务器，而服务器端的设计与表现层既有关联又相当独立。表现层向服务器发送一个命令消息，并且等待返回来的对象，这就是一个通讯了。同时假设是长连接，服务器不但可以返回表现层需要的数据对象，也可以同时推送消息通知对象过来。两个机器相互传送一些字节流，一点也不神秘。

加密有很多种方法，但是其不过是对传送的字节流加密。比如DES加密，可以将一个字节流数据变成另外一些数据，到另一端再解密。而DES密钥可以商量好，也可以先用一个RSA加密方式由客户端发送给服务器（因为公开密钥RSA方法可以保证只有服务器可以解密、而其它监听者无法解密。这样客户端连上服务器之后就可以每隔10分钟就换一组DES密钥）。当然你也可以选择严格遵守SSL规则来编写这方面的程序。但是原则是，在一开始不要考虑加密问题。加密机制是可以在通讯这个层次上，双发各自增加一个小程序就解决的，可以在你搞清楚之后，用2个小时彻底写好。（而没有搞清楚的时候，只应该用业余时间去做“探针式”研究，没有必要专门化时间设计这个）

我看不懂你说的“写权限”是什么意思。整出来关系数据库问题了？数据库有许多种选择，还可以先不用数据库来实现许多业务。所谓写权限，不是软件设计的内容，而是开发时即时由开发人员做出的决策，以后也不断被重构。比如说你跟用户讨论“当多个用户同时去抢购同意商品的库存的时候”，如何正确更新库存而不出错的问题，这才是业务问题。你可以告诉用户，经过测试，当用户抢购不同商品时响应是多快，请购相同商品时响应是多快。用户才不必要跟你纠结数据库锁之类的问题呢，你应该换各种思路去解决。用户只要首先判断你们是不是那种“一做这种功能就做砸了的公司”，然后就会放手让你们去逐步提高性能。

网络软件开发本来就应该分为表现部分、业务服务部分。即使web开发也是如此。即使使用asp.net、jsp等等，也不是让那些编写前端程序的人去编写业务服务部分，而是分层设计和分层开发。而对于使用html/jquery式的前端开发，则根本就跟服务器端开发完全并行和分层，跟winform、silverlight开发一样了。在系统内部往往是，前端程序开发是一个团队，服务器端程序开发是另外一个团队，它们之间靠业务逻辑层相协同，所以只有在讨论这个程序合同时会在一起讨论，而分析内部的任务开发进度时则完全分开到各自的团队内部的办公室里去讨论了。前端开发团队，当然是想方设法改变界面交互设计，给用户一套好的体验。而服务端系统的开发团队，当然是更多地考虑后端的架构问题。