做海外版外卖平台这件事我在过去几年里一直没停过。从帮东南亚本地生活公司搭第一版外卖系统到后来参与拉美、中东几个项目的架构改造最大的感受是外卖平台的难点从来不在“点餐-接单-配送”这条主链路本身而在你把这些流程塞进不同国家、不同习惯、不同基础设施之后原本简单的事都变得不简单了。这篇攻略围绕技术架构展开讲讲一个面向海外市场的平台应该怎么搭从模块拆解、多区域部署到实战避坑尽量给到可以直接参考的细节。不管你是创业公司从零起步还是成熟团队准备做出海产品这篇文章应该都能给你一些帮助。1. 海外版外卖平台的整体架构思路1.1 先搞清楚海外市场与国内市场的本质差异很多人一上来就翻国内外卖平台的架构文章照着微服务、中台、大促方案去规划。我建议你先停一下海外市场跟国内市场的打法本质上是不同的这些差异会直接影响技术选型。第一是用户密度。国内一二线城市的人口密度摆在那一个配送范围里可能有上千个活跃商家。但海外很多地区是低密度市场尤其是拉美、东南亚的非核心城区配送半径动辄5到8公里但订单量却比不上国内一个街道。这意味着你的配单逻辑不能照搬“高峰大量爆单”的模式反而要花更多精力处理低频、长距离、骑手路径规划的问题。第二是支付方式极度碎片化。国内基本是微信支付和支付宝两分天下但海外市场一个区域可能同时存在银行卡、本地电子钱包、货到付款、银行转账、甚至线下便利店扫码支付等多种渠道。技术架构上必须支持灵活的支付抽象层否则每接一个国家就要改一遍订单资金流程。第三是数据合规和数据驻留要求。不同地区对用户隐私数据、交易日志的存储位置和保留期限都有各自的规定。这不是简单在某个云区域开个实例就行而是贯穿数据库分库、日志采集、对象存储、权限审计的一整套设计。架构上要把“区域”当成一等公民来对待。第四是地图和地址体系差异明显。欧美市场以Google Maps、Mapbox为主地址体系相对规范东南亚部分地区的地址习惯完全不同用户可能只填一个地标名称连门牌号都没有。这直接影响地理编码、配送定位和骑手导航的方案。1.2 架构分层与边界定义在做架构设计时我倾向于把系统分成五层每一层只做自己职责内的事不越界。客户端层包括用户App、商家端App、骑手端App、Web管理后台。海外用户对App包体大小和弱网体验很敏感这一层要重点考虑性能与离线能力。接入层统一走API Gateway负责认证、限流、路由、灰度发布。海外业务经常要按国家或区域做不同的策略比如某个区域大促时流量突增网关层面就要能按区域维度做动态限流。应用服务层是面向场景的业务编排层。点餐、结算、下单、配送追踪这些用例都在这层完成。它不直接操作数据库而是调用下面的领域服务。领域服务层是核心业务逻辑所在包括用户、商家、订单、配送、支付、营销、通知等领域。每个领域服务独立演进有自己的数据存储和缓存。基础设施层提供数据库、消息队列、对象存储、CDN、Kubernetes集群等通用能力并且按区域做隔离。边界定义的核心原则是领域服务之间不直接访问对方的数据库只通过API或消息通信。订单服务要获取用户信息时去调用户服务的接口而不是join用户表。这个规矩看起来简单但业务一急就容易破功。2. 核心模块拆解与关键技术选型2.1 用户端、商家端、骑手端的三端架构一个完整的外卖平台至少有三类角色每类角色的技术侧重点都不同。我在项目里通常把它们拆成独立的BFF层各自面向一个端做API聚合。用户端的核心诉求是快。打开App看到附近商家、菜单、优惠、预计送达时间这些都要在几百毫秒内完成。为了做到这一点首页商家列表要做多级缓存本地缓存、Redis缓存、CDN边缘缓存逐层兜底。菜单数据基本是读多写少非常适合缓存。但要注意缓存失效问题商家改价或者下架菜品后需要在秒级内清除相关缓存。商家端的技术重点是操作可靠性和多设备适配。海外商家很多是夫妻店用一台老安卓机一边接单一边看外卖后台系统必须轻量、按钮够大、网络不稳定时也要能完成接单、出餐、改库存的操作。商家端的读写操作要支持离线队列先写本地再同步到服务端。骑手端的核心是定位和轨迹追踪。海外市场网络环境复杂骑手可能从城市主干道一路骑到信号偏弱的区域App需要做好定位采样的节流和补传机制。骑手端App本身也很讲究耗电GPS持续采集是个耗电大户我们的方案是动态调整采样频率——骑行速度快时提高频率静止或低速时降低频率。三端之间不能各自为政。比如订单状态的展示用户端和骑手端必须依赖同一套状态机由服务端统一驱动状态流转而不是客户端自己算状态。否则会出现用户端显示“商家备餐中”骑手端却显示“已送达”这种数据打架的问题。2.2 订单状态机与事务边界订单是外卖平台最核心的数据实体订单状态机是整个业务的中枢神经系统。我用过Spring StateMachine也自研过事件驱动的状态流转最终沉淀下来的是一套简单可靠的机制。订单状态模型大致如下状态说明可流转方向PENDING_PAYMENT待支付支付成功→PAID超时→CANCELLEDPAID已支付商家接单→ACCEPTED自动接单→ACCEPTED商家拒单→REFUNDINGACCEPTED已接单商家出餐→PREPARING取消→REFUNDINGPREPARING备餐中骑手取餐→PICKED_UPPICKED_UP骑手已取餐开始配送→DELIVERINGDELIVERING配送中送达→DELIVERED异常→申诉复核DELIVERED已送达确认完成→COMPLETEDCANCELLED已取消终态REFUNDING退款中退款成功→REFUNDEDREFUNDED已退款终态状态流转的实现有几个关键点。第一状态变更必须通过服务端接口完成禁止在客户端直接修改状态字段。第二状态转移要用乐观锁控制并发比如使用version字段update时条件带上where status 旧状态防止两个请求同时把订单改成不同状态。第三状态的每一次变更都要记录状态流水的操作人、操作时间和来源。事务边界一定要划清楚。创建订单这个动作涉及预扣库存、生成支付单、发送通知但这些操作不能放在一个数据库事务里因为库存服务、支付服务已经拆开了。实际做法是创建订单主流程只保证订单本身落库然后通过本地消息表异步触发库存锁定和支付单生成。这样主链路快了也不会因为下游服务抖动导致下单失败。2.3 地理空间数据与配单引擎外卖平台的“位置”概念贯穿始终用户定位、商家坐标、骑手实时位置、配送范围、路径规划。我在设计地理空间模块时最常被问到的问题就是“用什么数据库存坐标”。我的实践经验是热路径用Redis GEO冷路径用PostgreSQL的PostGIS。骑手的实时位置是高频写入、高频查询的热数据用Redis GEO可以很方便地实现“查询某个坐标附近N公里内的骑手”这种操作。而商家地址、配送区域、历史轨迹这些低频数据放在PostGIS里做复杂空间分析时优势明显。距离计算用Haversine公式就能满足大部分场景但在做配送费计算时要特别注意道路实际距离和直线距离的差异并不恒定城市中心绕路多郊区反而接近直线。所以计费距离建议用地图引擎返回的实际路径距离而不是手算的直线距离。配单引擎是外卖平台的核心竞争力之一。早期订单量小的时候用最简单的“就近匹配”就够了新订单进来查一下附近3公里内有哪些空闲骑手按距离排序派给最近的那个。但订单量上来之后这种贪心算法会导致部分骑手忙死、部分骑手闲着。我后来改成了批量调度模式每5秒收集一批待分配订单用最小成本最大流算法做全局分配把订单从起点到商家到用户的总骑行距离作为成本函数。这个改动让配送效率提升了大概12%到15%效果很明显。3. 多区域部署与国际化改造实践3.1 多时区、多语言、多币种的工程实现海外平台天然要面对时区、语言、币种的复杂度我见过不少项目在这上面栽跟头。时区问题看起来好处理但坑都在细节里。我的原则是所有时间在数据库和API层统一用UTC存储只有在给用户展示的时候才转换成用户所在时区。订单的预计送达时间、骑手的到达时间、商家营业时间全部按这个规则处理。商家营业时间尤其麻烦它是按店铺本地时区定义的比如一家在曼谷的店营业时间9:00到21:00是曼谷时间你不能用UTC去存因为它会随着夏令时之类的规则变化。这里要注意海外很多地区有夏令时虽然东南亚没有但拉美、欧洲有所以存储时区必须单独记录不能只存一个UTC时间。多语言的核心是文本资源跟业务数据解耦。菜单名称、菜品描述、商家公告这些字段我建议设计成i18n结构的JSON而不是塞一堆language_code。比如菜单项表里放一个name_json字段值为{en:Fried Rice,th:ข้าวผัด}由API层根据用户的Accept-Language返回对应语言。翻译工作流要建专门的后台让运营人员或众包翻译持续维护而不是让开发改代码发版。多币种处理的第一原则是金额存储用最小货币单位整数。美元用美分、日元用日元本身、泰铢用萨当避免浮点数运算产生的精度问题。汇率是另一个独立问题我建议把汇率服务单独拆分每天定时拉取外部数据源并且记录快照。订单金额在创建时就要锁定汇率不能用下单当天的浮动汇率去结算几天后的订单。3.2 支付抽象层与资金安全设计支付是海外外卖平台最绕不开的坑。我前前后后对接过的渠道包括Stripe、PayPal、Adyen以及东南亚的GrabPay、Touch n Go、PromptPay拉美的OXXO、Pix等。每个渠道的API风格、回调机制、退款限制都不一样所以支付模块一定要做抽象层。我在支付服务里定义一个统一的PaymentProvider接口public interface PaymentProvider { PaymentIntent createPayment(PaymentRequest request); PaymentIntent queryPayment(String paymentId); PaymentIntent cancelPayment(String paymentId); PaymentIntent refundPayment(String paymentId, long amountMinor); }每个渠道实现这个接口适配各自差异。上层业务统一调用这个接口不关心具体走的是哪家渠道。这样做的好处是接新支付渠道时只需加一个实现类不需要动订单核心流程。资金安全这块幂等控制是最重要的事。支付回调可能重复推送网络超时后客户端也可能重试下单。我的做法是给每个业务请求生成一个幂等键存到Redis里同一个幂等键的请求重复提交时直接返回第一次的结果。这个设计在创建支付单、确认支付成功、发起退款三个环节都必须有。对账也一定要做。每天晚上定时任务会从支付渠道拉取前一日的交易流水跟本地订单表、支付单表做三向核对。金额对不上就进异常池由财务人工处理。最开始我对对账不上心直到有一次渠道侧系统异常产生了几十笔重复扣款如果不是对账抓出来光客诉就能把团队淹了。3.3 多区域云部署与容灾设计海外业务的部署策略我比较推荐“区域独立部署、数据区域归档、全局统一管控”的模式。简单说每个目标国家或地区用一套独立的Kubernetes集群数据库、缓存、对象存储都部署在对应区域的云服务里保证数据驻留要求。云平台选择上我在东南亚和拉美用得比较多的是AWS在中东地区则要考虑本地可用区的情况。整体架构可以用阿里云、AWS、Google Cloud构建跨区域的底座各区域之间通过高速通道做控制面通信用户流量只在本区域内部闭环。每个区域的Kubernetes集群配置多个可用区Pod副本跨可用区分布节点池里同时准备常规实例和竞价实例。常规实例扛基础流量竞价实例用来承接弹性部分成本可以降低不少。数据库在主可用区和备可用区各部署一主一从开启同步复制自动切换时间控制在30秒内。CDN的配置比想象中更重要。海外外卖平台的用户端性能很大程度取决于静态资源的加载速度。图片资源、商家菜品的实拍图动辄几百KBCDN命中率做到90%以上App首屏的体验完全不一样。图片要进行多尺寸裁剪和格式转换WebP优先针对不同分辨率的设备推送不同尺寸的图。4. 实操过程从单体到微服务的演进路线4.1 第一版单体架构怎么搭我必须强调一个观点新项目启动时不要急着拆微服务除非你的团队已经有微服务的成熟经验否则一上来就拆会让你陷入分布式事务、链路排查的泥潭。我做海外外卖项目的第一版用的是模块化单体架构。技术栈选择如下后端用Java Spring Boot数据库用PostgreSQL缓存用Redis消息队列用RabbitMQ部署用单个Kubernetes集群前端用Vue或React做管理后台用户端App用Flutter或React Native。全部代码在一个代码仓库里但按业务模块分包订单、用户、商家、骑手、支付、通知各占一个模块模块之间通过内部接口调用。第一版的核心是跑通业务流程验证商业模式。这个阶段最怕过度设计比如一开始就上Kafka其实RabbitMQ完全够用一开始就做读写分离其实单库扛到日均几万单都没有问题。数据库表设计上订单表要预留扩展字段。比如说配送地址海外很多地区的地址格式跟国内不一样有些人写的地址是一段大段的描述性文字订单表里要有一个raw_address字段原样保存用户输入的内容不能只存解析后的结构化字段。同理用户手机号也要考虑留出足够长度并且支持号码前缀区域的区分。4.2 服务拆分的时机与拆法服务拆分的时机我的判断标准是看团队痛不痛。当一个模块改动频率明显高于其他模块或者某个表成了多个模块争抢的瓶颈时才考虑拆出来。生搬硬套微服务的边界没有意义拆了反而增加复杂度。常见的拆分顺序是支付服务最先拆。因为支付涉及资金安全、对账、合规审计变更频繁且牵一发动全身独立出来能有效隔离风险。其次是配送服务它的状态流转和订单主流程不一样而且骑手App推送、位置上报带来的流量经常会有突发峰值。然后是用户通知服务短信、Push、邮件这些渠道的对接很琐碎拆出来后订单服务的主链路更稳定。拆分过程要遵循“先改代码再拆数据库”的原则。先把代码层拆成独立的进程数据库依然共用一个实例观察一段时间稳定后再把对应的表迁移到独立库。直接一步到位拆库在代码没有完全解耦的情况下会出现跨库join被迫改成分布式调用的阵痛期很容易出线上事故。4.3 链路追踪与性能优化服务拆分之后排查问题的难度直线上升。用户报一个“下单很慢”你以前在单体项目里直接看一条日志就能定位现在可能要翻五六个服务的日志。所以可观测性体系必须跟上我用的组合是ELK做日志聚合Prometheus加Grafana做指标监控Jaeger做分布式链路追踪。链路追踪的做法是API Gateway在请求入口生成traceId然后通过HTTP Header透传到下游所有服务。每个服务在打印日志时都带上traceId这样可以在Kibana里按traceId把一次请求的所有日志串起来。刚开始执行的时候总有服务忘了透传traceId我后来给团队定了规矩内部HTTP客户端调用必须默认带上当前traceId代码审核时看到没带就要求打回。性能优化的优先次序我个人经验是抓三个大头。第一是数据库慢查询打开PostgreSQL的慢查询日志定期分析把执行时间超过200毫秒的查询逐一优化。第二是Redis热点key商家菜单和首页商品列表是典型的读热点除了缓存之外还要加本地进程缓存做二级兜底减少Redis的压力。第三是外部API调用地图服务、支付网关、短信服务这些第三方接口的耗时经常在数百毫秒能用缓存的地方绝不实时调用能异步的地方绝不阻塞主流程。5. 常见问题与避坑实录5.1 海外区域网络环境下的调用超时与重试海外用户的网络环境整体不如国内那么稳定和快速这是一个客观现实。你在云端调第三方接口时延迟波动也会比国内大DNS解析偶尔都会失败。所以整个调用链路的超时与重试策略必须有非常明确的规范。我给每个外部调用设置了三档超时要求地图接口和支付接口这种关键链路超时上限是5秒短信、邮件、Push这类非关键链路超时上限是10秒并且走异步队列不阻塞主流程。重试必须有退避机制不能简单写个for循环重试三次。我的常用方案是固定间隔加抖动比如第一次失败后5秒重试第二次10秒第三次20秒再加随机数避免同一时刻所有请求全部重试。熔断器必须有不能无限重试。服务之间调用频繁失败时要快速打开熔断避免故障扩散。我用的是Resilience4j里面可以设置错误率阈值、滑动窗口大小、半开状态的自愈机制。熔断这个概念在海外项目中尤其重要因为第三方服务的可用性往往比你在国内遇到的情况更不可控。5.2 本地化改造踩过的坑本地化不只是翻译文案我在这上面交过不少学费。地图坐标系的问题。不同国家使用的地图服务对同样的经纬度可能有不同的解析结果一些地区还存在地图数据偏移的情况。我的做法是统一使用地图服务商的坐标体系不自己做坐标转换。如果同时用了多个地图服务商一定要有一个坐标转换服务做中转不能直接把A服务的坐标传到B服务里。地址格式的差异。欧美用户习惯于填写街道名、城市名、邮编的格式而东南亚很多用户只填一个地标名比如“寺庙旁边的小路进去第三个门”。这种地址对骑手来说地图导航的意义不大反而需要建立“商户熟路”的机制。我们做的功能是让商家和骑手能在这个订单上做文字沟通、打电话甚至拍照补充路况信息。小费机制。海外很多市场有给小费的文化技术架构上要把小费金额纳入计价体系。小费可以在下单时支付也可以送到后给现金。部分国家的小费比例是浮动的用户可以在App上选择固定金额或百分比。这笔钱要单独记账跟餐费分开结算给骑手。电话隐私保护。为了保护用户和骑手的隐私平台一般不直接展示双方真实号码而是通过中间号系统转接。每次订单动态生成一个临时号码订单结束后自动失效。这个在海外平台几乎是标配上线前必须做好。5.3 资金与订单的最终一致性分布式系统里没有强事务这是做微服务之后必须接受的现实。订单支付成功、商家接单、骑手配送这些跨服务的操作最终都要达到一致但过程可以是异步的。我用的最终一致性方案是本地消息表加消息队列。以支付成功为例支付服务收到渠道回调后在本地事务里同时写入订单支付状态和一条待发出的消息然后通过消息队列把“支付成功”事件发出去订单服务收到事件后推进状态机。如果消息发送失败定时任务会扫描本地消息表进行补偿重发。这套方案简单可靠我推荐在大多数场景使用。Saga模式我也用过但主要用在真正跨服务的长事务场景比如“取消订单”同时涉及退款、释放优惠券、恢复库存。实现上通过Saga编排器逐步骤调用各服务每一步失败就执行对应的补偿操作。一个重要注意点Saga的每个步骤和它的补偿操作都必须保证幂等否则重复执行会产生资损。资金安全上退款操作格外敏感。退款单必须有提交流程和审批大额退款要风控复核。退款结果通知到用户时要区分“退款中”和“退款成功”避免用户因为退款流程时间较长产生客诉。订单和支付对账任务每天早上要跑一遍把前一天的数据做双向核对有问题就在对账平台生成工单。几点经验最后分享一点个人经验做海外业务和做国内业务的心态很不一样。国内的市场和基础设施高度同质化你可以靠一套技术栈横扫全国但海外市场每个区域都是独立战场技术架构上的灵活性、隔离性、适应能力永远排在第一位。我看到太多人拿着国内方案硬套海外项目最后死在各种看不见的角落——比如时区算错了导致骑手半夜没单比如由于支付适配没做好导致用户根本无法完成下单。架构不是一上来就设计得完美无缺的它是在业务推进过程中被需求推着走的你只要把边界划清楚、把核心链路守住、把可观测性做好后续的调整都会是顺理成章的事。