这是一个创建于 2666 天前的主题，其中的信息可能已经有所发展或是发生改变。
正负责设计构建一个大型设施（确实有点大）的分布式控制软件系统，目前路线是采用同类型设施控制系统采用的一个成熟框架（ C/S，中间件为 omniORB+ZeroMQ，正在逐步替换掉 omniORB，提供支持 C/C++、Python、Java 三种语言的 API，支持 Linux 和 Windows 平台，目前正在为其开发 RESTful API ）
现在设施总体方有个人（搞电子的）说调研了 IT 公司，应该采用 J2EE 架构（我还真不懂这个东西），理由一是客户端在浏览器中运行不需要部署，同时更换客户端机器也可以快速恢复／切换（我认可这个理由），理由二是这个更先进更符合发展趋势（这个理由我倒不完全认同，选什么主要看你干啥子）
但 J2EE 这个方案提议现在未得到多数控制工程师的认同（包括我），猜想主要原因是：
1.搞控制或控制软件的基本都是 C/C++出身（单片机或 ARM 等嵌入式设备控制软件基本在用 C 写，很多工业硬件提供的 SDK 也是 C 的），根本就不懂这玩意
2.以前很多成熟可靠的代码（特别是针对一些专用硬件设备）无法直接复用了，还有就是有些硬件设备提供的 SDK 仅是针对 C 的（我想这个可能也有办法来解决，可能麻烦一点点）
3.有些关键性能指标从目前的 C/S 到 B/S 后是否能够完全满足没验证就心里没底（比如关键状态显示的毫秒级更新周期，波形曲线及时显示等）
现在要我给出一个不采用 J2EE 的理由，我不知道从技术、应用层面咋个说这个理由以使其更充分、可信一点
现在设施总体方有个人（搞电子的）说调研了 IT 公司，应该采用 J2EE 架构（我还真不懂这个东西），理由一是客户端在浏览器中运行不需要部署，同时更换客户端机器也可以快速恢复／切换（我认可这个理由），理由二是这个更先进更符合发展趋势（这个理由我倒不完全认同，选什么主要看你干啥子）
但 J2EE 这个方案提议现在未得到多数控制工程师的认同（包括我），猜想主要原因是：
1.搞控制或控制软件的基本都是 C/C++出身（单片机或 ARM 等嵌入式设备控制软件基本在用 C 写，很多工业硬件提供的 SDK 也是 C 的），根本就不懂这玩意
2.以前很多成熟可靠的代码（特别是针对一些专用硬件设备）无法直接复用了，还有就是有些硬件设备提供的 SDK 仅是针对 C 的（我想这个可能也有办法来解决，可能麻烦一点点）
3.有些关键性能指标从目前的 C/S 到 B/S 后是否能够完全满足没验证就心里没底（比如关键状态显示的毫秒级更新周期，波形曲线及时显示等）
现在要我给出一个不采用 J2EE 的理由，我不知道从技术、应用层面咋个说这个理由以使其更充分、可信一点
 |
1
Terry05 2017-09-10 10:27:07 +08:00
既然是要做大型分布式，除了 Java，还有更好的选择么？
|
 |
2
hcymk2 2017-09-10 10:41:19 +08:00
3 估计有会有问题。
其实纯 B/S 不可能做到的。 |
 |
3
patrickstar OP @Terry05 不会这样绝对的吧，跟语言关系不大
|
 |
4
codeyung 2017-09-10 11:05:13 +08:00 via iPhone
其实可以的 我们之前项目的模式是有些涉及核心数据的比如总账的核心模块还是 c 其它都可以用 kava 来搞 看成本了呗 公司说搞 你又能怎样
|
 |
5
miaomiaoweiwei 2017-09-10 11:22:38 +08:00
java 人又好招，社区各种框架又成熟，干嘛不用
|
 |
6
wdlth 2017-09-10 11:39:31 +08:00
如果是纯粹的 HTTP Restful API，响应时间还是难以与传统的 socket 通信相比的，如果用上 WebSocket、WebRTC 和 WebAssembly 等新东西，就变成了新一代的 C/S 架构，Chrome/Server 架构……
Java 可以用 JNI 与 C 的部分进行通信，不过建议还是将 C 的那部分单独做一个服务器，用协议进行数据交换。 |
 |
