117 lines
7.8 KiB
Markdown
117 lines
7.8 KiB
Markdown
---
|
||
title: 后台系统功能设计
|
||
mdate: 2026-03-19 15:26:46
|
||
mdevice: lazy的MacBook Air
|
||
doc_id: 2d7921bcb33d47768945bb8f8d9a8e08
|
||
date: 2026-03-18 15:27
|
||
---
|
||
|
||
# 后台系统设计
|
||
## 1. 账号体系
|
||
### 1.1 用户设计
|
||
初始设计五种用户类型，分别为永东注册用户、内部员工、员工家属、代理商、认证机器
|
||
- 注册用户
|
||
对象：购票、旅游、演唱会等方式引导注册的用户。对应现有的 【永东友】用户
|
||
入口：App、小程序
|
||
主要权限：浏览、购票、订单、管理个人信息
|
||
|
||
- 内部员工
|
||
对象：永东工作人员，对应不同的功能组（检票、售票）和部门（站务部）
|
||
入口：后台系统、检票 App、司机 App
|
||
主要权限：根据各部门的职责进行灵活配置，内部员工具有创建员和管理员工家属的权限
|
||
|
||
- 员工家属
|
||
对象：内部员工的家属，需要与员工绑定，由员工账号进行注册和内容变更
|
||
入口：内部系统员
|
||
主要权限：浏览和申请员工家属福利。
|
||
|
||
- 代理商
|
||
对象：系统认证的代理商。主代理商由系统负责代理商管理的职能账号进行注册，子代理商由主代理商进行注册和管理。
|
||
入口：内部系统代理商通道
|
||
主要权限：代理商模块、购票模块、管理子代理账号（增删改子代理账号，并限制可创建账号的最大数量）。最终权限需要由永东进行确认
|
||
|
||
- 认证机器
|
||
对象：经过永东认证的设备，如自动售卖机、TVM 机等，需要绑定机器账号、机器码、所属部门等相关信息。系统必须还有机器管理的页面，建议由电脑部负责进行统一管理。
|
||
入口：对应的部署程序以及初始运行的账号。
|
||
主要权限：用机器运行的程序对应的账号作为权限设置。例如通过创建机器角色来赋予其主要权限。
|
||
|
||
### 1.2 权限设计
|
||
- 功能：每一个 API 对应一个功能，每个功能必须在后台系统进行登记
|
||
- 功能包：由系列的功能组成，绑定的是功能 IDs
|
||
- 角色：根据职能来决定其可使用使用的功能包（功能包 IDs）
|
||
- 用户：一个用户可以绑定多个角色（角色 IDs）
|
||
|
||
## 2. 站点和线路设计
|
||
### 2.1 城市和地区设计
|
||
- 区分城市和地区。解决港人对内地城市传统惯性认知。每个站点均需要绑定城市和地区。
|
||
>内地习惯为【市-区/县-站】，香港习惯为【市/县/区-站】，例如佛山市，港人习惯为佛山、南海、顺德并列。
|
||
- 站点绑定。站点必须绑定真实的经纬度坐标，同时可绑定城市和地区两套规则。
|
||
- 站点二维码。每个站点均可生成二维码，利用二维码实现扫一扫快捷购票功能。即默用户在扫码时默认使用该站点作为搜票的起点。
|
||
|
||
### 2.2 口岸
|
||
强化口岸属性，口岸属于线路的必选点，需要跟线路进行强绑定。
|
||
> 快捷购票的需要，在自助机上已经默认设置了购票起点的位置，终点直接指向口岸即可选择班次
|
||
> 口岸需要每个时段对汇入汇出的客流进行统计
|
||
> 通过购票/上车和到达口岸的时间，对班次进行调度优化
|
||
|
||
### 2.3 线路
|
||
- 线路关联站点（IDs），通过站点的排序来形成线路
|
||
- 线路必须绑定口岸 ID，通过【线路-班次】实现对口岸客流统计
|
||
- 一条线路只关联一个口岸
|
||
- 线路具备【基础价】属性，这个基础价将会在线路的所有班次中应用。线路基础价由站点区间计价得出。
|
||
|
||
## 3. 排班设计
|
||
### 3.1 班次
|
||
班次包含线路（线路 ID）、时间信息、站点序列（站点 IDs）、站点属性、可售票数、票价策略（策略 IDs）、售票状态等关键信息。
|
||
- 线路：线路是班次的基础载体，在常规班车运营中，一条线路会有多个班次生成。
|
||
- 班次号：用于标识班次，有固定的名称规则。
|
||
- 时间信息：班次的发车时间、区间时间（到站时间和区间时长）、到达时间（到达口岸/终点站时间和时长）
|
||
- 站点序列：从线路获得的关联站点集合，具有前后顺序（可以理解为站点数组）。
|
||
- 站点属性：同一站点在不同的班次具有独立属性，可单独设置如站点上（可售票）/下车属性、放票数量等。对于班次来说，【班次站点】是【站点】对象的一个映射，每个班次均会对所经过的【站点】做一次拷贝，并重新赋予新的信息，因此会有【班次--站点】对照表。
|
||
- 可售票数：在排班时预设的对外供给的票数
|
||
- 票价策略：每个班次均从【线路】中获得一个基础票价，用于日常对外定价。票价策略是设定票价上/下浮调整、实施时间、实施时长等的开关。一个班次可以应用多个策略，最终票价则由【后台计价】程序根据策略进行叠加计算。
|
||
- 售票状态：班次的售票开关。排班后确定班次信息才可以开放售票。后期可以通过【售票状态】和【可售票数】来分时段放票。
|
||
|
||
### 3.2 排班
|
||
排班一般分为固定排班和加班两种情况。
|
||
- 固定排班：根据运营线路每天固定时间点创建班次。目前永东在香港部分，各线路大概 20 分钟一班车，始发站发车时间相对固定。
|
||
- 加班：基于监测数据对某条线路进行加开班次。可以理解为线路的支援班次。一般会根据过去 2-3 天的监测统计结果，决定是否对该班次进行加班。加班车不一定从线路的始发站发出，它将由站务通过统计数据发起，并指定发车站点和发车时间，由车务部服务派发车辆和司机。
|
||
> 偶尔会出现临时加班的情况，一般发生在大型活动或大型节假日，口岸处出现大量乘客，这时才需要当天紧急加班。能否成功加班，视车务部是否能调出司机和车辆而定。
|
||
|
||
### 3.3 排班操作
|
||
排班操作分为单班排班、单日排班、一键排班三种操作。以下操作均针对【单条线路】的排班设计。
|
||
- 单班排班。按照排班的要求，排单个班次，包含上述【班次】中所有的信息。
|
||
> 单班排班可以使用【单班模板】对连续多日的这个班次进行统一应用，实现快捷排班。
|
||
- 单日排班。针对每天固定的班次记录，进行整体排班。如周一至周五，该线路每天固定 40 班，可以实现工作日每天覆盖排班。
|
||
> 单日排班可以结合【单日模板】对指定日期（整天）或连续多日进行快捷排班。
|
||
|
||
### 3.4 排班模板
|
||
- 单班模板。针对线路某个班次设定模板，该模板可以赋予某天或多天的这个班次。
|
||
- 单日末班。针对线路某天所有的排班设定的模板，该模板可以生成该线路的全天排班。
|
||
|
||
### 3.5 排班模板制作和应用
|
||
- 单班模板制作。选择某个班次，将该班次直接转换为单班模板。
|
||
- 单日模板制作。选择完成排班的某天，将这天所有的排班记录转为模板。
|
||
- 模板管理。独立的排班模板管理工具和界面。
|
||
- 模板使用技巧。单班模板可以根据某个时段的某一班车进行应用，如高峰期的某一辆班车。单日模板可以针对工作日、休息日、大型节假日进行创建和设定。使用排班模板可以实现类似【一键排班】功能。
|
||
> 排班模板与线路关联。
|
||
|
||
### 3.6 加班操作
|
||
- 加班监测。加班监测会在【站务 App】上完成所有的监测和信息流转，后台将会根据统计数据和加班阈值进行加班提醒。
|
||
- 快捷加班。在需要加班的班次条目上，增加【加班】操作，直接复制该班次信息，并按【加班命名规则】自动递增班次号，指定上车站点等操作。
|
||
> 加班将会联动站务监测、排班调度、派车等过个业务。系统已经考虑增加站务、车务的信息化应用，加班的复杂过程和前置工作量将会大量缓解。
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|