车辆调度

为什么80%的码农都做不了架构师？>>>   

车辆调度系统   

大体上分为4个部分吧

1.调度车辆：你调度的时候需要的车辆，方便给你运输啥的

2.调度任务：你为啥会调度车辆，肯定要有一个任务

3.客户：那这个车辆为谁调度呢？

4.用户：谁创建了这个任务，并且发起了调度，或者是谁主导了这个任务

 

这些问题弄清楚之后，我们就可以想象一下这个流程了

 

客户发起了一个调度任务，用户去调度车辆执行这个任务，然后接到任务的调度车辆去完成这个任务。完成任务之后，客户接收到任务完成之后的结果，大功告成。

 

虽然说，这样分析起来很简单，但是简单的背后是复杂的逻辑关系

比如说：调度车辆怎么分配，每个调度车辆都是平等的关系吗？如果一个任务发送出去了，每个车辆都能接收到这个任务吗？如果说每个车辆都能接收到这个任务的话，时间和成本应该怎么算，谁去执行，怎么执行。等等这些问题都是要考虑的。

 

1.执行任务的时候，车辆都是哪里都有。所以肯定不是有任务都直接发送出去的

2.执行任务的时候，车辆调度的距离远近，结算也是不同的，所以肯定要求最优化解决方案

3.执行任务的时候，对时间也是有要求的

4.对质量和服务也是有要求的

5.如果调度车辆已经接了很多单子，肯定也不会让他们在接单了，影响执行速度

6.每个任务都有对调度车辆和司机的限制的，所以车辆类型和司机的整体也是有要求的

7.因为一些原因，迟到或者是出现问题的处理

等等一些原因，如果这些原因都解决好了，那么这些问题我觉得70%左右的问题都解决了。

 

之后我们来分析一下车辆调度的时候我们的实体该如何设计

1.调度车辆

      我们现在看到的大街上，好多送餐的车，像饿了么，美团，百度等等，你们看他们的车子，有很多不是自己的，也有自己的，像饿了么找的是蜂鸟快送，应该是吧，我忘记了，百度好像是自己的，是饿了么。实际上我觉得有一部分都是找的第三方的公司接的单。然后到一个月或者是一个季度结算一次，这些我就不清楚了。

这个问题说明，最少得有一个第三方调度公司表，然后我觉得还有区域表，在有个调度车辆表，还有一个登陆上线的司机表，为啥呢？

1.第三方调度公司表：很清楚了，就是车辆所在的公司

2.区域表：我觉得，这些车辆应该有一个位置范围，他不可能那里都跑，这也不合理

3.调度车辆表：这个就清楚了，需要调度的车辆

4.司机表：他们肯定得有个App或者是啥东西吧，等接受到任务的，我怎么知道他们能不能上线，肯定得有个表记录一下他们的上下线的状态啥的

 

 

2.调度任务

    调度任务：相比于我来说，我想点个餐，然后这个点餐这个过程，我觉得应该是先发起一个点餐的任务，然后后台接收到这个任务，接收到任务之后，在把任务分配给调度车辆，然后调度车辆接到这个调度任务之后把相应的东西运送到目的地，然后结束掉。

    首先啊，肯定要有个任务表，来记录任务，然后有个调度表，来记录任务调度的状态，比如说任务调度给了调度车辆，然后车辆开始执行任务，车辆到达目的地，车辆完成任务等等。之后呢还需要车辆提供一下在这个任务中行走的轨迹，我们好知道他到哪里了，方便给客户推送实时信息。所以说呢?这里面的表包括

1.任务表：记录任务的

2.调度表：记录调度车辆状态信息的

3.坐标轨迹表：可以清楚的了解车辆信息的位置的

       但是呢，这个估计还不全，因为上面讲到了，这个任务有可能是特殊的，我们可能还需要加一个扩展表来满足它的特殊性，然后每个任务都是要对司机进行结算的，所以我们要有一个结算表来记录司机和任务的结算方式的。所以：

1.任务表：记录任务的

2.调度表：记录调度车辆状态信息的

3.坐标轨迹表：可以清楚的了解车辆信息的位置的

4.任务扩展表：记录特殊信息

5.结算表：记录司机和任务的结算金额

 

 

客户：

客户涉及到车辆服务的人群，所以首先有个客户表，根据客户的需求，可以在扩展出来其他的表

客户表

 

用户

用户包括组织权限，菜单，权限，角色，岗位，部门等等

用户表

用户角色表

角色表

菜单表

角色菜单表

权限表

岗位表

岗位菜单表

部门表

 

转载于:https://my.oschina.net/ohalo/blog/882600