NAS自托管：基于OSRM与OR-Tools的探店行程规划实操

最近我养成了一个新习惯刷小红书的时候看见感兴趣的店和去处先不急着收藏而是顺手把地址或地名复制到一个本地落点列表里。为什么要绕这么一圈因为光靠收藏夹我踩过太多坑——收藏了三十多处周末打开地图挨个标记发现它们东一个西一个有的隔了四十公里怎么排都不顺路。后来我把这个活儿交给NAS去算效果出乎意料原来要花一晚上研究路线现在五分钟就出一份带顺序、带时间预估的行程单。这篇东西就把这套思路和整套搭建过程写出来适合手里有NAS、又经常出门探店的人参考。这套玩法说穿了不复杂用NAS上的Docker容器跑一个自托管地图服务、一个路线规划引擎再配一个专门收集种草点的小工具最终一键生成顺路的参观顺序。整个过程不需要云端地图服务的免费配额也不需要手动在一个个小圆圈之间连线数据全部留在自己的硬盘里。接下来我按为什么选NAS、方案怎么设计、五步实操、核心算法细节、常见问题排查五块来写。1. 行程规划这件事为什么NAS能插一脚1.1 手机App规划行程的痛点在哪先聊聊为什么旅行类App普遍解决不了顺路问题。小红书这类社区App本质是内容流收藏夹只是一个种草清单它并不关心这些地点在地图上的空间关系。你收藏的可能是三个不同的探店笔记分别位于城市的东南西三个方向而App给你的仅仅是一个按时间排列的动态流。等你真正出门只能靠记忆在地图上逐点标记然后凭感觉排路线。更麻烦的是很多地点笔记里的地址写得非常种草化比如老城区的巷子口看到红色铁门往里走。这种描述对人是浪漫的对机器来说完全没法定位。于是大多数人的做法是先在点评或地图App里一个个搜把坐标点上去再手工调整顺序。一次两次还能忍收藏到五十个以后这活儿就成了负担。我自己就经历过一次周末想一天逛完收藏夹里的十家店结果在地图上来回拖拽了两个小时最后实际路线还是绕了一个大圈。再退一步说即使你愿意花时间手动排人的脑子也不擅长处理十几个点之间的两两距离。直觉上觉得A和B近可能中间隔着一条河开车要绕二十分钟。这时候只有路线引擎给出的真实路网耗时才能客观回答哪个先去更顺。1.2 NAS为什么适合干这件事NAS和普通电脑最大的区别就是它是一台24小时不关机、电费还不太心疼的小服务器。你的Docker容器跑在上面等于家里重新拥有了一个可以随意安装服务的私有云主机。用NAS来排行程最直接的好处是路线引擎跑在本地调用次数不受限。市面上的地图开放接口单日配额通常卡得很紧算一次几十个点的最优路线可能要消耗掉你一整天的配额。本地跑OSRM这类开源路线引擎数据在自己硬盘上请求多少次都无所谓只要NAS的CPU和内存扛得住。另外NAS天然适合挂定时任务。你可以在每周五晚上自动把收藏夹里的新增地点拉取下来滚动进候选池到了周末直接生成推荐行程。这种数据沉淀自动化的玩法是手机App没法给你的——你用过的每一个坐标、每一条路线都会留在NAS里时间越长这份本地数据越有参考价值。1.3 这套方案适合谁我不建议所有人都照着搭一遍。如果你出门只去一两个地方手机地图已经完全够用但如果你属于下面几类人这套方案会特别值收藏夹里攒了两百个以上地点但周末真正能去十不存一的探店党喜欢把数码设备和日常生活串在一起折腾的NAS用户经常替朋友做本地两日游导游的人——把朋友想去的地方丢进NAS算完直接导出路线发到群里。我就是第三种人。每次朋友来问想去哪答案永远是随便但真到了选路线环节又各有偏好。现在我不纠结了把这些偏好录进NAS让它自己算一条平衡路线比一群人围着一台手机争论半小时有用得多。2. 核心方案设计从种草到成行2.1 整体架构一条四段式流水线我的设计思路是把排行程拆成四个环节采集收藏地点、地址、标签统一落进NAS上的一个CSV或JSON文件。解析把地址转成经纬度这一步叫地理编码。规划用路线引擎算出路网距离和耗时再用优化算法安排遍历顺序。展示把结果渲染成一张带地图的行程看板同时导出KML/GPX供手机导航使用。这套流水线很像外卖的出餐流程采集成单、解析是备菜、规划是炒菜、展示是装盘。最关键的不是某一环有多强而是每一环的数据格式能互相衔接。我的经验是宁愿在采集端多花点时间做标准化也不要等排程时才去处理脏数据。比如CSV里的地址统一用市辖区街道门牌格式比零散的种草文案可靠得多。2.2 关键选型地图数据、路线引擎、前端界面排行程最核心的依赖是路网数据。开源生态里最常用的路网数据源是OpenStreetMap这种开放地图数据可以直接装进PostGIS也可以配合路网处理工具生成路由文件。我不讨论数据本身的来源细节只说用法把目标区域的OSM数据导出来后要让路线引擎能读它。NAS上这一步操作用Docker镜像即可完成不需要额外安装庞大的图形工具。路线引擎我推荐从OSRM、Valhalla、GraphHopper三个里选。三者的差异可以做一个精简对比引擎优点缺点推荐场景OSRM启动快、内存占用中等、API简单多模式/避让规则较弱单日自驾、骑行路线Valhalla支持步行/驾车/多模式时间窗能力强配置复杂构建路网耗时城市漫步、多日行程切分GraphHopper内存最省Java生态支持自定义权重速度略慢低配NAS、长时间后台计算我实际常用的是OSRM理由很朴素它的预处理和启动最省心一个car配置文件就能跑API文档也清楚。对于从A到B再到C的经典路线计算OSRM完全够用。如果你家里那台NAS内存只有4GB可以优先考虑GraphHopper它对低内存环境的容忍度更高。前端展示端我用MapLibre GL JS做地图渲染配一个简单的Flask或FastAPI页面。其实前端不是重头戏能一眼看清路线顺序就行我甚至试过直接用手机浏览器打开NAS生成的静态SVG路线图效果也还行。关键是把可视化作为辅助而不是为了好看把系统越做越重。2.3 容器编排与目录规划NAS上的Docker环境我按一个项目一个文件夹来管理。以一个名为trip-planner的项目为例目录可以长这样/volume1/docker/trip-planner/ ├── compose.yaml ├── data/ │ ├── osm/ # 原始路网数据 │ ├── tiles/ # 地图瓦片 │ ├── geocoding/ # 地理编码数据 │ └── trips/ # 历史行程和导出文件 ├── scripts/ │ ├── collect.py # 采集收藏夹 │ ├── geocode.py # 地址转坐标 │ └── plan_trip.py # 调用OR-Tools排程 └── web/ └── index.html # 行程看板容器方面我会跑四个服务PostGIS可选、OSRM、瓦片服务、Web前端。也可以再加一个Photon做离线地理编码。如果NAS内存只有8GPostGIS可以砍掉直接使用文件导入路网数据。这里想强调的是架构不追求大而全先跑通路线计算顺序优化这条主线后续再补地理编码和花哨展示。初次上手就搭六个容器出问题时你都分不清是哪个环节坏了。3. 实操五个步骤把行程管家跑起来3.1 准备NAS环境先把Docker跑起来。群晖的Container Manager、飞牛的Docker模块、绿联的Docker应用本质都差不多找到套件中心安装开启后确认能跑docker compose。新版群晖和飞牛都支持通过一个docker-compose.yml文件一键拉起多容器这一点很关键后面的服务我全用Compose来管理。然后给NAS设置一个固定的局域网地址。如果NAS的IP每次重启都变后面配置容器间互相访问和DDNS都会很痛苦。我习惯在路由器里给NAS绑定DHCP静态地址比如192.168.31.10。顺便把路由器的端口转发设好把NAS的5000、8080这类服务端口映射出去再申请一个DDNS域名这样人在外面也能打开行程看板。这件事看起来和行程规划没关系但实际使用时能在手机上看路线比只能在客厅看重要得多。最后建好项目目录。NAS上建议把所有Docker项目集中放比如/volume1/docker下面按项目名分文件夹以后再跑别的工具也不会乱。建好后可以顺手跑一个docker --version和docker compose version确认环境就绪。3.2 部署地图瓦片服务地图瓦片是前端地图的底图。我不打算占用太多篇幅讲瓦片生成细节只提供一个最小可行方案把想要覆盖区域的瓦片下载好放到data/tiles/目录下然后用一个静态文件服务器容器把它跑起来。瓦片目录组织形式应该是/tiles/{z}/{x}/{y}.pbfMapLibre的style里对应的source url指向它即可。如果瓦片数据量不大比如只覆盖你常活动的几个城市整包可以控制在几百MB到2GB之间。需要注意几个点磁盘空间瓦片数据虽然比原始卫星图小但覆盖范围一大体积涨得也快记得先裁剪到最常活动的区域。目录层级一定按z/x/y三级目录放文件否则MapLibre找不到瓦片。容器权限挂载目录要设置好宿主权限NAS上最常见的故障就是容器内读不到挂载目录里的文件。我自己第一次跑时瓦片包下载了两天结果访问地图一片空白。排查了半天才发现是目录层级少了一层。地图组件会直接按标准ZXY规则去请求目录不对就404页面上一行报错都没有非常隐晦。3.3 部署路线规划引擎以OSRM为例三步走下载路网数据文件、用OSRM镜像做预处理生成路网索引文件、启动对外服务。在NAS的终端里依次执行假设已经在项目目录下docker run -v $(pwd)/data/osm:/data ghcr.io/project-osrm/osrm-backend \ osrm-extract -p /opt/car.lua /data/region.osm.pbf docker run -v $(pwd)/data/osm:/data ghcr.io/project-osrm/osrm-backend \ osrm-contract /data/region.osrm docker run -v $(pwd)/data/osm:/data -p 5000:5000 ghcr.io/project-osrm/osrm-backend \ osrm-routed --algorithm mld /data/region.osrm第一条命令是把原始路网数据转成OSRM内部格式第二条是做多层级道路索引第三条才是真正对外提供HTTP接口。这三条命令看起来很像但缺一不可。这里有一个非常容易踩的坑--algorithm mld是内存优化算法内存占用比默认的CH算法低很多。我在8GB内存的NAS上跑用mld模式处理一个中等城市的区域非常稳如果换成默认模式预处理阶段可能会直接内存溢出。跑起来以后用浏览器访问http://NAS_IP:5000/route/v1/driving/116.4,39.9;116.5,39.92这样的URL就能验证接口是否正常。返回的JSON里的routes[0].duration和distance字段就是后面排程要用的核心数据。3.4 搭建种草收藏与解析器这一步解决的是小红书收藏夹里的地址怎么进NAS的问题。我的做法不复杂也不去逆向平台接口而是用最稳妥的办法每周花五分钟把新收藏的地点批量粘贴到一个CSV文件里格式固定为名称,地址,标签,备注然后让NAS上的脚本去处理。CSV样例长这样名称,地址,标签,备注 山野咖啡馆,某区某路12号,咖啡,拍照视野好 旧书店,某街巷3号,书店,老板会聊文学 日落观测点,某山步道入口,观景,下午四点到最合适接下来用Python脚本调用自建的Photon地理编码服务把地址转成经纬度。Photon是一个支持离线检索的地理编码容器在NAS上起一个实例非常简单services: photon: image: komoot/photon:latest ports: - 2322:2322 volumes: - ./data/geocoding:/photon/photon_data首次启动它会下载索引数据这个过程比较慢等它跑完以后再查询。查询接口长这样curl http://NAS_IP:2322/api?q某区某路12号limit1返回的JSON里geometry.coordinates就是经纬度。从CSV到坐标的数据流我建议在geocode.py里做两件事一是自动请求并做缓存同一个地址不要反复调用二是解析失败时把记录单独写到unresolved.csv等人工补充坐标。小红书笔记里的种草风地址经常不规范宁可先把明显不完整的地址筛掉也不要让它们污染后面的排程计算。3.5 一键排程让NAS算出顺路的逛法当所有地点都有经纬度后就到了最核心的排程环节。这里的数学问题是一个变体的旅行商问题TSP给定N个点找一条从家出发、依次经过每个点、最后回到家的最短路径。NAS上的方案是使用Google OR-Tools的Python库做启发式求解。我写了一个plan_trip.py逻辑分四段读取所有地点的CSV建立点表对任两点调用OSRM的距离矩阵接口得到路网距离和行车时间把数据喂给OR-Tools的RoutingModel求解把解出的顺序写进一个JSON文件并额外生成KML/GPX。距离矩阵的调用长这样import requests, json def distance_matrix(origin, dest): base http://localhost:5000/route/v1/driving coords f{origin[1]},{origin[0]};{dest[1]},{dest[0]} r requests.get(f{base}/{coords}, params{overview: false}) route r.json()[routes][0] return route[distance], route[duration]OR-Tools部分最关键的是设置车辆起点为家坐标并让每个点只访问一次。为了方便理解下面是简化版的核心求解配置from ortools.constraint_solver import routing_enums_pb2, pywrapcp manager pywrapcp.RoutingIndexManager(len(locations), 1, home_index) routing pywrapcp.RoutingModel(manager) def cost_callback(from_index, to_index): from_node manager.IndexToNode(from_index) to_node manager.IndexToNode(to_index) return int(distance_matrix[from_node][to_node]) transit_callback_index routing.RegisterTransitCallback(cost_callback) routing.SetArcCostEvaluatorOfAllVehicles(transit_callback_index) search_parameters pywrapcp.DefaultRoutingSearchParameters() search_parameters.first_solution_strategy ( routing_enums_pb2.FirstSolutionStrategy.PATH_CHEAPEST_ARC) solution routing.SolveWithParameters(search_parameters)这里有个细节OR-Tools默认做的是最小化总路程但实际出门时中午吃饭景点开放时间这类约束也很重要。我的做法是在生成点的过程中把硬约束设成时间窗再提供给OR-Tools比如规定午餐候选地只能安排在11:30到13:00之间。第一次跑通的时候不需要加这些等基础流程稳定了再逐步加约束。排完序后前端会把日程渲染成09:30 到访某咖啡馆 → 11:00 前往旧书店 → 14:00 登山看日落这样的卡片列表同时在MapLibre地图上画出折线路径。这一步信息量不小但体验上就是打开一个网页、点一下生成今日行程按钮。4. 排行程的核心算法与细节4.1 顺不顺路的本质路线成本计算很多人以为顺路就是地图上看起来近其实真实路况里直线距离根本不靠谱。城市里一条河可能把两个直线距离五百米的点隔成绕行三公里高峰期某个高架入口可能排队很久。路线引擎解决的就是这个问题OSRM基于真实路网做最短路径计算返回的距离和耗时才是真正意义上的成本。NAS上的距离矩阵本质上是在所有点对之间都算一遍这种真实成本。点对数量是N的平方如果一次要排20个点就是400次请求本地引擎几秒钟就能全部算完。换云端API就是另一回事了别说配额光看着请求列表里一行行跳数字就心疼。4.2 打卡点去重、聚类与多日切分当收藏夹涨到几百个点一次性跑TSP会得到一条横跨整个城市的疯狂路线。这时候需要引入两层预处理。第一层是去重。同一个地点被多个笔记反复收藏很常见我写了简单的相似度判断名称或地址里的关键词重合度超过一定阈值就合并优先保留带坐标的那条记录。第二层是聚类。我的经验是按区域先分组、组内再排序比直接全局TSP效果好得多。可以用二分法或按商圈划分把城市分成东、西、南、北几个片区每天安排只跑其中一个片区第二天再换另一个。这样既符合不赶路的旅行节奏也让路线规划的计算规模小很多。多日切分就一句话把TSP拆成区域选择单日TSP两级。先用聚类把点分进各个片区再对每天的候选点分别调用OR-Tools这样每一份运算都能在两秒内出结果。4.3 一个可落地的打卡点评分思路排行程不只是TSP还要回答今天到底去哪些点。我给每个收藏点设计了一个简单的评分公式score 0.4 * 关注热度 0.3 * 地理集中度 0.2 * 当日时间窗匹配 0.1 * 备注优先级其中关注热度可以来自收藏次数、点赞数这类相对排名地理集中度是该点离当天规划片区中心距离的倒数用来保证选出的都是顺路点当日时间窗匹配用来排除下午三点以后才开门这类和行程冲突的店。评分高的点优先进入当天的TSP点集。这个评分公式不用做得很复杂重要的是给你一个手动调整的抓手。我自己的习惯是每周五跑一遍脚本把TOP 12的点输出成一个候选清list周末再从里面挑。整套流程跑顺以后你会发现规划行程这件事终于不再靠拍脑袋了。5. 常见问题与排查速查表5.1 地图瓦片加载不出来最常见的原因不是容器没起而是瓦片路径层级不对。MapLibre请求的URL是/tiles/{z}/{x}/{y}.pbf如果你的瓦片文件放在了data/tiles/12/3410/1628.pbf但容器映射时把目录映射错了自然404。排查时先在容器外部用curl访问一下瓦片URL看返回是200还是404。另一个常见原因是NAS的防火墙或路由规则拦了5000、8080等端口。Docker容器端口映射出来后还需要确认宿主机防火墙放行了对应端口群晖和飞牛的防火墙套件默认会拦掉很多外部端口。5.2 路线引擎内存爆掉OSRM预处理阶段最容易内存溢出。解决办法有两个一是改用--algorithm mld这是内存优化算法二是缩小路网数据范围不要整省整国地导入只裁你重点关注的城市及周边三十公里。另外预处理阶段不要同时跑其他重负载容器我试过一边跑下载任务一边预处理NAS直接卡死等了大半小时才恢复响应。5.3 地理编码解析失败小红书笔记里的地址有两类一类是规范的某区某路某号一类是巷子口看到红色铁门往里走。后者我基本放弃自动解析直接靠人工在收藏清单里补充坐标。给CSV增加一个_lat,_lon可选的列如果程序解析失败该行的坐标列留空人工填一次即可。记住一个原则解析不了的点宁可先排除也不要让错误坐标污染距离矩阵。错误坐标会让路线引擎规划出一条穿墙路线体验非常奇怪。5.4 手机在外面访问行程看板很慢NAS在家里通常走的是宽带上行链路带宽不高。如果前端页面加载了大量高清瓦片手机在外面访问就会很卡。我的做法是给前端页面做一个精简模式默认只显示路线折线和打卡点标记不加载高清底图只有点进详情才临时拉瓦片。另外把瓦片数据做成多级缓存常用城市区域提前预取能明显改善体验。5.5 容器镜像拉取失败如果因为网络原因导致Docker镜像拉不下来先检查NAS的镜像源配置确认网络策略是否放行了对应镜像仓库域名。不要在这种问题上花费太多精力直接确认项目目录和Compose文件格式没写错比纠结拉镜像更有价值。镜像拉取属于一次性成本解决了以后基本不会再碰。5.6 排查速查表现象可能原因排查/处理办法瓦片404目录层级错/文件缺失curl瓦片URL检查容器挂载路径路线引擎启动失败预处理文件损坏/内存不足重新生成索引换mld模式地理编码返回空地址太模糊人工补坐标写入CSV的坐标列外网访问很慢上行带宽不足/底图过大开精简模式预取瓦片定时任务没跑cron时区不对检查NAS系统时间和脚本日志Compose拉不起镜像名写错/镜像源受限核对Compose语法检查镜像源写到这里再说点我自己的体会。最初给NAS搭这套行程管家纯粹是因为收藏夹太乱没想到跑通以后整个种草—成行的闭环变得特别自然小红书里看到想去的地方顺手记一笔周末前让NAS算一算出门照单走基本不用再在地图上划来划去。我最大的教训是别把系统一开始就做得太复杂地理编码、瓦片、路线引擎和TSP这四件事先各自跑通再拼起来成功率会高很多。后续我还打算把行程描述生成接到一个本地大模型上让它自动把每天的行程翻译成09:30 咖啡11:00 逛书店下午爬山看日落这样的自然语言提醒。如果你也在折腾NAS不妨从一份CSV和一次OSRM调用开始你的收藏夹会感谢你的。