惯性聚合 高效追踪和阅读你感兴趣的博客、新闻、科技资讯
阅读原文 在惯性聚合中打开

推荐订阅源

V
Visual Studio Blog
罗磊的独立博客
小众软件
小众软件
T
Tailwind CSS Blog
宝玉的分享
宝玉的分享
博客园_首页
N
Netflix TechBlog - Medium
B
Blog
Recent Announcements
Recent Announcements
Y
Y Combinator Blog
Blog — PlanetScale
Blog — PlanetScale
L
LangChain Blog
F
Fortinet All Blogs
The GitHub Blog
The GitHub Blog
Stack Overflow Blog
Stack Overflow Blog
C
Check Point Blog
Last Week in AI
Last Week in AI
Jina AI
Jina AI
V
V2EX
奇客Solidot–传递最新科技情报
奇客Solidot–传递最新科技情报
让小产品的独立变现更简单 - ezindie.com
让小产品的独立变现更简单 - ezindie.com
钛媒体:引领未来商业与生活新知
钛媒体:引领未来商业与生活新知
博客园 - 叶小钗
博客园 - 【当耐特】

陈少文的网站

巨变与机遇的未来十年 Kubernetes 平台管理软件压力测试方案 使用镜像部署 Hexo 静态页面 终于等到你 - GitHub 镜像仓库服务(ghcr.io) 一起来学 Go --(6)Interface 一起来学 Go --(5)Goroutine 和 Channel 什么是函数式编程 如何在 Kubernetes 集群集成 Kata 柯里化与偏函数 使用 PyGithub 自动创建 Label 软件产品是团队能力的输出 Helm 2 、Helm 3 比较 IoT 变现 Kubernetes 中的 DNS 服务 国内的 Helm 镜像源 Harbor 使用自签证书支持 Https 访问 DevOps 工具链之 Prow 如何使用 kfctl 安装 Kubeflow VS Code 无法下载 Go 插件的工具包 工程师更应具有服务精神 你不知道的 Docker 使用技巧 使用 Docker 运行 Tensorflow 论中国 什么是左移 如何清空 Git 仓库全部历史记录 一禅小和尚 有风吹过厨房 时间的玫瑰 如何在 CentOS 安装 GPU 驱动 开发 Tips(19)
海外多区下的流量分发
微信公众号 · 2022-05-31 · via 陈少文的网站

1. 关于流量分发

流量的治理分为南北向和东西向。在典型的 Network Diagrams 的绘图习惯中,核心网络组件绘制在顶部,客户端绘制在底部,不同的服务水平绘制,因此有了南北和东西流量的称呼。

其中,南北流量指的是从客户端发起的流量,东西流量指的是服务与服务之间的流量。目前东西流量,采用的是给每个服务添加一个 Sidecar 接管所有服务与服务之间的调用,以达到流量治理的目的。而本篇,主要讨论的是南北向流量,也就是网关流量。

2. LB 直接路由到服务主机

如上图,对于小规模的业务,我们可以直接通过云厂的 LB,将客户端的流量直接路由到服务,服务再去 DB 获取数据。这就是一个三层架构,接入层 LB,服务层 Server,存储层 DB。

接入层能承载的流量通常很大,如果需要扩展,可以根据业务进行水平拆分,比如 a.chenshaowen.com 一个 LB、b.chenshaowen.com 一个 LB。

服务层无状态,通过增加副本数即可实现扩展,无论是加 VM,还是增加 Kubernetes Pod 数量都能较快实现。

DB 层通常最容易遇到瓶颈,也是较难扩展的部分。在业务瓶颈期,通过配置更好的硬件、性能更好的数据库能短期解决问题。但如果想长期解决问题,还是得进行拆分。DB 的拆分有两种,水平拆分和垂直拆分。水平拆分就是将一个表分成多个表,一个库分成多个库,分散压力。针对国内的用户体量,有些用户信息库甚至能拆分为上百个表,在访问时,根据用户 ID 规则能够找到所在的数据库。而垂直拆分是对表的列进行拆分,减少单表的列数、减少单库的表数。

3. 国内多机房下的流量分发

如上图,业务规模持续增长时,我们不得不在多个机房部署服务,一方面是提高服务的可用性,一方面是提高对云厂商的议价能力。

在进行多机房部署之前,建议先做单元化。单元化的过程是有意义的,会帮助我们梳理服务的全部依赖,打包到一个 Unit。无论是单机房多 Unit,还是多机房多 Unit,都可以通过部署新的 Unit 增加可用的副本、实现无缝滚动更新、支持流量灰度等功能。

在多机房下,用户流量通过接入层 LB,按照比例分配到不同的 Unit 中,再经过 Unit 中的业务网关分发到具体服务。

这里最大的挑战在于,如何保障 DB 存储层的一致性。我们可以直接购买云厂的异地多活 DB 实例,当然也可以自建异地多活 DB 实例。很多异地多活的 DB 实例方案对时延要求比较高。同一个多活实例中,各个实例之间物理距离可能达到数百公里,这在普通公网条件下是无法达到低延时要求的。因此,异地多活的关键在于,需要搭建一个互通的低延时专线连通各个机房。

采用不同厂商的机房构建基础设施,还有一个好处就是各厂商都会提供一定的优惠折扣,技术支持上也会积极很多。当然,这也需要消费额达到一定的量级。

4. 海外多区下的流量策略

海外多区的架构比国内多机房的架构更加复杂。这是由于,各地区有数据保护条例,不允许当地的用户数据外传到其他地方。另一方面,还会涉及到域名策略,是选择海外使用同一个域名、还是海外各区使用不同域名?

4.1 各区统一域名

  • 通过 cookies 路由各区

如上图,我们可以在 cookies 中,设置 region 字段表示用户所在区域。

在登录之前,我们需要在各区之间同步用户所在区域的信息。在登录时,通过 DNS 就近解析,或者 LB 任意选择一个区域进行登录。登录之后,在 Cookies 中设置 region 字段。

登录完成之后,LB 通过 cookies 中的 region 将用户访问请求分发到数据所在区域。

  • 通过 url 路由各区

与采用 cookies 路由的方式非常类似,我们还可以将 region 信息直接显示的写到 url 中,将 /sg/* 的请求分发到新加坡,将 /us/* 的请求分发的到美西。

4.2 各区不同域名

如上图,采用多域名在用户可用性、可维护性上会更好。在每个区,我们都为服务提供一个单独的域名 sg.chenshaowen.com 指向新加坡的服务,us.chenshaowen.com 指向美西的服务。

在登录之前,通过 GeoDNS 地理位置域名解析服务,就近访问所在区域的服务。如果用户属于当区,则完成登录,并跳转到区域域名。否则通过后台转发到其他区域,进行登录,再跳转到用户区域的服务域名。

5. 总结

本文主要讨论的是南北向的流量分发,从经典的三层架构到多机房,最后到海外各区。

对于大型服务,单元化无疑可以提高整体的扩展性,借助于流量网关的分发,可以实现故障切换、灰度测试等功能。而对于海外业务,则首先需要考虑的是域名策略。

实际上,从 SEO 的角度考虑,采用单域名比多域名好很多,多域名会分散网站的权重。但是采用多域名也能有效的分担风险,各区的服务相互不影响,能够独立对外提供访问。如果想结合起来,也可以使用一个统一网关利用 cookies 或 url 转发到各区子域名,比如 chenshaowen.com/sg/ 转发到 sg.chenshaowen.com。