请教一个系统的设计

[hageen_dazs]

请问一些问题，主要关于系统架构方面的，主要有以下几个特点；
1：客户端的数据主要来源自硬件设备，通讯方式有蓝牙，串口。以及来自于内部外系统的一些数据。
2：客户端的功能主要是查询和极少数的录入，采用触摸屏的方式。
3：客户端的用户数量大概在3K-5K之间，并发量在百分之三十。
4：服务端功能主要是接收客户端（PC、安卓、IOS）数据、外部系统数据（外网支付、内网信息）、数据库（ORACLE）、以及常规性功能。
5：客户端采集的数据是要求实时的，甚至采集的数据会要求发送到手机端。
现在我在思考用C#开发客户端，采用C/S架构，用WINFROM或WPF都行（优先WPF），服务端采用JAVA在LINUX系统做支撑。
也有人建议我服务端采用.NET作为服务端，在Windows下运行。
所以有这么几个问题；
1：客户端PC采用什么语言和架构？为什么？
2：服务端采用什么语言和架构？为什么？
3：PC与服务器之间的通讯采用什么？为什么？

[xuzuning]

在 Windows 下运行 ORACLE 简直是噩梦

[以专业开发人员为伍]

我们不讲编程语言，你熟悉什么就可以用什么。编程语言的语法的区别只是皮毛，你的开发环境所提供的底层框架（framework）系统才是实质，而底下的是计算机体系结构、设备驱动基本原理、各种其它知识，这才是判断关键。因此你熟悉的东西，99%都是框架内容。如果你认为自己的主要知识都是编程语言语法课程培训班上学的，那么建议你另找比你在正规软件公司工作经验至少多6、7年的人，才来设计开发这样的系统。 至于架构，并不能随便讲一些名词儿，要看你所设计的蓝图，再来对核心的地方进行重构。架构都是应对极限需求而产生的，而极限需求其实就是每一个用户自己的独特性决定的，凡是那些似乎人人都能懂得所谓“架构”概念，那其实就不算是架构，必定是失败者不断重复的所谓架构，而真正成功者所用的“架构”其实就是细节和执行力。这些架构放到那些只喜欢追求时髦名词儿的人那里，不论怎么看好像都很普通似地，因为他们自己都无法深入去分辨技术区别。 如果平均每天有10万条完整的信息要上传，有100万条信息要实时下传，那么你就千万不要因为“只有3K用户”就胡乱选择什么编程框架。数据库不是关键（更不能盲目选购昂贵的企业数据库），真正的这类信息发布系统的强大性根本不是靠轮询数据库而来的。相反地，如果轮询数据库，那么你的系统可能上线不到1小时就垮了，就得给客户退钱了。一年内会垮50次，每次都停2、3天。同样地，假设有APP等需求，有涉及支付、工作流、即时通讯等部分，那么这种技术是基于“双向通讯”的，更不是那种去查询数据库的思路。如果没有双向通讯技术，或者双向通讯技术只能在单机、而不能在10台机器上实现，那么最好不要随便乱开发。 有的人动不动就给用户瞎说什么“负载均衡就好啦！”，实际上将来你的系统的个性化信息很多，而不是简单地大家去浏览相同的帖子。用web服务的负载均衡概念来解决一个高性能的数据采集和高并发的信息交互的系统，可以等着瞧，死的很快。

[以专业开发人员为伍]

由于现在的做web的小公司很多，那么很多小孩子都会扯什么“负载均衡”的概念来骗人。实际上一个做Web的网站，跟一个高度社会化的应用（例如腾讯的微信），在所谓负载均衡上的实现是天壤之别。一个网站的那种所谓负载均衡，几乎可以说是低级到“阴沟里的”，因为它不过就是对于千篇一律的网页刷新进行负载均衡而已。 比如说一个人用APP要观察“有哪些种类的人潮经过了自己的大门口”，他要附加好几个个性化的查询条件，连续观察1小时，要求最多每隔10秒钟就更新一次全部数据。那么假设有1000人在线，几乎可以预计到，至少有几百种查询模式。在这样的系统中，当采集系统有数据时，会实时地（在内存中）决定每一个数据变化要立刻推给这1000人中的120人，下一个数据则要实时推给另外30人。这里根本不是去查询数据库，而是推送！

[PaulyJiang]

每天回帖即可获得10分可用分！

[Justin-Liu]

楼上大神说的是 纠结于用什么实现毫无意义