前提：
公司是全球性的硬件公司，类似影石，做户外运动相机，硬件方面做了很多年一直都是卖硬件(我们 toB ，不 toC)，然后用合作厂商开发的 APP 给用户用，现在今年自己开发软件，我们在国内已经有一套架构(Go+k8s 集群)了，所以此次我想请教的是全球化的架构应该怎么搭。
目前考虑部的点：北美，东南亚(新加坡)，欧洲(法国)，迪拜，非洲(这个地方客户比较多)
问题：
1 、简单的做法，就是一个点位一套，但这样就没法数据同步，在北美注册的用户，在非洲得重新注册。这个体验不好，想还是实现全球化
2 、用 GeoDNS ，用统一域名设置多个 ip ，如果设备和 APP ，在某些边缘区域，ip 是不是会经常飘来飘去的
3 、因为是相机，所以很多音视频文件，全球化的话，音视频文件同步，一个是同步占用带宽，一个是占用空间，这两个量大的话，都难搞，怎么处理
4 、这几年硬件成本上升，所以公司资金不是很雄厚，有没有高端(用大厂)，中端(性价比)，低端(当地小厂)的架构推荐？
暂时想到的是这些，有继续想到再补充
 |
1
wKong753900 OP 软件架构上主要有自建的流媒体服务，P2P 使用的 turn 服务，Go 微服务后端加各种中间件集群(Minio 集群，Pgsql 集群，Redis 集群，Mqtt 集群，RocketMQ 集群等等)
|
 |
