Tencent运营10年,微服务结构下的运营平台创设

2020-04-09 作者:亚洲城动态   |   浏览(94)

十年不苟且的运维之路

3月12日,优维科技与又拍云联合举办的Open Talk No.29《云上运维与研发最佳实践》在上海顺利举行,优维科技CTO黎明带来了《微服务架构下的运维平台构建》的精彩分享,结合微服务架构特点,解读如何构建一个高效运维管理平台。

加入腾讯已十年的运维老兵,回顾这十年:

黎明:带领团队自主研发全栈DevOps运维管理平台——EasyOps,是目前行业领先的智能化运维管理平台。

2004年:加入腾讯,做贺卡开发;2005年:加入QQ空间开发团队,负责留言版模块;2006年~至今:公司组织架构调整,接触运维工作。

曾是腾讯最复杂业务部门的运维研发负责人,主导了多个运维系统研发舆情监控、大数据监控平台、CMDB、实时日志分析平台、织云、客户端体验监控等。

期间,他带领运维团队负责QQ延伸出来的各种社群的运维和维护,包括QQ空间、QQ音乐、QQ会员、QQ秀等一系列的QQ产品。团队89个人,维护了10万家服务器。经历的大事件有:红米在QQ空间首发时,90 秒卖出 10 万台设备,获得1亿点赞;天津大爆炸事件,把天津 2 亿多活跃用户,从天津快速调到深圳以及上海;春节红包准备工作,2016年比2015年的红包访问量增长了10倍 ,快速的扩充了 5000 台设备,最高访问量达到 477 万次/秒。

以下为黎明分享稿,经编者整理。

不要让自己变成一个救火队员

今天演讲的主要内容有三点:

作为运维,最重要的是先保证自己做的系统可靠、不会轻易出错,不要让自己变成一个救火队员。可靠之后,就要用更多时间去解决效率问题,让工作变得更加高效,追求更高的目标。

1、微服务架构特点及其传统巨石架构的差异,以及传统运维工具面临的挑战;

对团队工作帮助最大的是什么?

2、面向微服务的运维平台架构;

资源管理:把写出来的程序和代码,进行清晰划分和分类,对每个资源采用不同形式进行搭建;容错方案:在维护海量服务、运维过程中出现故障时,确保不能影响项目服务,服务器要做到及时处理;统一架构 CMDBA:把一个业务模块上所有依赖资源全部登记进去;同时如果做快速决策和调度,还需要有效的监控。DLP:内部定义的一个非常关键的监控,这个点发生后,可以知道哪里出现故障;

3、运维平台微服务进化。

入口监控:告知出现故障的根源在哪儿,容错方案的 L5 是用来解决容错、灰度,路由等。

一、 微服务架构与巨石架构的差异

运维团队的五个“杀手锏”1.L5系统

“微服务”与“巨石架构”两者并非对立,而是分别针对不同场景的解决方案。

世界上管理服务器最多的系统

巨石架构指将所有“大脑”集中在一起,以CS架构为代表,将所有的逻辑放在唯一应用中,再加入前端UI组件、Service、MVC架构、数据库等部分。它的技术架构不复杂,调试、部署、管理方便,是适用于绝大部分系统的解决方案。

运营管理系统管理了上亿服务器,脉络非常清晰,根本不会出现混乱。L5 系统也类似于 DNS 系统,有一排能提供的服务模块,从而解决的单点问题。

但是在互联网要求“多、快、好、省”的应用场景下,“巨石架构”面临诸多挑战。

L5 如何做容错?

多:互联网用户量巨大,达百万级在线量;

L5-主机/接口级的容错原理

快:服务请求反应速度要在一秒以内甚至更快;

L5 有由 L5、DNS 和 L5、agent 两部分构成。CGI 通过给模块提 ID,根据模块下设备的成功率和延迟情况,通过 IP PROT 给 CGI 一个反馈,访问之后,通过成功率和延迟情况,把数据上报给了 L5agent,然后做统计数据。当发现失败率特别低的时踢掉。当发现成功率和失败率有一定下降,会把访问权重降低,从而达到容错和负载均衡的作用。

好:服务质量稳定性要高;

可以注册一个模块,加多台设备,形成容错效果。如发现一台机器失败率很高,就把它踢掉。它成功率恢复过来,还可以再加回来。

省:硬件成本增涨要低于用户量增涨速度。

新加一台服务器设计它的权重为 1,假如之前的是 100,可以逐渐上线。还可以给它一个得分,得分下降的时候,快速把它踢掉。L5 具有灰度、容错、路由、负载均衡的能力。

如何解决这四个问题——增强整个平台的灵活性。

L5 对运维团队有哪些帮助?

平台扩展能力

