虎扑体育运维优化经验分享

 

目前移动互联网运维需要什么?我们总结三点:稳定:移动互联网业务要上线,我们肯定要提供稳定的服务给用户,让用户...

个人介绍


赵稀露 虎扑体育系统运维部负责人,10年的it从业经验,做过IT、SA、DBA、架构师,目前负责虎扑整体运维框架设计与成本、效率优化。
内容简介
《虎扑体育运维优化经验分享》

主题简介:

虎扑体育运维体系概况

虎扑体育运维碰到过的问题

虎扑体育APP架构演进

理想网站运维体系/我们的努力方向目前移动互联网运维需要什么?

我们总结三点:

稳定:移动互联网业务要上线,我们肯定要提供稳定的服务给用户,让用户随处随地随时可以访问得到。
效率:我们产品在更新迭代的过程中,会不断的提出新的需求,所以我们需要不停的强化,提高我们的效率,更好的支持我们产品的功能上线,
成本:每个做产品的公司都希望自己的成本足够低,利润足够的高。



虎扑运维这概况

目前我们团队有8个人,管理着1千多台服务器,100多个项目,网站最高的并发是百万级



这个是我们在2014年到2016年我们线上所有生产服务器数量增长的情况,从这张图可以看得出,我们的业务呈现的是一个上升趋势。可能跟大牛公司比较,目前体量还是比较小,但对我们来说是一个极大的挑战。



这个数字是我最近才统计出来的,是我们每天代码提交生产的部署次数,我们从14年的时候平均每天是3次的提交,到现在每天大概是平均42次,最高一次是在4月28号,有133次。



针对于上面两组数据我们在虎扑运维过程中我们碰到过许多问题,后面我会针对我们所碰到的问题,介绍下如何把这些问题做解决的。

这是我们在工作中经常会碰到的一个事情,就是资源申请这块。我们最终把它归纳为我们资源利用率,我们在14年以前整体属于传统PC架构,用的都是实体机。

随着我们业务需求的变化,经常会提出各种各样的需求,比如“我们一个项目需要50个服务器、要部署20个tomcat、需要100个redis、我们要做业务拆分”。可我们资源池里面根本没有办法支撑这个业务。当时在想“如何改变这个现状”,最终我们的决定去建设一个新的资源池。

虎扑成立之初服务器是托管在传统机房,这个机房体量比较小,没做到一个合理的架构规划,等到我们发展壮大后,发现机房整体机柜、带宽成为业务发展的瓶颈。我们希望在现有情况下把资源更充分的利用起来,最后决定通过KVM虚拟化的方式来做。当时立了一个项“建设虚拟化服务器资源池”。

在做这件事情的时候,分成了六步去完成。

我们目前项目有100多个,在没有建设服务器资源池的时候,我们的项目有多少个是不清楚的,有很多历史原因。

业务要上线有可能是客户的需求,也有可能是项目临时活动的需求。经常碰到的是“xx我今天有一个新的业务上线,你需要给我准备一个服务器,我们需要快速投入到生产,推送到我们的用户”。这个项目上线完了以后,需求方未告知什么时候下线,所以一直保留在线上。

第一步我们做了一个项目梳理,把我们的项目分成了三类,

第一类:无用。

第二类:项目架构清晰。

第三类:耦合度高。

考虑到我们传统的IDC这边我们的机柜和网络带宽资源是有限的,公有云服务也是未来的一个趋势,当时我们定了两个方案:

第一个方案,是组建我们内部的虚拟化的资源池,对核心业务进行解耦重构。

第二个方案,把非核心业务往云端做迁移。

我们运维根据这两个方案,把我们的项目做了一个具体的排期,逐步对线上业务进行腾挪,最终实现了项目间的解耦。

我们在做服务器资源池建设的时候,我们碰到过很多问题,最常见的就是这个。

由于历史的原因,很多的配置都是手动通过脚本推送到线上,当时为了图快,没有做有效的管理。当时在做项目梳理过程当中,经常出现由于配置变更导致的各类线上的事故。记得15年的时候因为配置变更,导致线上有三个P1的故障。然后我们就痛定思痛,怎么去解决这件事情。

我们最终定的目标是标准化的建设,我们把要梳理的项目都列出来,我们逐个去解决。跟大家讲一下我们中间的小故事。

比如服务器命名,起名是一件很难的事情,很多项目和业务之间没有一个必然的关系。举个例子:线下篮球赛这个项目,项目组没有给到线上业务的名称,大家拍个脑袋,要不然就叫3x3吧,这样项目名称定好了;有的时候我们项目可能连名称都没有,这时服务器要上线我们会用资产编号来代替。最终带给我的困扰就是,等我们开始做服务器架构梳理的时候,我们没有办法很快速的定位我们项目和对应项目的应用服务器,没有办法给到团队成员一个清晰的列表。标准化第一件事情就是对线上业务服务器命名做统一的规范,我们现在命名规范是这样做的。