2
evill 1 day ago
做过类似的(北爱尔兰、美西、新加坡)
以新加坡做用户服务主服务，强一致性注册；同步用户回对应区域的服务器，后续登录等对应区域自己完成。 其他所有服务(支付除外）每个区域完整部署一套。 用户夸区域时，当前服务接受请求，gateway 确认区域 走亚马逊内网 proxy 到用户注册区域。 |
|
3
wKong753900 OP @evill 谢谢哈，请问用户数据同步是用什么方案？然后“用户夸区域时，当前服务接受请求”，这个需不需要一个统一的访问入口？还是让 GeoDNS 来做？
|
 |
4
xwayway 1 day ago
分主数据，业务数据，多媒体数据。主数据全球同步，业务数据和多媒体数据只存一个 region ，通过边缘网关按 region 转发业务请求，多媒体上 cdn
|
 |
5
sentinelK 1 day ago
这个要看你业务的轻重而定。就是你需要再全球不同节点同步多大量的数据。如果只是类似会员，或者设备注册信息，那就完全可以选择异步慢慢同步。
毕竟你的用户不可能在 A 地注册后，瞬移到 B 地。所以不存在热切节点的可能性。 然后容错措施可以优先同步一个最近信息节点 ID （类似于最新时间戳），实在没同步过来就主动发起拉取。 不过从行业做法来讲，跨地域的注册信息其实价值没那么大。甚至会因为政策原因，反过来限制跨地域账号。 |
|
6
wKong753900 OP @xwayway 谢谢哈，"分主数据，业务数据，多媒体数据"，这样的话，岂不是得拆得很细，然后把服务分开？然后再请教下如果多媒体数据，很多都是看回放的话，用户跨区了，是不是还是得同步？有想过边缘网关做缓存，就是遇到跨区要怎么同步
|
|
7
wKong753900 OP @sentinelK 谢谢哈，我也在想这个跨区其实是不是就很少一部分情况，大部分还是都会集中在一个点的，需不需要为了解决这么少部分，而考虑那么多呢
|
|
8
evill 1 day ago
@wKong753900 这个是 10 年前做的了，具体现在是什么方案不清楚了
用户数据同步是很粗暴的方式：注册时新加坡服直接 call 对应区域写入接口 没有统一访问接口当时是 APP ，服务器会下发所有域名好像 app 根据延迟选择的，还有一些兜底的规则 |
 |
9
Quarry 1 day ago
又不说日活和未来预计日活，你都知道用 k8 搭微服务，为什么还搞自建流服务，没用过 OSS 相关的吗
|
 |
10
Mithril 1 day ago  3
额外说一点，需要提前考虑各地区的隐私策略与合规。特别是欧洲的 GDPR ，还有 Cookie 设置啥的。不然可能直接被搞一波集体诉讼。所以你很可能还是要按地区切分出去。
|
 |
11
xianyu191031 1 day ago 1
搞三个，美区，欧区，glo, 合规不严格的其他地区都走 glo 。跨区另外做
|
 |
12
cloudzhou 1 day ago
很有意思的问题，典型一个多点登录同时需要同步全球的场景
我的建议是： 1. 单点写，一对多复制，一旦用户固定点写入，那么设定用户持续单点写 2. 算法判断用户变迁，设置新的固定写入点，所有请求一定会转发到固定写入点 3. 读取的话可多地，但是如果用户读自己数据，强制写入点 按真实情况，用户 90% 其实不变化的，一些小的 case 解决变化即可 |
|
13
wKong753900 OP @Quarry 一年出货量大概 100 万台设备吧，按 10%日活，前期是打算用 OSS 的，后面量上来了得自己搭
|
|
14
wKong753900 OP |
|
15
wKong753900 OP @Quarry 谢谢哈，另一个要自建流服务得原因是有款设备主推非洲，然后芯片能力很低，不是标准流，都是传图，所以要自己写协议，主打非洲，一个设备卖 10 块钱以内。
|
|
16
xwayway 1 day ago
@wKong753900 #6 不会啊，主数据也不是所有都同步啊，就是最简单的，甚至可能就一张用户表，这样保证用户注册/登录这样的基本接口，然后就能把其他所有请求通过边缘网关转发或者直接返回对应 region 的域名，去对应 region 请求具体的业务数据了。多媒体你是准备自建？直接用厂商对象存储然后 cdn 回源呗，没必要自己折腾一套吧
|
|
17
Quarry 1 day ago
@wKong753900 后面量上来，资源服务器的费用确定抗得住？论成本明显海外云存储性价比更高
|
|
18
wKong753900 OP @Quarry 一个方面在找性价比高的服务器厂商，另一个方面也在看海外云存储支不支持非标准的媒体流
|
|
19
xianyu191031 1 day ago
@wKong753900 global 全球区。 美欧的合规比其他地区严狠毒，要做的话要考虑本地部署（量小的话可能监管不鸟你）
|
|
20
Quarry 1 day ago
@wKong753900 真的存在高性价比服务商吗，不至于某些流媒体大厂需要建多个仓库来存数据，自建流备份还原少说几十台机器够你们运维玩的了
|
 |
21
cominghome 1 day ago
北美、欧洲是必须要独立部署的，其他地区可以新加坡一把梭，非洲用户多单独在中东或者南非起一套也行。
账号这一块，注册的时候让用户选 base 地或者给默认值，认证的时候统一入口加一个网关确认账户 base 然后去对应集群拉数。业务这一块前端 CDN 一把梭，后端不同集群不同域名直接调就行（不要试图帮用户解决网络问题）。 搞不懂你总是在这里同步同步什么，有什么好同步的，政商关系不硬等下 GDPR 砸下来直接按营收 10%罚 |
|
22
wKong753900 OP @cominghome 谢谢哈，主要没海外的经验，所以容易陷进某个点
|
 |
23
mooyo 1 day ago
单地中心化存储，多点部署 gateway 内网反代过去就行了。不考虑境内外互联，纯境外国际网间的话，流量费不算特别贵。
|
|
24
mooyo 1 day ago
GDPR 啥的另说哈
|
 |
25
jarytom 1 day ago
服务器可以用裸金属服务器,性价比比较高,比云主机好多了.推荐一下我们自己用的,鲨鱼的服务器,可以注册账号看看
aHR0cHM6Ly9wb3J0YWwuc2hhcmt0ZWNoLm5ldC9hZmYucGhwP2FmZj0xNjcx |
 |
26
cnleon 1 day ago
1 、简单的做法，就是一个点位一套，但这样就没法数据同步，在北美注册的用户，在非洲得重新注册。这个体验不好，想还是实现全球化
2 、用 GeoDNS ，用统一域名设置多个 ip ，如果设备和 APP ，在某些边缘区域，ip 是不是会经常飘来飘去的 3 、因为是相机，所以很多音视频文件，全球化的话，音视频文件同步，一个是同步占用带宽，一个是占用空间，这两个量大的话，都难搞，怎么处理 |
|
27
wKong753900 OP |
|
28
cnleon 1 day ago
1 、简单的做法，就是一个点位一套，但这样就没法数据同步，在北美注册的用户，在非洲得重新注册。这个体验不好，想还是实现全球化
当然是一个地方一套啊，速度也快，也符合很多当地的法律法规。 至于用户注册，这个就一套就行了，其他地区同步这一套的账户体系就行 2 、用 GeoDNS ，用统一域名设置多个 ip ，如果设备和 APP ，在某些边缘区域，ip 是不是会经常飘来飘去的 肯定不能啊，这样非常容易被打，自然是主动推送 ip 啊。 3 、因为是相机，所以很多音视频文件，全球化的话，音视频文件同步，一个是同步占用带宽，一个是占用空间，这两个量大的话，都难搞，怎么处理 s3+cdn 来处理啊 |
|
29
wKong753900 OP @cnleon 谢谢，方案渐渐清晰了
|
 |
30
MindMindMax 1 day ago
如果没运维能力，还是考虑依赖 CF 的 R2 吧。 非洲的带宽成本并不低（相比北美和欧洲）
让黑哥们多掏点云存储的钱。 |
 |
31
yyttrr 1 day ago
可以看看阿里云的 nis 之类的工具看看延迟,要求不高的话新加坡+美东双中心就足够了,数据同步的涉及业务要具体分析,大概是读写分离,缓存在本地,定时双向同步什么的
|
 |
32
7beloved 1 day ago
好帖子
|
|
33
wKong753900 OP |
 |
35
lixintcwdsg 1 day ago
只有个疑问：
你应该只能要求用户注册的时候就必须选定区域，然后用户访问不同地区直接用不同子域名（最彻底），或者统一域名做网关转发分流（其实也算是有风险，本地网关转外网）。 一个基本问题是 欧洲 北美 东南亚 印度 这些你必须要做数据隐私合规隔离的（不记得印度是不是要单独做了，东南亚不用，北美没经验），尤其是欧洲，欧洲用户数据就不能存在其他区域，用户跨区数据的转移等应该要有用户协议先做法律上的风险（你们公司做全球，那么法务部，数据隐私安全合规应该有同事来处理这方面问题）。 当然你要是觉得自己是小厂，觉得暂时这些事不会找上门来另说，我这里就提示一下做全球服务这是一个基本问题。后面的架构什么的反而都简单后端没多复杂问 AI 都行。 |
|
36
lixintcwdsg 1 day ago
一般来说你们自己的后台系统，都不能看欧洲的用户数据，只能欧洲那边的运营团队自己看和操作。
数据安全隐私合规就有一些欧洲具体的规定了，比如必须 https 未成年不能存 什么信息不能收集 哪些需要脱敏等等。 |
|
37
lixintcwdsg 1 day ago
我看回复有人做过也提出这个问题，你的思路如果还是全球数据访问延迟和成本之类的，恐怕的确关注错了方向～
|
 |
38
nexttick 1 day ago
观摩大佬们的讨论😶🌫️
|
 |
39
lovedebug 1 day ago
用户注册和 onboarding 入口放在一个 site 上，onboarding 时选择绑定的地区（其他 site ），可以上 CDN 等，账号数据进入后再同步到其他 site ，后续用户登录请求先访问主 site ，并根据绑定区域跳转到对应的 site ，目前我们的做法是这样的。
|
|
40
lovedebug 1 day ago
关于文件，建议考虑直接使用云厂商的云存储，目前我们用的 Azure blob ，这个难题就让微软头疼吧。
|
 |
41
remarrexxar 1 day ago
北美和欧洲的数据合规要当心，不同类型的数据怎么存存哪里存多久都有不同的要求。
|
|
42
wKong753900 OP |
 |
43
IvanCrancy 1 day ago 1
这帖子让我梦回 5-6 年前的 V 站氛围 挺好挺好；
 |
 |
44
COW 1 day ago
我理解应该有张全局的表，负责用户 id 、地域标识等元数据，因为要考虑隐私合规，实际使用会根据这张表路由到绑定地域的集群上，真正的用户信息表是在这个集群上的，另外设计时还要考虑用户、设备实际位置变动的情况。
|
 |
45
kaf 1 day ago
我是云服务厂商出身，觉得你这种需求想的太复杂了，要合规化你确实得每个点位一个服务，这个也不是架构和同步的问题，计算机科学的解决思路，首先要想加一层中间件能不能搞定，如果用户对延迟敏感度不高，全球绕一圈最短 200ms ，你需要加一层网关通过 cdn 代理到全球，鉴别用户反代到哪里的服务器就好了，至于域名和代理方案产品这些，云厂的客户经理会帮你决定好的，泥需要的架构只要 用户-》 cdn-》 gateway-》全球加速-》实际可用地区服务，延迟，缓存，全都交给云厂，或把我的话喂给 ai 也可以生成一套架构方案。我只是猜测你们业务不是需要那么高的全球同步必要，如果确实必要全球同步那另说。
|
 |
46
qishua 1 day ago
有两种架构
1：用户中心放在新加坡，对外走 Anycast ip 的方式，这样用户注册、登录延迟最高也就在三四百 ms 左右。 然后你可以在美国、欧洲、非洲各地部署你们的流媒体服务，资源存储存 s3 、oss ，走云企业网，各地域 vpc 打通。 2：就是分地域的情况了，例如欧洲就一套欧洲的，美国就一套美国的， |
|
47
qishua 1 day ago
你也可以都部署在新加坡，对外走 Anycast ip 的方式，只要你们的业务需求没有什么强联网的情况
|
|
48
wKong753900 OP |
 |
49
xumiao 1 day ago
学习一下各位佬的架构设计
|
 |
50
piercezzs 23h 55m ago
喜欢这类帖子，多来点
 |
 |
51
Chinchilla500 22h 38m ago
我们公司也是做全球市场，为了满足 GDPR ，RED-DA 的法规，分别在北美、澳洲、日本、德国部署了 4 套服务，但是各个 region 的日志、图片还是回传到了中国的 Clickhouse ，我们还处在 Beta 阶段，基本上所有日志都采集了，为了打磨产品还是冒着一些风险的。虽然我们在登录界面的隐私&用户协议提到了会采集用户数据用以改善 app 体验...
我也提个问题，正式上线之后像飞书通知、日志、图片回传中国这个通道肯定是要关闭的，那对研发就非常不友好了。是不是在中国也不能连接北美、欧洲的数据库？那平时怎么监控线上问题呢，我们只有中国团队。 |
 |
52
ETiV 22h 24m ago
总体来说应该是 [一个点位一套]
用户注册的问题： 我建议是用户注册的时候，让用户自己选。 你可以根据用户的 App 来源区域做就近匹配（ App Store 、Google Play 都有接口获取到），然后你根据 App 的 region 设置默认的连接域名、甚至欧洲区不让用户切换服务器 ── 你说的“在北美注册的用户，在非洲得重新注册”这是非常极度非常极度非常极度边界的情况，不予考虑即可。因此即便一个非洲用户从北美 App Store 下载安装，注册或者登录时连接的还是北美服务器。 全球加速的问题： 你可以分别针对每一个点位的域名分别做 CDN 的全球加速（这样到非洲的北美用户也有个基础保障），这个方案很成熟了，买 Cloudflare 就行、当然国内云厂商也有这种全站加速服务…而后就不存在从 origin 同步音视频文件到其余各个地区了 Tips: 音视频可以存一个低码率的，给用户在线预览用，当用户需要下载时再给高码率质量的 URL 。 云厂商选择： 如果你们下游厂商没有特别严格 特别变态的合规需求就用国内的云，联系个商务能给不小的折扣~ |
 |
53
nrtEBH 19h 47m ago
数据合规的美国和欧洲单独存放 其他区可以放一起 但是入口可以搞在一起 不少 app 是这么干的 应该只是 PII 数据是需要合规 你可以在用户注册时候用国家属性来路由
|
|
54
wKong753900 OP @Chinchilla500 这个得具体问题具体分析了，当然保险的做法是在北美，欧洲部一台堡垒机，通过堡垒机再去访问数据库了
@nrtEBH 是的，不少 app 是这么干的，估计我也差不多也这样干了 @ETiV 好的，谢谢哈 |
 |
55
waringid 8h 48m ago
1 、首先评估安全合规影响（法务和业务一起）再考虑技术架构
2 、这些业务都和用户隐私相关，建议结合法规和区域（欧洲、中东、东南亚、北美、南美+澳洲）规划资源和网络配置 3 、如果技术架构不强制要求数据或访问接口统一，可以考虑采用不同云服务优势结合的方案。例如欧洲考虑谷歌云或 AWS ，东南亚、中东考虑国内的云资源 4 、如果系统的架构一致，相当于各区域单独部署并使用独立的域名接入访问 |
 |
56
egfegdfr 4h 44m ago
大概 2 个方案
1 ， 全球只做一个集群，能后给集群开 dcdn 加速，这样访问速度的延迟应该还好 2. 全球在多个区域各部署一个集群，结构化数据通过 dts 全球同步，非结构化数据，按照注册地区就近存储 方案 2 有两个问题需要注意：1 ，合规性，各个国家对数据出境（特别是敏感数据）都有相关的法律规定，这个需要加上法务开会讨论； 2. dts 全球多节点同步，这里有个坑，不能用阿里云的，我们当时用的阿里云，介绍页面写的支持多节点的同步，上线后发现不支持，紧急回退了， 我看腾讯的支持，可以用腾讯的 https://www.cnblogs.com/tencentdb/p/16521265.html 我公司的方案演变过程， 先全球各主要区域独立部署一套，各自为战。 后面用的方案 2 ，由于合规的问题，现在统一迁移到国内，用的方案 1 |
|
57
wKong753900 OP |
 |
58
encro 1h 6m ago
账户服务统一，需要快速服务的本地服务可以独立部署？
|
Select Language