新浪微博平台自动化运维演进之路-阿里云开发者社区

开发者社区> it大咖说> 正文

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

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

_

20170607193304

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

_

点击嘉宾演讲视频观看

Sina Weibo业务介绍

微博业务简介

5

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

微博核心业务

6

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

微博业务部署结构

7

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

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

8

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

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

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

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

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

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

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

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

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

微博平台运维进化历程

微博平台的运维进化历程大概分成四个阶段。
最早是人工阶段,所有的脚本都要依赖于人工,也就是所谓的脚本时代;

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

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

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

百台规模运维标准化

百台规模——一切皆需求

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

百台规模——需求达成

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

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

百台规模——标准化梳理

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

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

百台规模——CMDB&配管

9

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

百台规模——配管UI化

10

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

千台规模平台化&可视化

千台规模——挑战性加大

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

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

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

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

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

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

11

千台规模——Joopl核心组件

12

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

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

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

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

万台规模自动化&智能化

万台规模——面临的核心挑战

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

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

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

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

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

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

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

13

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

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

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

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

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

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

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

相关推荐

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

版权声明:本文内容由阿里云实名注册用户自发贡献,版权归原作者所有,阿里云开发者社区不拥有其著作权,亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容,填写侵权投诉表单进行举报,一经查实,本社区将立刻删除涉嫌侵权内容。

相关文章
关于自动化运维的思考-基线
DevOps几年前来看,基本都在提概念,这几年很多公司都在落地了,公司里每个自动化运维平台都不好意思。具体落实下来,做得好还是不好,水平也层次不齐。 我们不说自动化运维的意义,不讨论要不要做自动化运维。
1351 0
阿里云服务器端口号设置
阿里云服务器初级使用者可能面临的问题之一. 使用tomcat或者其他服务器软件设置端口号后,比如 一些不是默认的, mysql的 3306, mssql的1433,有时候打不开网页, 原因是没有在ecs安全组去设置这个端口号. 解决: 点击ecs下网络和安全下的安全组 在弹出的安全组中,如果没有就新建安全组,然后点击配置规则 最后如上图点击添加...或快速创建.   have fun!  将编程看作是一门艺术,而不单单是个技术。
4504 0
《Python自动化运维:技术与最佳实践》一导读
由于Python具有脚本语言的特点,学习资源多,社区非常活跃,且在Linux平台默认已安装等优势。Python已经是当今运维领域最流行程的开发语言之一
2839 0
一直播、小咖秀大数据自动化运维实践
在高速成长发展型企业,我们需要大数据做得更多的不是平台,不是让平台做得多么好,让各个部门使用,而是让平台提升用户增长、扩大营收,有些处于高速发展期和成长期的公司可能跟我们面临同样的问题,大家可以共同探讨。
3078 0
函数计算进行自动化运维专题
在传统的运维中,对于定时任务的处理通常用crontab脚本来实现,但是一旦管理的机器多了,必定会对脚本进行集中管理,这个时候对集中管理脚本的机器的可用性、脚本里面会散落密码明文等相关信息以及定时任务执行的记录都是一个很大的挑战;而对于事件驱动的报警处理,要么是通过短信报警告知运维人员,要么需要自建服务来处理报警信息, 无论是哪种方式,财务成本和运维成本都很大。本文探讨一种新的运维方式,利用函数计算做自动化运维,以极低的成本就可以获得一个高可靠,高质量的运维服务。
246 0
+关注
it大咖说
大咖干货,不再错过
28
文章
0
问答
文章排行榜
最热
最新
相关电子书
更多
文娱运维技术
立即下载
《SaaS模式云原生数据仓库应用场景实践》
立即下载
《看见新力量:二》电子书
立即下载