最开始的时候前端服务器用的是传统架构,没有统一的公网管理的规范,以前业务要上线,要和外部业务团队做对接,或者是开放一些外部数据访问权限的时候,我们会把公网直接暴露给用户,当时我们选用的技术解决方案也比较多,LVS、Nginx、Haproxy这个对我们统一管理带来很大的问题。

这些技术大多数人都会,但在整个项目层面来看,管理的差异化会导致失控。针对这个问题,我们决定:一、需要收敛公网访问;二、对公网的权限、安全做统一控制。这个项目叫做“张无忌”。

张无忌的架构设计是通过交换机的四层OSPF+LVS+Ngix,用来实现我们统一的公网管理。LB的统一管理有的很多方案,运维架构都应该适合业务本身。

我们做这件事情的时候,对前、后端的业务服务器进行梳理,并对业务之间调用进行了解偶,对业务也做了规范的命名,按类型划分,最终统一了整套系统应用架构。

以前线上的环境,会让研发上去部署维护,因为研发和运维缺失统一的配置管理,以至于到后面我们线上的配置变更出现了问题,我们都很难去定位。发现这个问题后,把我们的应用拆分了,放到GIT上进行统一管理,并且按项目的维度部署我们的应用服务,只有我们统一了才不会出现配置不一致的问题。

目前我们用GIT来做统一管理的应用服务配置管理。

在优化的过程中,我们遇到过业务耦合度太高,出问题很难定位的情况。我们通过逐步虚拟化的方案,推动我们的产品、研发,进行业务端代码的解耦。比如:在A项目中,我们会根据业务的不同属性,我们去定义它的服务类型,我们去把它最小的一个服务的单元,单独抽象出来,把后端所调用的数据完全做去中心化的数据的管理,我们希望把我们以前单体的架构方式,改造成三层服务架构。



另外就是逐步的把非核心的业务往云端做迁移,这类业务平时没有太大的访问量,如果碰到业务推广或是活动宣传,可能会出现短时间大并发,使用云端的好处就是可以很方便进行弹性扩容。



我们对业务系统解耦、去单点,主要是推行服务化来推行。简单的说,一个服务A,如果要受B或C, D同时调用时,会受到其他业务并发的影响,从而不能可用的服务,产生各种性能的瓶颈。这个时候我们会对A中的服务进行拆分,再单独提供给相关业务调用。

运维在线上处理问题最痛苦的莫过于无法及时看到线上系统日志,无法快速的定位问题根因。在做业务拆分的时候我们整套日志系统搜集的量是爆增的,导致经常高峰期日志数据有延迟,日志搜集系统用的是Elasticsearch、agent使用fluentd。

为了优化这个问题,我们引入了kafka+logstash解决fluentd的日志转发性能问题,通过一系列的优化,使得我们在高峰期的日志的接入的延迟大概在30秒以内。

后续我们制作了一些自定义面板,日常定位问题的时候,可解放运维双手,哪里出问题找哪里。

后面我们简单介绍一下虎扑体育APP的架构演进,过程是通过迁移、解耦、逐渐服务化来实施的。

这个是我们现在最开始的一版虎扑APP的架构,当时可以看到是1.0。

我们虎扑APP主要分三大块:一、新闻;二、文字直播;三、房间。当时文字直播这块功能会经常出问题。主要是在高峰期那一段时间内,我们全站的用户都会集中对这几个模块进行访问,为了解决这个问题我们对后端的缓存和DB做了一个拆分。

改进后的一个架构,把DB和KV层(NOSQL)做了拆分、解耦,前端web还未做。

后面优化的过程中我们发现,服务器负载过高后,所有业务系统都无法正常访问,服务无法实现降级,我们又开始对前端服务进行了业务拆分,业务层级的关系一并梳理了。

这是我们目前整套应用的架构。

这个是我们其中一块KQ消息推送基础架构,以前都是混在一起的应用服务,拆分成独立应用模块后,可以方便的定位问题并及时解决。

运维努力的方向

一、应用本身

  • 逐渐实现业务的标准化,标准化带来的好处是效率的提升,并控制了运维成本,实现业务稳定。
二、监控

  • 提供实时业务数据监控,便于运维更快速的定位问题,对线上服务降级,提升业务稳定性。
三、自动化

  • 应用部署自动化,加快我们上线效率。

END


    关注 虎扑技术


微信扫一扫关注公众号

0 个评论

要回复文章请先登录注册