查看原文
其他

新浪微博平台自动化运维演进之路

2017-07-31 王关胜 IT大咖说

内容来源:2016年12月16日,微博产品资深运维架构师王关胜“GIAC全球互联网架构大会”进行《新浪微博平台自动化运维演进之路演讲分享。IT大咖说作为独家视频合作方,经主办方和讲者审阅授权发布。

阅读字数: 2557 用时: 4分钟

摘要

新浪微博是一个由新浪网推出,提供微型博客服务类的社交网站。用户可以通过网页、WAP页面、手机客户端、手机短信、彩信发布消息或上传图片,是当下中国最火热的社交APP。微博产品资深运维架构师王关胜给我们分享新浪微博平台自动化运维演进之路。

https://v.qq.com/txp/iframe/player.html?vid=t0531snl8rx&width=500&height=375&auto=0


Sina Weibo业务介绍微博业务简介

微博平台是属于偏后端的一个产品,它所提供的服务就是固定量的接口,比如信息流里的接口、用户接口、关系接口等等。

微博核心业务

微博最核心的产品就是信息流,以信息流为中心出发,它周边的用户、关系以及通知等主路径的服务都在内部平台,属于核心服务。


微博业务部署结构

我们对于核心业务要求多机房部署,电信和联通机房都部署了完整的链路。


服务保障——服务治理(开发主导)

在这样一个复杂的架构下,运维和开发需要紧密配合。我们内部组织架构调整后,运维团队属于开发团队,配合起来就非常紧密。


内部分为了两个方向。第一个方向的部分是开发主导,运维参与。比如建立完善的SLA体系,我们这个SLA体系做在应用层上,从开发和运维层面在代码上做一些改造,在数据层面上做收集。降级/封禁也是相似的方法,开发在代码上做降级/封禁的入口,具体提供的功能和平台是在运维做的系统里。

服务保障——防御体系(运维主导)

第二个方向就是由运维全程主导,开发参与。例如容量、监控、干预还有运维的部署架构。


架构要做到极简、稳健、美丽;


监控要求具有实时性,报警快、准,覆盖全面;


容量的性能要好,冗余足够,能快速动态扩容,有压测、容量预警;


干预的预案要全,手段多,操作快速,方案细致,要做到干预行之有效。


整体的防御体系要由标准化转化为可视化、自动化,最后升级到智能化。

微博平台运维进化历程

微博平台的运维进化历程大概分成四个阶段。


最早是人工阶段,所有的脚本都要依赖于人工,也就是所谓的脚本时代;


第二阶段是工具系统。当规模有一定的成长之后,做到了工具系统化和运维标准化;


下一个阶段就是综合运维平台。要把很多运维系统做成一个运维平台,就需要让系统平台化、数据API化和运维服务化;


目前我们比较推崇的是利用混合云DCP的思路来做一些系统。


百台规模运维标准化百台规模——一切皆需求

这个阶段主要的工作就是日常的需求对接、完善监控警报、代码的发布和回滚、还有服务的扩缩容以及之前的一些配管工具。


这些工作都要做到快速迭代、快速上线、快速响应。

百台规模——需求达成

当时只需要利用Python、Perl、Shell等去写各种脚本,日常的需求基本都能达成。


我们也在研究一些开源的工具。当时在业务部署的层面最开始是用脚本,后来发现脚本比较麻烦,就改用配管。


百台规模——标准化梳理

配管是该阶段比较核心的内容,需求经过抽象可分为三类,机器上的基础配置、机房相关和业务相关。


所有配置要能通过标准化的配管工具管理起来,每一类服务都进行标准化梳理,就能达到我们这个阶段的目标了。


百台规模——CMDB&配管

新浪在很多部门都会用到Puppet来做配置管理工作。我们当时借鉴了这样一套配管工具,把所有能通过Puppet做的需求在标准化之后尽量用到Puppet。这样就能基本上满足那个阶段的需求。

百台规模——配管UI化

在三大需求之上,我们也给Puppet做了完善管理的UI。与Puppet相关所有配置的需求不再需要通过手工管理,直接UI化,就可以在页面上修改配置,把配置管理起来,再通过Puppet的API下发。满足了当时的需求。


千台规模平台化&可视化
千台规模——挑战性加大

我们面临了很多的挑战:服务器规模线性增长;业务单元线性增长;系统变更及代码上线次数线性增长;大型运营活动及三节保障;每日不定时段的PUSH。所以要做一些工具来满足需求。


但同时也出现了人力成本线性增长、差异化加剧导致认知成本线性增长的问题。

千台规模——构建运维平台

我们当时内部做了一套比较完善的运维管理系统Jpool。它是一个通用的集群管理平台,核心模块包含了用户权限、资源管理、配置管理、部署管理、任务管理、Nginx变更管理、降级/封杀管理和日志查询平台。


Dispatch和Puppet Master组成了这个平台里最核心的部分。Puppet Master管理了配管方面,Dispatch是一个分布式的命令通道。

千台规模——运维平台Joopl框架

千台规模——Joopl核心组件

Dispatch是一个分布式任务调度引擎。在Dispatch里有三大任务线程,任务处理线程、与agent连接的通信协议层及通信线程和主线程。


千台规模——统一运维平台

整合工单流程变更、统一配管系统、统一负载均衡系统、持续集成和监控报警系统这些工具系统,形成完整的运维平台。


平台建成后还能在上面做一些日常的变更手段,例如Puppet/Nginx变更、服务的部署变更、服务降级/封禁、扩容/缩容以及业务docker化。还有其它的像流量切换、限流、数据修复等等都是可以在运维平台上完成的。


万台规模自动化&智能化
万台规模——面临的核心挑战

针对一些突发的娱乐事件,我们需要有峰值应对才能保证服务的稳定。


在这个阶段我们要设置混合云系统,主要从四个点出发。


最核心的是峰值应对,可以进行快速扩容,及时回收;


其次是成本优化,可伸缩的业务利用公有云,私有云的内部进行弹性部署;


打通多语言环境,全公司统一平台,做到运维统一化;


业务快速迭代,基础设施标准化,提高发布效率。

万台规模——峰值应对——混合云DCP

峰值应对:目标“无人值守”的扩缩容

由于近几年突发的爆炸性事件增多,所以我们要做到扩缩容“无人值守”。


基于运维自动化之上再做“无人值守”就需要各种各样的业务指标,而我们的监控可以收集所有的业务指标。有了详细指标就可以做到“无人值守”。



总结:自动化核心——任务调度引擎

一个产品要想发展壮大,必须得有一套完整的任务通道。利用任务通道把所有运维相关的操作抽象为标准化的操作库,加上流程引擎,然后再做统一的任务编排。


有了这四大核心内容,再做平台或自动化思路就比较方便了。



今天要分享的就是这些,谢谢大家!


相关推荐

推荐文章

近期活动



点击【阅读原文】进入干货密道

您可能也对以下帖子感兴趣

文章有问题?点此查看未经处理的缓存