海外多区下的流量分发
1. 关于流量分发
如上图，对于小规模的业务，我们可以直接通过云厂的 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/<em> 的请求分发到新加坡，将 /us/</em> 的请求分发的到美西。4.2 各区不同域名
如上图，采用多域名在用户可用性、可维护性上会更好。在每个区，我们都为服务提供一个单独的域名 sg.chenshaowen.com 指向新加坡的服务，us.chenshaowen.com 指向美西的服务。在登录之前，通过 GeoDNS 地理位置域名解析服务，就近访问所在区域的服务。如果用户属于当区，则完成登录，并跳转到区域域名。否则通过后台转发到其他区域，进行登录，再跳转到用户区域的服务域名。
