技术转型之路三:资源隔离之域名拆分

为什么执行域名拆分

现在的团队支撑的所有业务都是通过同一个域名服务的,根据 URL PATH 的不同最终路由到不同的后端 APP

URL 业务 备注
api.host.com/v1 business logic 1 第一个版本 涉及支付,核心链路
api.host.com/v2 business logic 1 第二个版本 涉及支付,核心链路
api.host.com/v3 business logic 2 第一个版本 不涉及支付,非核心链路

从以上表格不难看出,现有的域名设计方案,核心业务和非核心业务都是用同样的域名,也就是他们都是用的是同一网关做出入口,这样会导致的问题是:

由于非核心业务引起的流量突发会波及核心业务链路

非核心业务在一些热点事件或推送的影响下流量会在短时间激增,是平时业务 5 倍甚至更高,因此之前的团队为了应付这种情况做了动态的调整带宽包,每隔一分钟检测出口带宽的使用率,以避免因为出口带宽打满而引起业务不可用,但是这个解决方案仍然有几个问题:

  1. 带宽检测的有延迟,并不能在带宽打满的第一时间做出调整
  2. 动态调整带宽包依赖与云厂商的相关服务,此前因为云厂商带宽调整服务不可用导致带宽调整失败

为了能够保证核心业务始终高可用,采取如下几个措施:

第一,需要把各个业务从域名开始彻底拆分,部署不同的网关,由于核心业务带宽稳定,可以使用较高的基础带宽来保证业务的高可用,辅助以动态调整带宽预防突发情况。

第二,非核心业务依然采用动态调整的带宽的方式,观测和预估流量的走向,在业务高峰发生之前提前调整,比如在推送发生时触发流量调整事件,在业务高峰的早 9 点和晚 9 点前后提前调整流量。

划分域名的原则

域名拆分的原则是把具有相同功能 API 划分到同一域名之下,区分核心业务(支付、交易等)和非核心业务(资讯、用户消息、评论等),始终保证非核心域名的网关可用。

为了保证域名拆分可以顺利推动和落地实践,需要 API 的使用方和制作方严格遵守同一套规范,即对应功能要部署在对应的域名之下,对应的 API 的调用要使用对应的域名

注意,同类型服务(比如服务于同一个客户端 APP)不要引入过多域名,过多域名不利于维护,根据自己的业务场景酌情划分。

命名规则可以参考类似 consul 的域名命名规则:NAME.TAG.host.com,name 表示业务功能,tag 表示具体的应用,例如 order.app.host.com 和 news.app.host.com 。

三月沙 wechat
扫描关注 wecatch 的公众号