App域名容灾方案

文 掘金号 wandyers @每日优鲜

著做权归做者全部。商业转载请联系本帐号得到受权，非商业转载请注明每日优鲜大前端团队以及原文地址。

注：本文为系列文章，将分为方案简介，方案落地方案，具体方案剖析，技术实现细节等多篇文章，敬请期待。

背景

因部分地区App域名解析出现问题，致使部分B端App等（如下统一简称App）都出现网络请求超时，找不到主机或异常错误，致使部分配送App没法登陆、使用等问题，影响了部分To B业务。

目标

尽可能消除因外部网络缘由（如外部DNS解析异常、域名不可达等）致使的App出现网络异常的问题。 通过调研,咱们总结了下面的几种方案来防止相似问题再次发生，对比以后，咱们最终也选择了部分策略作为咱们的分批落地方案（步骤后续会详细讲解）。 咱们的但愿App达到避免DNS劫持，下降访问延迟，下降用户链接失败率，提高用户体验度，SDK高可扩展度及可复用性。

方案简介

如下的各类实现策略的简介及简单的优缺点对比。

方案详细

本章节将对上面提到的策略作出详细阐述，包括实现流程及部分重点细节。

1.系统DNS缓存策略

本策略即如今的实现策略，无需额外开发，使用域名进行请求，依赖系统DNS和网络服务商的DNS解析等。再也不详细说明。

2. 直连策略

直连方案实现较为简单，当使用域名访问出现找不到主机，请求超时等异常时，直接切换至IP地址重试请求；且App在下次启动以前，一直使用该IP进行网络请求。

IP或域名优先级为： LocalDNS（域名） > 内置固定IP。

流程图以下图所示：

本方案实现较为简单，在紧急时能够做为临时过分方案。但不建议长期使用此策略，由于App内置的IP没法实时动态更新，会增长将来的风险。

3. 配置文件策略

App首次启动时（包含冷启动），请求后端接口下发配置文件，数据格式可参照附录必定义，并持久化缓存在App客户端本地以供未来使用。

当App启动时，从缓存读取出来配置，并验证有效期。如所有过时，则使用域名或系统内置的IP使用；如部分未过时或全未过时(其实大部分状况下，即便IP过时，在必定时间段内仍是有效的)，则按照优先级次序使用IP地址直连请求；

IP或域名优先级为： 配置文件IP > LocalDNS（域名）> 内置固定IP 。

此方案相比较直连方案，更加灵活，后台可随时更换IP地址而不影响生产环境客户端。

但会出现当域名不可达时间段较长时，或者用户在较长时间段内未打开App，而打开时正好域名不可达，致使缓存配置文件的所有失效，进而降级至直连方案。简而言之，配置文件TTL时间阀值很差控制，不够灵活。

由于每次App启动都会请求配置文件并更新本地缓存，没法根据每一个IP的TTL灵活的更新。

这种方案也会与项目耦合度较高，不利于扩展，各端都须要实现本身业务逻辑，与实际业务耦合度较高。

缓存文件或数据的安全性校验也必不可少（此部分将在后续的分享中详细阐述），防止被第三方恶意篡改致使出现异常。

参考流程以下图所示：

如下两种策略都是基于HttpDNS。HttpDNS是以Http或Https的方式向外提供域名解析的服务。与传统的运营商的Local DNS相比，有如下几点优点：

1、 防止出现DNS劫持

2、 可实现精准调度，让客户端接入最近的业务节点

3、 0ms解析延迟

4、 快速生效

5、 扩展性强

4.第三方HttpDNS策略

腾讯云HttpDNS，阿里云HttpDNS，DNSPod等厂家提供HttpDNS方案，客户端接入方便，开发量较小，相对稳定。

但因为依赖第三方服务，不能自定义一些依赖规则，好比分流等。且第三方服务也可能出现服务异常进而致使咱们的网络状态不可控。

拓扑图以下图所示【图片参考于网络】：

流程图与自建HttpDNS方案类似，请参考"自建HttpDNS"章节流程图。

5.自建HttpDNS策略

自建HttpDNS就是提供私有的DNS解析服务，以Http或Https的方式向外提供服务。严格来说，此方案不是降级策略，而是使用自建DNS替代系统DNS拿到直连IP进行网络请求，而把系统级的缓存做为最后的降级方案。

独立域名或独立IP提供HttpDNS域名解析服务，自研HttpDNS的SDK实现与服务器的通信；各端App接入SDK并完成Http DNS的解析工做，并根据域名拿到部分或所有可用的IP地址列表，再也不依赖现有域名访问后台服务，每次均采用IP的方式访问服务。

拓扑图以下图所示【图片参考于网络】：

App在启动时，须要按照如下流程完成SDK初始化，访问业务接口时，直接使用IP访问，下降延迟，避免DNS劫持等问题，也能方便的集成在其它App中。

IP或域名优先级为：自建HttpDNS > LocalDNS（域名） > 内置固定IP 。

主要流程图以下图所示：

自定HttpDNS与配置文件策略的区别在于，第一提供SDK供多端快捷接入；第二能对单个IP的生命周期进行管理；第三SDK接入方不须要关心IP的管理，只要根据SDK返回的IP或域名（无有效IP时自动切换为域名）进行网络请求便可。

关注问题

1. 不管采用哪一种方案，都须要考虑Header中Host参数配置问题，Https的证书校验问题，SNI等问题，App内嵌的网页的网络请求等问题。
2. 不管采用何种方案，都默认使用App内部固定的IP做为最后的容灾方案。
3. 相同优先级中存在多个IP有效时，采起轮询或优先级的方案就行分流。

上面提到的问题，都将在后续的分享中说明相关实现方案。

建议方案

基于以上阐述，考虑App现状，建议初始阶段暂时采用直连策略（DS001）或配置文件策略(DS002)，在既能减小生产环境问题。App能正常访问的前提下。

第二步根据实际状况，建议尽快实现或接入第三方HttpDNS策略方案(DS003)或自建Http DNS方案(DS004)，并实现本身的SDK供多端使用，此方案在灵活性，扩展性，可维护性，可控制性上比其它方案更加有优点。

附录

附录一

[
	{
		"hostName":"a.test.cn", //域名
		"ips":[ // 域名对应的IP地址列表
			{
				"priority":1, // 优先级
				"ipAddr":"192.168.1.23", // ip地址
				"ttl":1568859453 // 超时时间
			},
			{
				"priority":1,
				"ipAddr":"192.168.1.23",
				" ttl":1568859453
			}
		]
	},
	{
		"hostName": "b.test.cn" ,
		"ips":[
			{
		    	"priority":1,
				"ipAddr":"192.168.1.23",
				" ttl":1568859453
			}
		]
	}
]
复制代码