• 请不要在回答技术问题时复制粘贴 AI 生成的内容 V2EX › 程序员 今天周二，人多，有没架构大佬帮忙看看，讨论讨论，有兴趣的也可以一起参与 wKong753900 · Kun-GitHub · 1h 1m ago · 911 views 前提： 公司是全球性的硬件公司，类似影石，做户外运动相机，硬件方面做了很多年一直都是卖硬件(我们 toB ，不 toC)，然后用合作厂商开发的 APP 给用户用，现在今年自己开发软件，我们在国内已经有一套架构(Go+k8s 集群)了，所以此次我想请教的是全球化的架构应该怎么搭。目前考虑部的点：北美，东南亚(新加坡)，欧洲(法国)，迪拜，非洲(这个地方客户比较多) 问题： 1 、简单的做法，就是一个点位一套，但这样就没法数据同步，在北美注册的用户，在非洲得重新注册。
这个体验不好，想还是实现全球化 2 、用 GeoDNS ，用统一域名设置多个 ip ，如果设备和 APP ，在某些边缘区域，ip 是不是会经常飘来飘去的 3 、因为是相机，所以很多音视频文件，全球化的话，音视频文件同步，一个是同步占用带宽，一个是占用空间，这两个量大的话，都难搞，怎么处理 4 、这几年硬件成本上升，所以公司资金不是很雄厚，有没有高端(用大厂)，中端(性价比)，低端(当地小厂)的架构推荐？暂时想到的是这些，有继续想到再补充 全球化 架构 同步 19 replies • 2026-09-08 10:19:35 +08:00 1 wKong753900 OP 55 mins ago 软件架构上主要有自建的流媒体服务，P2P 使用的 turn 服务，Go 微服务后端加各种中间件集群(Minio 集群，Pgsql 集群，Redis 集群，Mqtt 集群，RocketMQ 集群等等) 2 evill 53 mins ago 做过类似的(北爱尔兰、美西、新加坡) 以新加坡做用户服务主服务，强一致性注册；同步用户回对应区域的服务器，后续登录等对应区域自己完成。
其他所有服务(支付除外）每个区域完整部署一套。用户夸区域时，当前服务接受请求，gateway 确认区域 走亚马逊内网 proxy 到用户注册区域。
3 wKong753900 OP 50 mins ago @ evill 谢谢哈，请问用户数据同步是用什么方案？然后“用户夸区域时，当前服务接受请求”，这个需不需要一个统一的访问入口？
还是让 GeoDNS 来做？ 4 xwayway 50 mins ago 分主数据，业务数据，多媒体数据。
主数据全球同步，业务数据和多媒体数据只存一个 region ，通过边缘网关按 region 转发业务请求，多媒体上 cdn 5 sentinelK 48 mins ago 这个要看你业务的轻重而定。就是你需要再全球不同节点同步多大量的数据。
如果只是类似会员，或者设备注册信息，那就完全可以选择异步慢慢同步。毕竟你的用户不可能在 A 地注册后，瞬移到 B 地。
所以不存在热切节点的可能性。然后容错措施可以优先同步一个最近信息节点 ID （类似于最新时间戳），实在没同步过来就主动发起拉取。
不过从行业做法来讲，跨地域的注册信息其实价值没那么大。甚至会因为政策原因，反过来限制跨地域账号。
6 wKong753900 OP 46 mins ago @ xwayway 谢谢哈，"分主数据，业务数据，多媒体数据"，这样的话，岂不是得拆得很细，然后把服务分开？然后再请教下如果多媒体数据，很多都是看回放的话，用户跨区了，是不是还是得同步？
有想过边缘网关做缓存，就是遇到跨区要怎么同步 7 wKong753900 OP 44 mins ago @ sentinelK 谢谢哈，我也在想这个跨区其实是不是就很少一部分情况，大部分还是都会集中在一个点的，需不需要为了解决这么少部分，而考虑那么多呢 8 evill 41 mins ago @ wKong753900 这个是 10 年前做的了，具体现在是什么方案不清楚了 用户数据同步是很粗暴的方式：注册时新加坡服直接 call 对应区域写入接口 没有统一访问接口当时是 APP ，服务器会下发所有域名好像 app 根据延迟选择的，还有一些兜底的规则 9 Quarry 37 mins ago 又不说日活和未来预计日活，你都知道用 k8 搭微服务，为什么还搞自建流服务，没用过 OSS 相关的吗 10 Mithril 31 mins ago 1 额外说一点，需要提前考虑各地区的隐私策略与合规。特别是欧洲的 GDPR ，还有 Cookie 设置啥的。
不然可能直接被搞一波集体诉讼。所以你很可能还是要按地区切分出去。
11 xianyu191031 31 mins ago 搞三个，美区，欧区，glo, 合规不严格的其他地区都走 glo 。跨区另外做 12 cloudzhou 30 mins ago 很有意思的问题，典型一个多点登录同时需要同步全球的场景 我的建议是： 1. 单点写，一对多复制，一旦用户固定点写入，那么设定用户持续单点写 2. 算法判断用户变迁，设置新的固定写入点，所有请求一定会转发到固定写入点 3. 读取的话可多地，但是如果用户读自己数据，强制写入点 按真实情况，用户 90% 其实不变化的，一些小的 case 解决变化即可 13 wKong753900 OP 30 mins ago @ Quarry 一年出货量大概 100 万台设备吧，按 10%日活，前期是打算用 OSS 的，后面量上来了得自己搭 14 wKong753900 OP 27 mins ago @ Mithril 谢谢，这个是有考虑到的，不过也是得具体实施了才知道什么情况 @ xianyu191031 谢谢哈，glo 是？
@ cloudzhou 对的，主要这个数据同步比较头疼 15 wKong753900 OP 25 mins ago @ Quarry 谢谢哈，另一个要自建流服务得原因是有款设备主推非洲，然后芯片能力很低，不是标准流，都是传图，所以要自己写协议，主打非洲，一个设备卖 10 块钱以内。 16 xwayway 23 mins ago @ wKong753900 #6 不会啊，主数据也不是所有都同步啊，就是最简单的，甚至可能就一张用户表，这样保证用户注册/登录这样的基本接口，然后就能把其他所有请求通过边缘网关转发或者直接返回对应 region 的域名，去对应 region 请求具体的业务数据了。
多媒体你是准备自建？直接用厂商对象存储然后 cdn 回源呗，没必要自己折腾一套吧 17 Quarry 23 mins ago @ wKong753900 后面量上来，资源服务器的费用确定抗得住？
论成本明显海外云存储性价比更高 18 wKong753900 OP 14 mins ago @ Quarry 一个方面在找性价比高的服务器厂商，另一个方面也在看海外云存储支不支持非标准的媒体流 19 xianyu191031 12 mins ago @ wKong753900 global 全球区。美欧的合规比其他地区严狠毒，要做的话要考虑本地部署（量小的话可能监管不鸟你）