链家网技术总监陈尔冬:链家网的第三种运维(4)
所以大家都缓存一下吧,30秒内我不会变,直接用上次查询结果.如果我这里有一个后端的资源故障了,我要把这个故障移除,我刚才设了 30 秒 TTL,30秒内不会更新这个域名,30秒都可能继续连到有故障的后端,这怎么办?所以我们又引入了一个新的基础设施,叫做 DNSMasq.
这个时候我们这个域名就可以在 TTL 之内也完成这个变更.我们看最后这个架构,我们在一台服务器上面安装了一个 DNSMasq,如果应用程序需要通过域名连接 MySQL,它会先查 DNSMasq 有没有.有,给一个 IP 端口,如果没有,DNSMasq 会查 SkyDNS. 如果这个时候有域名变更也能够取到,但是 DNSMasq 有缓存怎么办?我们看到后面我们有个 API 层,项目代码叫马其顿,我们每一个基础设施都是 API 化的. 当你做 MySQL 监控的时候,发现我一个从库延迟太高,我要摘掉它.怎么摘呢? 调用马其顿 API.马其顿做两件事,第一是更新 etcd,第二就是刚才我说的调我的 DNSMasq 的 API,这个时候如果业务再要连后面 MySQL 就会连 DNSMasq.DNSMaqs 这个缓存已经被清除了,于是就会连 SkyDNS,就会给一个新的记录,因为 etcd 里面记录已经被更新了. 最后还有个问题,后端服务拓扑不光有 IP 地址,还有可能是有端口号.这时候标准域名协议就搞不定了.这时候我们有两个方法.
在链家应用团队觉得可接受,我们也乐得清闲,不用再改了.如果应用团队不接受怎么办?就要去修改 Glibc 了. 6、配管工具与自动化运维最后部分是关于配置管理与自动化运维.我翻译过了《奔跑吧 Ansible》这本书,所以我肯定是偏爱 Ansible. 现在在市面上我们能看到的主流的配管工具有这么多,左下角是一个灯泡,这个灯泡在淘宝上叫爱迪生灯泡,我用它替代自研系统. Puppet、Ansible、SaltStack 等配管工具各个有各自的特点,Ansible 是推模式,无 Agent,其他的是有 Agent 的.抽象层有薄有厚,在《奔跑吧 Ansible》一书中,作者的观点是他喜欢 Ansible 的一点就是抽象层很薄,这点我也非常同意. 举个例子,如果我这个团队有上千台服务器,都是 Linux,但是有多个发行版.Puppet 会倾向自己去适配不同发行版,形成抽象层. Ansible 倾向于暴露这些差异,需要使用者去管理.或者使用者把发行版统一,或者使用者自己做一层抽象层来兼容不同发行版. 我认为 Ansible 的做法比较适合运维领域,但我觉得这几个工具都蛮好的.我还是建议大家分析它的特点,如果你觉得这个东西用得顺手,适合你的团队你就用,Ansible 会有瓶颈,没 Agent,又是 Python,内存占用比较高. 另外 Ansible 所有的配置是静态配置,如果我有些服务器变更,我希望它动态变更怎么办? 在我们团队初期,服务器规模还不大,直接使用 Ansible 落地很快.一方面不需要装 Agent,所有服务器肯定都会启动 SSH,Ansible 马上可以落地.而且团队历史遗留一些脚本,用 Ansible 也很容易复用. 当你用 Ansible 遇到瓶颈的时候,团队已经已经成长了,你就可以把它一定程度的改掉或者整个替换掉. 7、总结总结一下,就像我最开始时说的,我认为这个真实世界不是 0 与 1 两面对立的,在 0 和 1 中间有无穷的灰度.到底这个灰度对于我们的公司或者对于您的公司在哪,需要结合团队情况自己分析,自己去找. 对于新技术,尤其是现在技术炒作问题这么严重,千万不要迷信.某个技术,解决什么问题?优势是什么?成本又是什么?对于我们团队、环境适不适合?这些都是在使用前需要考虑好的问题. 一个系统不管怎么样,在我们的应用中,在我们的生产环境中真正运行里面才能发挥价值. 系统再好,不管是因为什么原因,只要在我们环境中运行不起来,那对我们公司没有价值.最后就是不要忽略工程上和这些可以规范化、流程化上可以解决的问题. (编辑:ASP站长网) |