减少了 80~90% 的日常故障;不再需要频繁的变更 ip port;同过名字便利的服务上下线;通过权重灰度上线;模块访问关系可帮助定位根源故障;接口的延迟和失败率可用来监控;

1.平行扩展:一般的无状态服务器可以通过服务器扩容完成平行扩展;

集容错、负载均衡、路由、灰度、监控能力于一身。

2.分区:对于有状态的服务可以通过分区增强平台灵活性,如:南北方用户分属A、B不同集群。

2.统一框架和架构

平台上的扩展“巨石架构”可以适应,但是功能上的扩展却比较难适应。

团队里有上千号开发同事,每年会有大量毕业生加入,也会有社交同事。进来以后,都希望为平台做更多的代码贡献、展现自己的技术实力,亦或是提高自己。

功能扩展能力

那么,问题来了。在开发过程中,如下图,有管道、消息队列、信息文件锁、记录锁、文件影射内存、还有迭代服务器 Select poll Io 等,这些是用各种各样技术组合生产出来的代码,交给团队维护,数以万计不同性格的服务器,要掌握得非常好,了解它的工作机制和原理,更好的维护它基本上是不可能的。

功能维度上,如何使系统变得更融洽?

那怎么办呢?把网络通讯部分列成一个标准框架,提高它的通讯效率,统一维护。

1.灵活控制成本:局部调整,变更模块、逻辑,而不是整个系统去修改。

统一框架

巨石架构的所有模块都捆绑在一起,进行扩展时,由于每个模块巨大,只能高成本平行整体扩容。

业务逻辑部分用 SO 动态库方式编写与框架分离部署,类似 Web 服务器上的CGI。接入层用 QZHTTP,逻辑层是 SPP 和 SF 的框架。

微服务架构下模块产品的服务器分布非常灵活,扩容成本低,现在都会选择将服务器模块切分,进行微服务化改造,提升平台支撑能力。

作为社区类服务,虽然用户的热点并不是很集中,但数据量、访问量还是很大。大量用 CKV 存储,同时针对访问量非常大的问题,如说用户没有开通空间,游戏用户,会员等标记,之后均做一个定位,形成一个高访问量的模块即可。

二、微服务架构下如何构建一个运维管理平台

如下图,是一个架构体系:

上文讲述了微服务架构与巨石架构的差异,接下来了解如何构建一个运维管理平台。

接入层是 TGW,流量从它进、从它出;中间层,利用 L5 进行调度;

运维平台管理最重要的是应用。对于应用运维来说,系统的前端所接入的官网、中间的逻辑服务,后端的存储、缓存,分属于不同的运维。

存储层,因为每一个存储模块要分耗段,故加入 Access,从上到下把技术架构进行了统一规范,同时在组织上也通过接入逻辑运维层,进行标准化的维护。

把运维平台拆分成三块具体化部件对应到工作中。

统一框架对运维有什么帮助?

运维平台的内部应用、内部依赖是什么?——程序、配置文件、计算的资源

网络框架和业务逻辑 SO 分离管理、运维人员学习成本大大降低、框架稳定性极大提高、可跨业务统一维护、运维效率提升最高可达 10 倍。3.资源打包管理

是什么支撑运维平台作为一个互联网应用?——内存、CPU

如上图,资源打包管理是对开发出的程序包进行标准打包操作,一个程序开发出来有不同特征,有需要加银行参数,有需要依赖目录,还有需要前面准备工作和后续善后工作。

运维平台依赖的资源有哪些?——系统镜像

把它全部放在一个类似于包里面,装进一个盒子里。之后提供标准的操作接口,如安装、卸载、启动、停止操作等这些操作让它们变成有关联的。

这是CMDB IT资源管理系统要承载的,在自动化扩容、环境部署时,只有了解这些数据,上层系统才知道如何构建这个应用。很多运维团队,仅仅做到“工具化”,却没有跟“资源管理配置”联动起来。

资源打包管理对运维有什么帮助?

资源有效管理之后,是研发、运维这类的动作管理。如:版本更新,迁移服务、搭建测试环境等标准化的动作。

部署规范统一,再也不担心找不到、标准化了操作界面,极易学习掌握、支持前后置脚本做准备和善、进程级运转的所有资源的完整镜像。

在拥有资源和动作,达成自动化运维的闭环后。运维人员只需事前维护好准确的资源配置数据(CMDB),余下动作系统会自驱完成。如果把资源跟动作相混杂,每次运用都需要耗费资源定制专用的发布脚本、构建脚本。

4.资源登记—CMDB 虚拟镜像

除了资源跟动作管理,还有状态(监控)管理。每个公司都会有“监控”系统。这里需要强调的是意识的问题,因为在整个上层、应用层监控设计中考虑了“自动容灾切换”能力,所以我们不需要关注底层的监控。只要应用层没有告警,不用管底层服务器和机房是否挂掉。