7
ulins2000 2017-09-10 13:05:26 +08:00
用网页与硬件打交道的基本上都是都是一些只会搞些网页开发的人的胡扯的方案
|
|
8
patrickstar OP @wdlth 受益，谢谢
|
 |
9
zwy100e72 2017-09-10 18:41:53 +08:00  1
基于我个人（非常短的）经历而言：
1. 现有 C 代码不是完全不能进分布式系统，只是需要一个微服务框架和对应的接口 2. 转型过程中也要考虑 C 和目标语言之间的交互，需要提供相应的接口才行 3. 如果是延迟关键领域，Go 语言也值得考虑 4. RPC 和 mRPC 耦合还是太紧密了，最好能用 REST 或 SOAP 5. 如果框架层层封装消息，最后只剩一个函数调用了，无论底层是 REST 还是 SOAP，其实都等价于 RPC |
|
10
zwy100e72 2017-09-10 22:42:54 +08:00
我刚刚看了个视频 如果你的数据更新要求不超过 60Hz 的话，那客户端能完成的浏览器一样能完成，就是需要 width 说的一些东西
如果你的数据更新要求超过了 60Hz，那么实时显示的话还是需要一些特殊的硬件才行，普通显示器没办法刷新那么快；游戏显示器最快也就 480Hz 多加一句，如果你的目标是在任何端，任何时间地点，一键打开你的应用，统一的做法就是使用 Web Application，然而客户端能以时间换空间，虽然每个新客户端都需要花时间去重制，但是客户端能帮你扩展到 Web Application 无法达到的其他客户端上。 （抱歉 基本上把回复当成笔记本了） |
 |
11
vjnjc 2017-09-11 11:32:17 +08:00 1
看起来是一个 c/s 架构转型到 b/s 架构的问题，
转型优点：客户端不用部署，restful 接口的话跨语言 转型缺点：团队技术没有 web 前端的知识，也没有 restful 的知识。 个人建议逐步改革，先用熟悉的语言做一个能够产出 restful API 的后端，这样对外调用起来就和 j2ee 框架一样了（你要的不用 j2ee 的理由也就有了） 但是数据包从 socket 变成了 restful + json，关键性能肯定没以前好，具体差多少你测试一下再看看。 |
|
12
patrickstar OP @vjnjc 就是准备开发一个 restful API 的后端，这样保持两个架构都可能
|
 |
13
WispZhan 2017-09-13 00:06:14 +08:00
工控方向的，还是建议客户端比较好，可以直接操作底层的驱动或者直接读取 COM 口，否则还要再浏览器上加插件作适配。服务端 Java 正常提供资源接口，提供 RPC。
工控方向的客户端还是用 C/CPP，再不济还可以用 Java 客户端调用 native 接口。如果单独只适配 Win 的话 C# Client 也是个不错的选择，也是可以直接调用 C/C++ library 的。 如果为了跨平台，要么针对不同系统平台选择不同的开发方案；要么就选个跨平台方案，Java GUI、Electron 或者 QT。 反正不管怎么说，底层接口都要封装一个统一的调用库，然后给 Client 或者 Web 使用，这是少不了的。 至于向示波器或者其他采集器，这样的高频实时数据，确实是个难点。最好在采集在客户端缓存，然后定期上传到服务器同步。如果直接采集然后上传到服务端的话，也不是不行，只是不知道这个数据量总体达到什么量级。 |
|
14
patrickstar OP @WispZhan C/S 确实还是当前控制系统的主流解决方案，在系统配置管理、监测方面逐步往 Web 方向拓展
|
 |
15
oaix 2017-09-24 18:29:40 +08:00
对楼主这个领域不是很了解，只是对第三点要求有点问题：“关键状态显示需要毫秒级的*更新周期*”
如果更新周期的意思是 采集数据的频率，那换成 BS 与 CS 没有什么关系吧，如果指的是显示的时延，那 BS 应该会差一些，但是监控真的需要毫秒级的时延吗，用户看到这个指标变化到做出反应都需要秒级的时间吧？ |
Select Language