之前有负责过公司的内网域名系统的开发以及一部分的建设。在这里做个总结。
首先第一个问题：商用的域名管理平台有DNSPOD，有阿里的域名管理平台，还有一些小众平台，比如dns.la等。有些做运维的同学都不是特别明白，我们使用公网的DNS系统就可以啊，为啥你们公司还搞个内部的DNS服务，我们之前都不需要。
解答：使用公网DNS服务的时候，我们企业内部服务之间的调用是这样的：
公司内部服务之间的调用量，小公司可能还好本身自己的量也不大,但是当公司做大之后内网的网络传输量是非常大的,这个时候如果我的服务1 和服务2之间的通信域名解析要走公网出去绕一圈再回来，对性能要求高的肯定是没法接受的，我2台机器都纯内网高速网络却让我去公网绕一圈，本身这是一点，其次呢是：稳定性，出公网就意味着公网出现网络抖动等等都会影响服务的响应。技术可要更高的效率以及稳定性。缓存这一块也该考虑进去，对于迭代频繁以及一些需要秒切服务的应用，公网DNS更是个大的瓶颈。
上述就是为什么要在自己公司内部自建DNS服务的原因。那接下来就是搭建。
搭建我们首选BIND,网上教程很多，这个不做过多的
讲解。服务好了，在初始化镜像里加入我们的nameserver地址，本地找不到再去公网上。如图：
服务1和服务2直接走内网DNS服务请求，同时我们新增域名等等一系列的操作都可以立刻reload服务，刷新。内部DNS服务不存在的才去找公网DNS服务。
问题二：平台搭建使用zone文件还是数据库存储解析数据？
解答：zone文件存储是传统的方式，解析都是配置文件里。优势，不会存在任何问题，本地读取，缺点：很不方便使用。数据库存储是后来Bind服务支持的方式，更方便的增删改查，bind服务读取都直接从数据库中读取解析信息，缺点：bind服务和数据库之间的连接出现抖动就会出现问题，其次，数据库的高可用也是风险点。综合一下，我司更愿意使用第一种方案，运维最在意的就是稳定。使用不方便可以通过平台开发实现。
接下来就是开发的工作了。本人使用django 实现快速的迭代。架构图如下：
线上的DNS服务不能因为我们的平台而导致服务稳定性出现问题，所以平台需要脱离线上服务，管理平台和线上所有机器建立免秘钥登录，管理平台和线上的所有DNS服务之间只是线上会推送文件zone文件给线上，然后执行reload
问题：为什么要冷备不选负载均衡？
解答：因为zone文件是存在服务器上的文本，如果采用负载会导致两边机器同时更新，同时互相推送等的问题，主机器只需要把备也当做线上机器一样推送zone文件就OK,当主挂了备起来，当然了，我们就是想实现负载均衡也肯定是可以的，不过，我们更关注的是高效和快速的开发使用。这个架构对我们来说不存在瓶颈。
平台开发中的功能：1.解析增删改查，备注，批量增删改查，这些都是基本功能。其次就是操作记录一定要记录全，要支持一键回滚。按照企业需求开发就好。
问题：数据库高可用改造？
解答：首先为什么域名解析会和数据库都扯上关系了呢。感觉一点关系都没有的东西怎么就有了交叉呢。
公司做大之后，运维需要考虑更多的东西，比如：异地容灾，万一北京的机房火灾了，如何立马把所有的服务切换到上海，对服务要求更高的要求2地机房负载，用户理哪里近请求哪里的资源。这个时候我们的平台就能发挥横向扩展了，只要上海的DNS服务器和我们的平台之间建立免秘钥就OK，分分钟搞定。
问题来了，在异地机房容灾这一块，数据库也要实现容灾。那就得北京和上海同时拥有相同的数据库，假设北京数据库出现问题（阿里RDS 脑裂或机房火灾）如何立马切换到上海呢？
给每个使用数据库的用户都是通过域名来访问的。例如：dba.dba.com
我们需要实现当北京的数据不可用的时候：dba.dba.com 172.168.1.1 这条解析立马切换成dba.dba.com 172.169.1.1的解析，172.169.1.1 这个IP是我们大内网上海的网段IP
看着好像是非常完美，DBA的需求也实现了。当他们200+的域名需要全部切换到上海的时候，约定规范，几秒只能全部修改了推送到上海机器，然后reload 生效。
那么问题又来了：平台部署在北京机房，如果北京机房只是数据库故障还好，平台在就能切换。那如果北京机房不可用了呢。我们的平台都能用了，还怎么给我切换了。我上海不能用了还要切换北京呢。这些都怎么给我解决呢。。。
一脸懵逼。。。。
解决方案：
架构是有些复杂了。把DNS平台完美克隆到上海一套，为了让用户无感操作，点击上海域名的时候在nginx上做强跳转到上海，认证可以通过在cookie里面设置值实现。
这样是不是就可以北京全部down掉之后需上海不受影响了。
如今大伙儿了解企业域名管理系统的搭建&数据库高可用改造了吧，早已在上述文章为大伙儿作出了解读，坚信诸位在看了以后应该可以懂了吧。
[ 关键字：管理系统,数据库 ]