资源登记到二级 CMDB 形成服务的虚拟镜像,除了传统基础配置信息,把一个模块依赖的资源,全部记录进 2 级 CMDB,形成一个模块的虚拟镜像。

我刚参加工作时,系统经常告警,需要半夜爬起来重启机器、删文件。现在运维只会接到通知,告知服务器挂掉,进行确认,不用实时处理。基于这个逻辑,在业务没有告警的情况下,我们系统就是正常的。

CMDB+资源=虚拟镜像

完善的运维管理平台能够合理的把资源、动作、状态协调管理。

CMDB 虚拟镜像对运维有什么帮助?

这张图将上面那张简单的图做了扩展、细分。

一个模块运转的所有资源的“完整镜像”、记录了模块运转所依赖的所有资源、不再需要文档说明。

最上面是面向运维,包含运维、研发者的服务目录和日常任务中心、状态中心的统一运维门户。

5.决策调度—自动化部署平台

下面是调度编排系统,产品扩展根据不同行业及其业务特性,做出不同编排需求,将这些不同的需求选项进行固化。

在团队内部有织云自动化部署平台,从申请设备获取资源、发布部署、检测,进行测试,上线。在每个环节还有些细节步骤,如申请设备的时屏蔽告警事件,如发布时同步传输文件、如发布后检测程序的包进程是否启动,启动之后进行业务测试。

中间是运维平台的核心,执行层的系统。忽略灰色的传统API模块,现在我们运维日常使用的就是这个包括持续交付平台、统一监控平台和ITOA运营分析平台在内的立体化监控系统,通过它实现动作、状态管理。针对基础设施、平台系统、应用级、服务级甚至更高层的需求,提供精确度、优先级不同的接口。

自动部署流程 23 步

底层是CMDB资源管理。传统CMDB管理对象,属于硬件资产。在云化技术发展之后,会越来越弱化。应用运维就不需要关注太多。这里CMDB包含了业务信息管理、应用程序包、配置、定时调度任务、流程、工具、权限、系统配置等基础资源。

如下图,是我们内部自动化部署的平台。相当于把这个进程开发出来以后,依赖的资源全部打包放在盒子里,把盒子里的东西放资源仓库中,有一些模块全部登记在 CMDB。

三、运维平台的微服务进化

自动化运维体系

伴随着公司业务的发展,如何将正在应用的系统进行架构上的优化或者规划?

如果要部署一个模块 A 或进行扩容,可以人工触发或自动系统触发。

1.技术选型

控制人工系统进行操作,把模块边上三个资源,由资源仓储部署在模块 1 上,通过 L5 系统进行一个注册,这个模块就可自动上线。之后会把一个模块登记回来,对它进行自动化操作,每一个方块是一个步骤,这个步骤执行过去之后是绿色的,执行失败是红色,没有执行是灰色。

首先,微服务跟基础架构的区别在于,微服务的组件拆分后是通过网络传输的。因此通讯标准要做出合理的选型。

执行成功就可以看到,可以做自动化的扩容,可以做日常演习,还可以回收等工作。

微服务的架构,通常是异构架构。比如我们的平台运用了Python、JAVA、PHP等语言,必须选择同时兼容多种语言的协议。就像我们之前选用protobuf时,发现Python自带的库兼容Linux系统不成熟。在不同场景下,微服务的技术选型需要有较强的兼容性。

全自动扩缩容

其次是语言的选择。微服务强调接口的稳定性,在保证服务稳定的情况下,可以自由选择熟悉的语言。

运维规范的推进历程

2.微服务的规划

如下图,是运维规范的推进历程。看起来是自然而然的过来。但实际上这个过程并没有那么容易。

单一职责原则:每个服务应该负责该功能的一个单独的部分。

作者:

明确发布接口:每个服务都会发布定义明确的接口,而且保持不变,消费者只关心接口而对于被消费的服务没有任何运行依赖;

赵建春,腾讯社交网络运营部助理总经理、技术运营通道会长、专家工程师。04年加入腾讯,先后从事过研发、运维、数据方面的建设和管理工作,在海量技术运营方面积累了丰富的实战经验。

独立部署、升级、扩展和替换:每个服务都可以单独部署及重新部署而不影响整个系统,这使得服务很容易升级与扩展。

3. 平台构建

通过下面的两个模块来讲解平台的架构。

1) CMDB系统怎样做简单的分拆,使之更容易维护?

CMDB是一个有大量配置系统存在的可以进行查询、修改的数据库管理系统,它的内部包含模型管理,配置管理、自动发现。

A)模型管理

CMDB中,我们会管理大量随着产品技术站演进动态变化的资源和相异的动作,所以要独立出模型管理的模块,保证CMDB动态可调整。

