• wKong753900

    前提:

    公司是全球性的硬件公司,类似影石,做户外运动相机,硬件方面做了很多年一直都是卖硬件(我们 toB ,不 toC),然后用合作厂商开发的 APP 给用户用,现在今年自己开发软件,我们在国内已经有一套架构(Go+k8s 集群)了,所以此次我想请教的是全球化的架构应该怎么搭。

    目前考虑部的点:北美,东南亚(新加坡),欧洲(法国),迪拜,非洲(这个地方客户比较多)

    问题:

    1 、简单的做法,就是一个点位一套,但这样就没法数据同步,在北美注册的用户,在非洲得重新注册。这个体验不好,想还是实现全球化

    2 、用 GeoDNS ,用统一域名设置多个 ip ,如果设备和 APP ,在某些边缘区域,ip 是不是会经常飘来飘去的

    3 、因为是相机,所以很多音视频文件,全球化的话,音视频文件同步,一个是同步占用带宽,一个是占用空间,这两个量大的话,都难搞,怎么处理

    4 、这几年硬件成本上升,所以公司资金不是很雄厚,有没有高端(用大厂),中端(性价比),低端(当地小厂)的架构推荐?

    暂时想到的是这些,有继续想到再补充

    主楼
  • wKong753900

    软件架构上主要有自建的流媒体服务,P2P 使用的 turn 服务,Go 微服务后端加各种中间件集群(Minio 集群,Pgsql 集群,Redis 集群,Mqtt 集群,RocketMQ 集群等等)

    #1
  • evill

    做过类似的(北爱尔兰、美西、新加坡)
    以新加坡做用户服务主服务,强一致性注册;同步用户回对应区域的服务器,后续登录等对应区域自己完成。
    其他所有服务(支付除外)每个区域完整部署一套。

    用户夸区域时,当前服务接受请求,gateway 确认区域 走亚马逊内网 proxy 到用户注册区域。

    #2
  • wKong753900

    @evill 谢谢哈,请问用户数据同步是用什么方案?然后“用户夸区域时,当前服务接受请求”,这个需不需要一个统一的访问入口?还是让 GeoDNS 来做?

    #3
  • xwayway

    分主数据,业务数据,多媒体数据。主数据全球同步,业务数据和多媒体数据只存一个 region ,通过边缘网关按 region 转发业务请求,多媒体上 cdn

    #4
  • sentinelK

    这个要看你业务的轻重而定。就是你需要再全球不同节点同步多大量的数据。如果只是类似会员,或者设备注册信息,那就完全可以选择异步慢慢同步。

    毕竟你的用户不可能在 A 地注册后,瞬移到 B 地。所以不存在热切节点的可能性。
    然后容错措施可以优先同步一个最近信息节点 ID (类似于最新时间戳),实在没同步过来就主动发起拉取。

    不过从行业做法来讲,跨地域的注册信息其实价值没那么大。甚至会因为政策原因,反过来限制跨地域账号。

    #5
  • wKong753900

    @xwayway 谢谢哈,"分主数据,业务数据,多媒体数据",这样的话,岂不是得拆得很细,然后把服务分开?然后再请教下如果多媒体数据,很多都是看回放的话,用户跨区了,是不是还是得同步?有想过边缘网关做缓存,就是遇到跨区要怎么同步

    #6
  • xwayway

    不会啊,主数据也不是所有都同步啊,就是最简单的,甚至可能就一张用户表,这样保证用户注册/登录这样的基本接口,然后就能把其他所有请求通过边缘网关转发或者直接返回对应 region 的域名,去对应 region 请求具体的业务数据了。多媒体你是准备自建?直接用厂商对象存储然后 cdn 回源呗,没必要自己折腾一套吧

    #16
  • wKong753900

    @sentinelK 谢谢哈,我也在想这个跨区其实是不是就很少一部分情况,大部分还是都会集中在一个点的,需不需要为了解决这么少部分,而考虑那么多呢

    #7
  • evill

    @wKong753900 这个是 10 年前做的了,具体现在是什么方案不清楚了
    用户数据同步是很粗暴的方式:注册时新加坡服直接 call 对应区域写入接口
    没有统一访问接口当时是 APP ,服务器会下发所有域名好像 app 根据延迟选择的,还有一些兜底的规则

    #8
  • Quarry

    又不说日活和未来预计日活,你都知道用 k8 搭微服务,为什么还搞自建流服务,没用过 OSS 相关的吗

    #9
  • Mithril-v2ex

    额外说一点,需要提前考虑各地区的隐私策略与合规。特别是欧洲的 GDPR ,还有 Cookie 设置啥的。不然可能直接被搞一波集体诉讼。所以你很可能还是要按地区切分出去。

    #10
  • xianyu191031

    搞三个,美区,欧区,glo, 合规不严格的其他地区都走 glo 。跨区另外做

    #11
  • cloudzhou

    很有意思的问题,典型一个多点登录同时需要同步全球的场景

    我的建议是:
    1. 单点写,一对多复制,一旦用户固定点写入,那么设定用户持续单点写
    2. 算法判断用户变迁,设置新的固定写入点,所有请求一定会转发到固定写入点
    3. 读取的话可多地,但是如果用户读自己数据,强制写入点

    按真实情况,用户 90% 其实不变化的,一些小的 case 解决变化即可

    #12
  • wKong753900

    @Quarry 一年出货量大概 100 万台设备吧,按 10%日活,前期是打算用 OSS 的,后面量上来了得自己搭

    #13
  • wKong753900

    @Mithril 谢谢,这个是有考虑到的,不过也是得具体实施了才知道什么情况

    @xianyu191031 谢谢哈,glo 是?

    @cloudzhou 对的,主要这个数据同步比较头疼

    #14
  • wKong753900

    @Quarry 谢谢哈,另一个要自建流服务得原因是有款设备主推非洲,然后芯片能力很低,不是标准流,都是传图,所以要自己写协议,主打非洲,一个设备卖 10 块钱以内。

    #15
  • Quarry

    @wKong753900 后面量上来,资源服务器的费用确定抗得住?论成本明显海外云存储性价比更高

    #17
  • wKong753900

    @Quarry 一个方面在找性价比高的服务器厂商,另一个方面也在看海外云存储支不支持非标准的媒体流

    #18
  • xianyu191031

    @wKong753900 global 全球区。 美欧的合规比其他地区严狠毒,要做的话要考虑本地部署(量小的话可能监管不鸟你)

    #19
  • Quarry

    @wKong753900 真的存在高性价比服务商吗,不至于某些流媒体大厂需要建多个仓库来存数据,自建流备份还原少说几十台机器够你们运维玩的了

    #20
  • cominghome

    北美、欧洲是必须要独立部署的,其他地区可以新加坡一把梭,非洲用户多单独在中东或者南非起一套也行。

    账号这一块,注册的时候让用户选 base 地或者给默认值,认证的时候统一入口加一个网关确认账户 base 然后去对应集群拉数。业务这一块前端 CDN 一把梭,后端不同集群不同域名直接调就行(不要试图帮用户解决网络问题)。

    搞不懂你总是在这里同步同步什么,有什么好同步的,政商关系不硬等下 GDPR 砸下来直接按营收 10%罚

    #21
  • wKong753900

    @cominghome 谢谢哈,主要没海外的经验,所以容易陷进某个点

    #22
  • mooyo

    单地中心化存储,多点部署 gateway 内网反代过去就行了。不考虑境内外互联,纯境外国际网间的话,流量费不算特别贵。

    #23
  • mooyo

    GDPR 啥的另说哈

    #24
  • jarytom

    服务器可以用裸金属服务器,性价比比较高,比云主机好多了.推荐一下我们自己用的,鲨鱼的服务器,可以注册账号看看
    aHR0cHM6Ly9wb3J0YWwuc2hhcmt0ZWNoLm5ldC9hZmYucGhwP2FmZj0xNjcx

    #25

发表回复

登录后回复