【万泉河】服务器与服务器大不同
被服务器这个概念困扰很久了, 包括要开始写此文了, 许多概念也尚未完全弄明白。 写出来, 希望有机会与广大读者共同探讨。
服务器的本质是什么, 服务器给人的第一印象是什么?谈我自己的固有印象吧:高大上, 高配置, 高性能,运行速度快, 价格昂贵。而站在服务器对立面的呢,客户机, 矮穷挫,配置一般,性能平平, 价格便宜...
在IT领域, 服务器一般都深藏在电信机房, 我们平常人难得一见。所以只能从功能上了解, 比如网站服务器, 邮件服务器, 云服务服务器等等。
而在工控领域, 对工控人就很常见了, 通常会在中央控制室, 最常见的就是WINCC服务器咯。
这两种服务器, 本来各行其道,没啥关联的。 因而也相安无事。 可网络时代来了, 工业4.0来了, 工业数据信息需要进入web,这俩货就不可避免的要遭遇到一块了。 要么咱们来比一下谁比谁更高大上, 谁服务谁,谁才是真的老大?
这一比, 就比出来问题了, 服务器和服务器原来不一样, 我们过去泛泛地把WINCC站叫做服务器, 原来有很大的纰漏的, 不严谨。
回到服务器的本意吧。服务器英语叫做server, 服务啦!服务生, 为人民服务,啥时候听说过服务生比被服务还高大上的?当然某些号称的公仆除外。
所以,服务器这个名词本身叫法就有问题。 导致我们想问题的时候容易迷糊。
不能用服务器的称谓, 得用“数据提供者”,英语叫做provider。在数据通讯中, 简单的对等通讯,是A发送, B接收;或者B发送, A接收。但那样的效率低,承载量小。
更为常见的则是一方作为数据提供者, 提供数据服务。另一方作为查询者或者获取者,向数据提供者发出请求, 然后获得数据。这里面不因为数据的读写方向, 而发生互相身份的改变。 即便是查询者向提供者写数据, 也仍然是查询者发出写请求,提供者允许后数据写入完成后给出一个回执。
这里面数据提供者就担当了一个服务生的角色, 随叫随到,随时响应。 没人叫,就一直呆着候命着。而查询者呢, 需要数据通讯服务的时候来参与通讯。而不需要的时候呢,可能就直接回家了, 睡觉了。 但作为服务方的数据提供者呢, 仍然要7*24小时不间断持续服务。
服务器啥时候会变得高大上了呢?当向其索要服务的客户多的时候。 一个服务员, 只服务一个客户,很轻松。如果要服务10个, 就有点手忙脚乱了。如果要服务20个,就要身体特别好精力特别足的年轻小伙了。 再多, 就要多人一起协作服务了。 像互联网上的动辄百万的同时并发的数据访问量,需要的服务生的性能就要特别高才能胜任了。
而对于客户端数量较少的情况,所谓的服务器,有时候需要的性能就少的可怜。有时候简单到一个芯片就足以完成。听说过串口服务器吗?就这个样子的:

没错, 它也是服务器。 完完全全颠覆了以往对于服务器的概念了。
同样, 对于MODBUS协议, 所谓的主站, 其实是数据请求者, 而从站其实才是标准的服务器。 你想啊, 不管主站在不在线, 是否要来查询数据,作为数据提供者的从站, 都要一直运行从站服务程序, 以随时应答...
所以后来, 当MODBUS协议升级到MODBUS/TCP的时候, 叫法也变了。 原本的RTU,叫SERVER了。 而作为查询者角色的上位机叫做客户端了。 不再居高临下地称为主站了。
把考虑问题的视角由服务器/客户端切换为数据提供者和访问者以后,就很容易思考数据发布到网络空间的数据链路了。 通常来说, 不大可能有角色单独只做提供者或者只做访问者。 大部分情况下, 数据通讯链路中的每个成员, 都会同时担任数据访问者和数据提供者两个角色。 从它的上游获取数据, 然后作为服务, 期待更下游的访问者来访问。
比如一个标准的PLC+WINCC的控制系统, 他的数据链的方向应该是:
仪表--->PLC--->WINCC server--->WINCC 客户端
以及,
仪表--->PLC--->WINCC WEB server--->WEB客户端
在数据链路中, PLC和WINCC SERVER 都是同时担任了两种角色。
那么, 现在面对互联网数据发布和访问的流程,如果SERVER端可以有公网IP, 那么链路的第3段, 都是可以穿越internet的。
但悲剧的是, 工控系统在一个企业的IT系统中占有的位置都很低, 特别是中国的IP资源特别稀有的情况下, 通常很难在SERVER端获得一个公网IP地址。 哪怕是动态的公网IP,目前都已经越来越难得到了。 一次一次的电信网络升级,客户们发现, ADSL拨号所获得的IP,很多竟然都是10.x.x.x这样的内网段了。
有办法, 租用云服务器, 他们有公网IP,加入到这个链路中来, 或许可以解决问题。
仪表--->PLC--->WINCC WEB server(内网)--->VPS(公网IP)--->WEB客户端(内网)
但好像仍然有问题, 躲在内网中的wincc server,是无法被公网中的VPS发现的。 因而也就无从提供服务了。 所以有人提出过把WINCC系统的数据发送到云端服务器的想法。 也就是说让WINCC对两侧都作为数据访问者,把从下位获得的数据, 搬运给云端的VPS。即:
仪表--->PLC--->WINCC WEB server(内网)<---VPS(公网IP)--->WEB客户端(内网)
现在问题来了,因为在旧的链路情况下, 实时数据是在访问的时候直接从最上游获取的, 而历史数据也可以只保存在WINCC SERVER一个地方。 现在VPS变成了局部的数据最上游, 那么为了保障数据的及时性, 工厂内的server需要足够频繁的实现数据搬运的工作。这些都需要人工编程来实现。 同时历史数据也要同步并存储在VPS中,数据库软件方面的投资不小, 而存储空间也会是一块不小的投资。 这比起在WINCC SERVER端买一个公网IP来说,恐怕花钱会更多。
所以, 我猜测, 凡是提出这种方案的人, 最终都不会付诸实施。 大概都是一直停留在概念里吧。除非是物联网和只能家电领域, 工厂内压根没有投资PLC和WINCC 站, 数据的安全性要求和实时性要求也低, 所以数据才可以直接存储在云端。
所以看来对于大数据量的控制系统,上述的方案并不可行。比较可行的方法是VPN, 在VPS上面搭建VPN SERVER, 工厂内的WINCC站作为VPN的客户端登陆到VPN网络, 因而实现可以向VPS提供数据服务, 在数据安全要求高的场合,客户端在访问数据之前, 也需要先拨号到VPN SERVER, 实现虚拟专用网络。 客户端貌似直接访问数据的过程中, 云端VPS实质上起到了数据转发的作用。 而如果数据安全不高, 那么在云端的VPS就应该直接提供数据转发的功能到公开的端口上。 WEB客户端在访问VPS提供的地址时, 就直接经由VPS的数据转发, 访问到了SERVER。
今天这里呢, 只是思路的考虑, 并未涉及到具体的方案。 有具体方案需求的, 在回复中讨论。