一个调度系统的表面研究

整个调度系统的研究
1.逻辑是先捕捉车载地图，才可以在monitor上显示出来。
调度系统与引擎之间有缓存
或者之前捕捉过(指的是全部都重新关闭，然后先开程序集，再开车载也行，是由于两者之前已经建立了联系。若删库的话，则就完全不一样了)，已经建立了连接，那么就可以完成。
没有任务run还是dispatch状态
添加任务error的情况：
1.莫名奇妙停止仿真车的运行
车子直接finish,结束并没有compele.托盘名称放错，不会报错的。直接finish
2.很久没开调度系统
调度系统有现存的active任务，并且取消的话就会出现奔溃恢复。(复现：就是由于之前的托盘类型发错了，导致的，并没有在运行的时候检测托盘类型的变化，但它为何会一直奔溃恢复呢)

部署到服务器上还是比较困难

困难的点在于外网很难访问
关键在于就算部署成功，车载也无法访问外网：

模拟车载 agv shell发送对应模拟车载的程序
车载是本地才可以连接上么，我想应该是的，它应该捕捉不到外网ip的到来（车载关闭之后会报错Network Disconnect）

尝试解决方法可以试试xpress

整个调度系统的架构(7个)

(待详细补充)
或者说启动起来的顺序
整体都是遵循模块化开发原则，
web_monitor->om(om啥时开都可以，它是接收订单，然后执行任务的)->restapi(最重要的，承上启下(页面，数据，调度))->dispatch-engine->仿真车载
发现的点
om是管理任务的，要是没开om，仿真车就不会动，创建的订单也会一直waiting,task页面空白
om查看所有发送的任务，并且web界面和引擎跑起来的车是同步的，引擎已关闭，车就会停止

总结调度系统的7个组成部分

dispatch调度打开马上生成很多日志打印阿来
rest_api打开在linux上中断安ctrl c 退不出去。他会一直等待保持着那种状态
om可以按ctrl + c 退出
webmonitor 的启动脚本在linux中可以不用给他赋予权限，他整个调度系统还是可以跑起来；赋予权限跑起来，可以看到很多api;最多的是/api/custom/replay/all/)(http://192.168.252.144:2000/api/custom/replay/all/)
引擎启动会持续不断的刷新捕捉状态(刷新日志 按ctrl + c可以退出)，但后台进程却没有退出
maintenanceserver在Linux中也没有权限运行，按ctrl + c可以退出
WebGrace是整个调度系统的维修平台按ctrl + c可以退出

查找问题的先决条件

om-rest_api-dispatch-engine-车载(一个一个查)
要是车载也就是车不动的话，是不是最好一个一个查(反着查)

调度系统OM层面的研究

重点
这是由于我们所有的技术支持都是在om层引起的，只要om的订单(error)或任务(handle)然后就完蛋，就要来找我们查找。

在这里总结om层常常出现的问题

handle

1.之前做的卡住了，然后重发订单，重启程序集，
前面发的订单任务就会之后做，然后强制结束，就会handle
2.

杂

run_asgi 在哪看 就是webmonitor
dispatch也坑是最大的，启动一定要加个
配置文件 run_asgi打开后台程序打不开shell语句写错，或者我的配置错误

manager就是 runasgi也就是webmonitor
数据库错误，或者数据库版本有些问题，网页上会报websocket 断开连接