花了几个月的时间费劲心思的努力的开发成果，在提出交付的几个小时内

  说来可笑，经历一个多月的设计，精心的计算和运营状况模拟，三个多月的开发，完成了一套与共享单车类似的设备管理，运营平台，然而最后交付演示的时候，客户只用了一个问题否定了一切，有些事情真的让人不吐不快。
这不是一个瞎编的故事，而是一个发生在眼下的真实事件，但这里姑且就当作一个故事来讲讲吧。

  2019年九月，在新元素餐厅里，我和合伙人与客户见面了，单子是合伙人拉来的，订制开发一套完整的类共享单车和按摩椅的设备管理运营平台，或许很多人觉的应该是一个预算很充裕的订单，正常情况即使开价到10几20万也是不为过的。

  但毕竟是熟人介绍，客户态度也非常诚恳，希望打造一套这样的平台长期运营，只是如今手里并没有那么多的钱。

  那一次聊的过程中，客户的态度的确是非常诚恳，虚心请教各种技术难点的解决方案，我也一一对其介绍了相关的处理方法，说实话，我被当时客户的态度打动了，虽然这个订单注定是一个赔本买卖，但是还是决定，尽我的最大努力设计和实现。

  通过简单了解，这个项目的后期部署铺开的范围还是非常大的，第一批上线的设备可以达到数百台，但运营环境相对较为恶劣，设备通信使用的网络是2g，设备运营的地点又是在一些信号相对较差的环境，为了客服这个难点，我提出了方案——做区域化网关。

  这是一种通用的物联网管理手段，好处我自然也不必多说了（不明白的可以自行百度），但说实话这对我来说会增加太多太多的时间成本，原本就是个亏本买卖，但是在和客户的交流中，我还是答应了会尽可能的用更高效，拓展性更高，容错性更高的架构方案来实现，保证整个平台的长久可靠运营。

  这里要说一下我的客户，对后续的运营资金扣到什么程度，一个调用一次1分钱的数据接口，听说用户在运营过程中可能会反复使用调取，一天的用户正常调用可能会造成一二十块钱的开销后，毅然决然的对我说：你要理解，这种开销要尽可能的少，能不花钱就不花钱，实在不行做缓存一天固定次数调用，所有用户共享数据。

  总的来说，那天聊的结果就是，客户明白项目需求究竟有多大，需要多少成本去实现，但依然直言：我现在没有那么多成本投入，我只希望找一个靠谱的人，做靠谱的事，大家一起把这个平台做好，前期可以简陋一些，但要保证高可用性和拓展性，只要项目上线，加盟模式做起来，后续的拓展开发还会有许多。

  时间很快，12月底，初步的平台硬件对接完成，虽然付出了很多，但还是很开心的，因为即将有一个较有规模的设备管理运营平台将要在我的手里诞生了，初期的200台运营设备和投放地点也被确定了，投放时间也定下了。

  当然最后并没有实现，疫情的原因，所有事情都被延后了，最终的交付阶段也被延期了一个多月才进行，原本以为一切都已经完善可以做最终测试的交付了。

  这个时候，一个问题出现了，用小程序对硬件的控制有延迟，无法百分百同步！在设备运行过程中需要实时产生运行报表在客户端展现，无法百分百同步，也无法在用户使用期间实时监控设备状态，对设备异常做出实时的自动调整。

  对于这个问题，我给出了我的解释，一共有两点，实时的设备状态监控并不是做不了，但实现成本太高，代价太高，初期运营阶段，以现有的资金和服务器情况，可能无法承受。第二点，实时报表生成并不是动态查询设备参数而是利用用户访问情况采集当前状态下被缓存在数据库内的设备状态，最后保存在对应的服务订单内的详情内。

  或许很多人会和客户提出同样的一个问题，实时监控为什么做不了，不就是定时去询问设备状态，然后根据订单内的参数进行调整么？动态报表更简单了，不就是根据时间去查对应的设备状态日志么？有什么难的？

  对此，我也再三做出了解释，设备如何通过网关发送状态，接受控制指令，相关日志又是如何被记录到数据库，最后又会产生多少的数据量。

  然而没有人觉的1台设备1分钟上报一次状态加用户使用期间主动查询状态一天会产生最少1440条日志记录，200台总计最少288000条日志记录，在运营1个月后产生的日志记录有多少。也没有人会觉的一个人在普通低配的数据库里根据时间查询订单服务时间段内的海量设备状态来制作报表和实际运营中数人甚至数十人一起查询制作会有区别。

  自然也不会有人觉的200台设备由服务器控制，一个分配至少2条线程处理业务逻辑和管理与设备之间的长连接并且定时每秒钟轮询状态到底会消耗多少资源，甚至会认为，只不过是订单开始到结束轮询几个小时而已，其他时间都可以自动感知设备断网和延迟，并在出现问题的时候自动调整修复。更加会觉的，1台，200台，2000台，一个人用，十个人同时用，一百个人同时用都是一回事，需要考虑？查就是了！

  花了两个小时，所有的解释都是对牛弹琴，集群架构方案在用户的辩解下土崩瓦解，1个月的设计与精心计算后利用一台双核4g内存100g硬盘的服务器如何稳定支撑整个平台的初期4-8个月的持久运营的所有容错方案和平台集群拓展方案被一一否决，而其原因只有一个：我设备启动了，你的小程序就要保证实时能看到结果，类似共享单车这种延迟时间长，无法实时查看到设备运行状态的方案，不是我要的！

  突然觉的9月份到现在，抱着负责心态的我好傻好天真，只为了客户的那一次诚恳交谈，全心全意付出了10倍与合同的劳动代价，而在这一刻显得一文不值。

  写下这篇文章的时候，我正在默默的将一个集群模式的设备管理运营平台，修改成为一个开了数百线程500毫秒一次轮询数据库与设备，保证小程序上可以看到实时可靠的数据的单机应用。

  曾几何时，在饭桌上侃侃而谈平台拓展方案，集群设计方案，吐槽其他外包企业用单机应用实现实时更新查询看上去似乎完美，但经不起运营的考验上线就崩，现在看着编辑器上的代码，嗯，真香。