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

    xiaoxiao2021-04-18  273

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

    点击嘉宾演讲视频观看

    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

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

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

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

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

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

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

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

    相关推荐

    XpmJS —— 小程序后端开发思考和实践魅族推荐平台架构近期活动活动 | 区块链技术如何改变我们的生活活动 | 一起出发,吹响Container+的号角

    相关资源:新年快乐! python实现绚烂的烟花绽放效果

    最新回复(0)