东郊到家开发技术服务

东郊到家系统架构

目前主流的按摩软件系统会有三个端口：用户端、技师端、商家端，以及管理后台。
上门预约的操作
1、技师管理。

技师满意度进行统一跟踪评估，进行分级管理，分级评估；

2、订单管理。
按订单状态分类筛选，安装进度一目了然；

3、智能派单。

根据客户位置、技术人员效率、技能和时间智能分配技术人员，提高效率。

上门预约流程
1、消费者填写预约信息：联系方式，姓名，省市区地址，上 - 门详细地址，还有选择具体时间，即可预约成功，系统在后台即可看到预约信息，可线下电话联系，也可直接上门。

东郊到家的优势 对比传统线下、其他垂类的上门服务，

东郊到家的优势主要有：

利用互联网技术和互联网思维，高效管理数以万计的劳动者，服 务质量不断迭代优化。 2、利用 LBS 技术、集中调度算法让劳动者和用户的连接最高效，大幅 提高劳动者收入和用户体验。

3、构建上门服务综合平台，借助品牌联合运营和大数据技术，形成 平台合力。

订单调度系统介绍

1、订单调度系统的作用 输入：订单、服务者 输出：订单和服务者的绑定关系

2、到家服务预约模式 预约调度：以家政、美甲为代表 用户预约 1~7 天后使用服务 商家以接受派单为主，上门方式是公共交通

3、预约调度的核心技术点 劳动者浪费在通勤时间尽量少，提升劳动者体验，也提升劳动者接 单数 按距离筛选的优化 早期按直线距离筛选，存在不少问题 过度方案，缓存离线网格 目前应用多终点距离测量接口 订单间距离优化：让浪费在路上的时间尽量少 派单时候考虑前后单的服务地点 订单按距离聚类优化，让阿姨批量消灭订单

预约调度架构

1、订单 “系统”（第一个月） 业务量：日均单在百单左右，劳动者数量在百人左右。 需求：能把订单派出去就行 实现：一张订单表记录订单，mis 后台用于客服操作记录订单状态。 ≈ excel

2、存在问题 1、对劳动者体验差，不断受到客服电话骚扰，需要自己记住订单安排 。 2、对用户体验差，订单量上来之后，导致订单积压，客服忙不过来， 用户的订单得不到及时响应。 3、对客服体验差，每派一单需要打平均 7 通电话。

3、订单系统（第三个月） 业务量：日均单过千单。劳动者过千人。

需求：客服人肉已经无法应对，急需优化派单效率让用户得以快速响应。

1、开发用户端和商家端 app，接派单降低对 400 客服的依赖。

2、初步商家管理系统，记录商家住址经纬度，实现按坐标排序功能。

3、开发抢单功能，让劳动者自己抢单。

4、订单系统 派单调度模块选取订单服务 地址距离商家位置由近到远 进行推送 商家接单后返回用户接单成 功

存在问题

上门服务不是打车，上门服务绝大多数是预约制，打车绝大多数 是实时需求。所以抢单在打车行得通，上门服务行不通。

2. 劳动者学历偏低，对 app 负责使用不适应。

3. 劳动者的接单距离、时间管理问题等派单效果问题开始凸显。

订单「调度」系统

业务量：日均单峰值过万单，劳动者数千人，业务线三足鼎立（家政 、丽人、搬家） 需求：解决订单超售问题，提升人均接单量。

实现：

从抢单改为派单，由系统安排劳动者日程，商家端只做确认。
劳动者库存系统，和用户端联动，避免超售。
每个商家有一个接单半径，落在这个半径的单才会被推送。
用通勤距离代替直线距离，因为实时调用地图接口性能无法接受， 建设了一个离线距离模块。

订单调度系统

用 bitmap 记录每个劳动者最 近 1 周的时间安排，派单成功 后会占用相应时间。 商家拒单后会重新选择新的 商家派单，重派失败由客服 介入。 离线地图网格是把一个城市 划分成一公里见方的小方格 ，预处理任意两个方格之间 的通勤距离。

存在问题

业务特点是劳动者少，订单多，接不过来。需要进一步优化人均接 单量。

2. 随着业务深入，从单纯追求订单量慢慢转变为既保证订单量，又要 提升整体订单收益。 3. 品类继续在增多，劳动者也继续在增多，劳动者会出现各种各样的 状况，比如临时请假、缺席等。

订单调度系统的未来规划

业务量：2015 年年底的目标是峰值 10 万单，并且接入不少于 5 家三方服 务。 需求：实现高订单饱和度，低通勤距离。综合考虑订单量和订单收益 。实现通用平台接入

未来规划

用户分级，优秀用户优先派单。
集中派单 + 综合考虑劳动者临近时间点的订单，缩短中间路程。
订单分级，引入动态定价。
劳动者分级，优秀劳动者有更多接好单的机会。

5. 把订单调度模块插件化，不同业务可以定制自己的调度逻辑。

实时调度的技术核心

需要在最短时间内撮合商家和订单 实现：搜索 + 推送 + 抢单 搜索商家条件：订单距离、商家权重 商家实时返回当前定位 商家权重（好评率、培训程度、商户用户紧密度） 里程计算： gps 漂移：定位 api 返回精度、前一个点距离、道路吸附 gps 点缺失：调用导航距离来弥补

实时调度架构

LBS 技术的应用 实时定位、导航 里程计算：目前准备借力高德地图的出行类 LBS 解决方案，结合我 们自有的业务策略来优化里程计算功能

数据分析技术的应用

数据分析与挖掘

订单维度

基于地理位置的人群画像，获取潜在用户群，平台内品类运营更加 精准。
商圈维度、小区维度的订单量分析，使得地推更高效。

劳动者维度

劳动者出行路线分析，关键路径增加班车提高通勤效率。

2. 基于区域的订单量饱和度与劳动者数量分析，指导劳动者招募

区域化订单分析 根据用户分布、地形、交通 划分商圈，按商圈就近派单 根据商圈饱和度和用户需求 智能调度商家和精准市场推 广 根据商家数据个性化商家运 营管理

小区地推系统 小区用户画像，目标客户群 精准定位 小区潜在用户规模评估，用 户渗透率，地推效果跟踪记

动态补贴模型

根据商圈历史数据以及用户 和商家行为数据等建立数据 模型动态补贴，提升订单响 应率。 商圈精准市场活动，量化市 场活动效果和后续跟踪，提 高市场推广效率，降低推广 成本。

数据库基础规范

1. 必须使用 InnoDB 存储引擎

解读：支持事物，行级锁，并发性能好，CPU 以及内存缓存页优化使得资源利用率高。

2. 必须使用 UTF8 字符集

解读：万国码，无乱码风险，无需转码，节省空间。

3. 数据库表，字段必须加入中文注释

解读：N 年之后，谁 tm 知道这玩意是做什么的。

4. 禁止使用存储过程，视图，触发器，Event

解读：高并发大数据的互联网业务，架构的设计思路是 “解放数据库 CPU，将计算转移到服务层”。在并发量大的情况下，这些功能很可能将数据库给拖死，业务逻辑放到服务层具备很好的扩展性，能够实现增加机器就增加性能。数据库擅长存储于索引，CPU 计算还是上移吧。

5. 禁止存储大文件或大照片

解读：为何要让数据库做它不擅长的事情，文件存储在文件系统，数据库保存 url 即可。

表设计规范

6. 单实例表的数目必须小于 500。

7. 单表列数目必须小于 30。

8. 表必须有主键，例如自增主键。