订单系统是整个平台的独立的核心业务流程，它本身并不复杂，最初的原始需求如下：
1.用户打开app，登录进入主界面。
2.点击扫码，扫码摇摇车身上的二维码。
3.app显示扣费，摇摇启动。
4.用户订单中心显示消费明细，商家订单中心显示收入明细。
长期写代码形成的思维习惯，脑袋里面立马意淫起来，浮现出一幅画面:
路边有辆摇摇车，用户张三打开app，迫不及待的扫码摇摇车，系统提示，未登录，张三输入手机号码和密码，登录成功，可以扫码了，这个时候系统又提示钱不够，张三只能通过app充值，充值成功后，继续扫码摇摇车，终于app提示扫码成功，消费1元，1秒钟后，摇摇启动了，用户可以在用户中心看到每次都消费明细，商家可以通过微信登录商家中心，查看每天都收入，到达一定的资金量后，可以申请提现。
从这个需求里面，大概知道一个整体流程应该怎么走，下面要做到就是根据具体的业务场景做功能设计，依然是程序员的惯性思维首先想到的是: 用户点击扫码摇摇车，然后摇摇车启动这个过程怎么交互?
其实我前面有说到过，摇摇车信号启动这个过程，已经有人在研究并打通，软件这边只需要发送相关协议即可。由于硬件这边是C语言，两边的通信采用什么方式需要考虑。当然，物联网项目现在也比较成熟，相关的解决方案也大把，我们用的是阿里云的平台，阿里云这边已经提供物联网套件的整个解决方案。我们采用的MQTT协议作为软件和硬件的一个交互中心，光听MQTT名字就大概知道MQTT属于消息中间件了，它和传统的MQ系列产品(如RabbitMQ，ActiveMQ等)稍微不一样，MQTT协议是为大量计算能力有限，且工作在低带宽、不可靠的网络的远程传感器和控制设备通讯而设计的协议，主要用于小型传输，开销很小（固定长度的头部是 2 字节），协议交换最小化，以降低网络流量，像摇摇车(摇摇车身上装了个智能盒子，盒子里面有个2G流量卡，盒子发信号给摇摇车)这里面用的就是2G的流量卡这种业务就非常适合这种。
大概的通信过程就是如此简单: 软件应用层发送协议到MQTT中间件，摇摇车身上的盒子订阅消息，一旦收到消息，盒子就发送启动命令给摇摇车，摇摇启动。
所以订单系统的第一次发版流程如下:
备注: 由于涉及到平台的一些机密，订单系统不可能详细描述到传某个参数，怎么去数据库查询，甚至贴核心代码上来，如果有感兴趣的技术朋友，可以单独探讨！
整体功能性开发差不多，核心主干流程一旦打通（到目前第一版总共差不多花了1个半月左右时间），当然迫不及待地投入到市场进行模式验证，从投入到第一辆摇摇车开始，运营平台后台陆陆续续在产生订单数据，这个过程绝对是大幅度提高士气的，大家看到了希望，前面大概2，3周到时间里面，老板们整天盯着运营平台的订单页面不断的刷新订单记录，每看到一个用户充值的订单，都是欣喜若狂啊。
创业的路都是艰辛的，其实每个创业者真正拼的并不是纯粹的市场盈利模式，也不仅仅是管理策略，我一直认为创业公司能走多远，就看每个人在这个路上想走多远。同时，只有走的更远才能看的更远。所以一切从简，一切利益最大化，效率最大化为原则。
行业内本身经验的欠缺，时间的仓促等各方面原因立马检验出第一版上线订单系统有如下的BUG:
1.用户app扫码需要判断当前车辆（设备）是否在线，如果在线，就用户扣费，然后发送协议到MQTT。这个版本里面的判断设备在线用的是阿里云提供的一个公共接口，而且阿里云也后来指出这个接口不能用于主干核心业务流程，尤其使用很频繁的业务场景，当初没看到，结果造成很多设备其实不在线，但是用户继续扣费，发送协议到MQTT，当然盒子因为没在线，也不会发生启动指令给摇摇车，摇摇车没启动，这样造成了大量的用户投诉，说乱扣费，结果那段时间客服在后台一个个的退费（退费有依据的，看我上面的流程图就知道，盒子要是订阅到消息，会通过订单号修改数据库状态就知道盒子有没有发送启动指令了）。
2.正常情况下，就是设备真的在线整体流程走下来，但是到了设备那一端（看我图），盒子接受启动指令，发送指令给摇摇车，这个过程并不是摇摇车百分之百就一定启动，原因就是摇摇车本身硬件的不成熟。这么一来就彻底尴尬了，设备在线，用户扣费，发送MQTT协议，设备订阅消息，并修改数据库状态表示发送启动指令给摇摇车了，但是摇摇车就是没启动，简直无从查起，毫无证据保留，那段时间唯一的解决方案就是尽量送用户一些用车卷进行低调安抚了。
于是，经过讨论，修改如下，在确定设备有返回的时候在去下订单，即在MQTT应用层这一层去下订单。
这个算是订单流程系统的第二次发版，又过了大概一周，重新优化，原因是依然有个问题，那就是盒子发送指令到摇摇车依然不是百分之百靠谱能启动，这样导致用户要是扫码没启动，虽然没扣费了，但是平台也没下订单，没有订单依据，用户体验也不好。当初由于硬件这边条件上的限制，在设备这边流程上不能做到：盒子接受启动指令，发送指令给摇摇车，摇摇车收到指令回复盒子，盒子这个时候再返回信息到MQTT。
目前的硬件条件暂时还做不到这种流程，订单系统再次进行第三次发版，主要改动点如下：
1.用户扫码摇摇车，如果设备在线，账号余额充足，先下一个预扣费的订单，然后发送协议到MQTT。
2.盒子监听MQTT消息，收到消息，发送启动指令到摇摇车，然后上报消息（发送指令到MQTT）。
3.MQTT应用端监听上报消息，收到消息，并核对流水号凭证，这个时候才去做订单具体业务，包括用户扣费，商家分成，修改订单状态等操作。
这次改版虽然改进了用户扫码后没有反应，有数据追查的凭证，相对提高了用户的体验，但是盒子发送启动指令到摇摇车和盒子上报消息到MQTT依然是个并行的操作，依然存在盒子发送启动指令到摇摇车有可能不能正常启动的可能（包括摇摇车本身的问题导致），所以后续在摇摇车本身的质量上包括启动技术实现方案上需要不断的去改善改进。