B)配置管理

由于CMDB的信息敏感度高,很多公司要求,将敏感业务信息,特别是应用和IP这类关联关系的信息保存在里面。

C)自动发现

如果CMDB没有完善的自动发现机制,它失败的概率会非常高。就像传统CMDB有一个在严谨的审批机制运行下的配置变更流程。但是即使在配置跟现网一致的情况下,还是需要每半年进行一次资产盘整,对信息进行纠正。对于有海量业务的系统来说,没有“自动发现”能力的CMDB是不合格的

通过“自动发现”,去自动化采集服务器带宽、网卡速度、内存、磁盘空间、进程等信息,由CMDB进行管理。模块管理相对传统,“自动发现”是CMDB的核心,在同时管理数十万台服务器时,只能通过“自动发现”的探侦才能进行自动化维护。

2) 持续部署系统

持续部署系统负责自动化发布。上图将持续部署系统的平台构建分为多个子模块。

A) 构建管理

构建即以静态图片、业务程序、配置文件等为主的部署对象。根据DevOps中的原则,需要将一切版本化。所以需要一个构建库负责管理所有发布到生产环境的资源。

通过统一的构建库,对所有发布到线网上的数据进行标准化管理,以此可以快速在其他机房重建原系统等。同时它还拥有信息共享功能,过去运维发包之后跟踪困难,现在研发人员只需向构建库输入版本信息,运维从构建库中导出就好了。

B) 任务管理

任务库负责存储日常发布任务,满足自动化发布需求。曾经由于很多研发人员贪图方便,选择在现网直接更改系统,记录信息错乱变更很不利于任务管理的日常下发。

常常是错误的,所以我们并不使用“任务下发完成之后,系统设置自动更新”这种设计。在无法信任上层管理系统的情况下,现网信息、数据必须实时扫描上报。

为了保证信息的发布成功,必须以Agent上报的信息为准。因为配置信息存在大量变更入口,在无法保证唯一入口的情况下,不能想当然的设计系统。

命令通道与数据通道是除了构建库、任务库、实例库之外的上层系统的基本构成。首先命令通道与数据通道需要分开管理。腾讯曾经需要将1G的文件发送到两千台服务器,频率达到一周一次,一次一周,不断重试、失败。后来将命令与数据切开,每次只传输几十K的命令脚本,服务器再也没有阻塞。

开源方案部分问题依旧无法解决,像现在的异构网络,在混合云的场景下,必须保证网络互通,才能做到直连。大家可以选择自己去编写Agent练手,通过反向通道连接中心管理服务器去解决此问题。

微服务架构下平台架构的底层基础服务

1.名字服务

名字服务指通过配置文件中匹配的名字查IP端口的服务,可以选择合适的开源方案。如果自研的话,可以对服务进行灵活分区等。如深圳的服务器A访问在深圳、上海两地均部署服务的B,我们只需要在,名字服务中与CMDB打通,使用深圳的服务器访问深圳的IP,达到同城访问的效果。这个操作在开源方案中就无法完美实现。

  1. 状态监控。

要求能达到接口即调用数据采集的应用层监控。

通过访问量、成功率、平均时延这三个核心指标,低成本把握绝大部分需求。以访问量为例,当访问失败率上升告警时,直接触发名字服务联动,将故障节点自动摘除。

3.负载均衡。

当系统规模扩大,节点剧增时,增加中间代理的方法会增加系统内部压力。

如果落地到Agent,通过名字服务查询IP列表,合并状态信息,均衡节点请求,可以更好的达到负载均衡。

负载均衡的极端就是容灾,正常情况下根据性能状况保证每个节点处理合适的请求量即可。

这三点是运维平台或业务生产的系统中的核心能力。包括腾讯在内的运维平台都是基于这三个服务闭环去运行的。只有在做到这三点,才能解决系统异常,维持系统的正常运转。

微服务运维平台的迭代重心

其实我们在平台构建的时候,在整个的平台进化的过程中,其实是要有优先级,要有取舍的。总得来说,优先要解决我们的瓶颈问题。 然后是平行扩展的能力,还有考虑服务复用的能力,甚至是一些开源的解决方案的利用。但是开源这个东西,我从来不觉得是说大家把一堆的开源工具用在一起,能够形成一个很好的一个运维平台。

大家应该是把这些开源的能力,这些一个个的微服务,核心的这个架构还是必须要有自己的控制力在这里。比如:监控。很多开源的系统,它是更偏重于执行层的工具,但是核心的CMDB,核心的流程控制还是需要我们去建设的。

本文由yzc216亚洲城发布于亚洲城动态,转载请注明出处:Tencent运营10年,微服务结构下的运营平台创设

关键词: 亚洲城官网 yzc216亚洲城