携程第四代架构探秘之运维基础架构

从携程到知乎,运维人该如何觉醒?

最近互联网也是非常有意思,接二连三的发生故障,让我们一起先回顾一下。

2015年5月11号晚上21点左右开始,网易的网易新闻、云音乐、易信、有道云笔记等移动应用均无法正常刷新,网易名下的游戏也全线瘫痪。故障原因:骨干网络遭受攻击。

2015年5月27日下午,部分用户反映其支付宝出现网络故障,账号无法登录或支付。故障原因:光纤挖断。影响时长:4个小时

2015年5月28日上午11:09,携程官网及APP出现故障无法打开,到28日23:29全面恢复,整个过程耗费12个多小时。故障原因:误操作。影响时长:12个小时左右

2015年6月5日
今日头条网首页和APP都无法访问,直接提示500错误。故障原因:不明
影响时长:30分钟左右。

2015年6月15日12点30分
知乎网无法打开,直接提示服务器提出了一个问题】错误,在13点45分左右的时候,知乎页面恢复正常。故障原因:机房故障
影响时长:60分钟左右

 图片 1

到底是怎么了,是什么让我们的互联网业务如此脆弱?真的是运营商老是在后面干坏事?还是我们的系统架构不给力?还是我们运维能力真的很弱?如果广义的去看这个,我还会把它归结成运维问题。不过对于以上的故障,从运维的角度来说,我依然会说官方结论不够专业,希望内部不是这样的哈。

1、网易说骨干网收到网络攻击影响业务,貌似那天好像也就网易业务受到影响?

2、光纤挖断影响四个小时,从这么核心的业务来说,第一原则一定是恢复业务,我想支付宝即使没做双活,肯定也会有一个可用的备份中心,为什么没切过去了?一定是内部出了乱子。不过阿里流弊的地方,负面的事情他可以变成正面,他们把”5.27″变成了技术保障日,大肆宣传。

3、携程事件,我之前写过一篇文章携程事件:运维债务的深度分析和解决方案】,不详谈了。

4、今日头条,500内部错误,这条新闻可以让自己上头条,但也没有正式的给出解释。从500错误的恢复时间来说,有点长,500错误是十分好定位,我的怀疑是数据库的压力不够,导致后面的扩容变更,也只有数据库分库分表扩容时间需要这么长了。另外头条君的首页上直接给个500的错误,技术表述,十分的不友好,建议你服务降级啊,推个大众版的新闻,不做个性化推荐,这个可以做一个缓存就可以解决的。

5、知乎故障,直接说是机房故障,太简单了,但我觉得最大的可能应该是Tengine后端服务超时导致的,而非简单的一个机房故障引起。

在每一次故障发生的时候,其实都是伤害了我们的用户,内部的表述就是可用性或者质量。因此我们必须要足够的重视,更需要我们把它变成宝贵的经验。那到底什么是可用性和可靠性?影响可用性的因素有哪些?运维如何提高可用性?等等。

一、什么是可用性和可靠性

可靠性是在给定的时间间隔和给定条件下,系统能正确执行其功能的概率。可用性是指系统在执行任务的任意时刻能正常工作的概率。先来看一些指标定义:

  1. MTBF——全称是Mean Time Between
    Failure,即平均无故障工作时间。就是从新的产品在规定的工作环境条件下开始工作到出现第一个故障的时间的平均值。MTBF越长表示可靠性越高正确工作能力越强

  2. MTTR——全称是Mean Time To
    Repair,即平均修复时间。是指可修复产品的平均修复时间,就是从出现故障到修复中间的这段时间。MTTR越短表示易恢复性越好。

  3. MTTF——全称是Mean Time To
    Failure,即平均失效时间。系统平均能够正常运行多长时间,才发生一次故障。系统的可靠性越高,平均无故障时间越长。

可用性Availability = MTBF / (MTBF +
MTTR),一般我们都是用N个9来表达系统可用性,用宕机时长来说更好理解,如果以全年为周期(24*365=8760个小时),3个9(99.9%)就意味着全年宕机时长是525.6分钟,4个9(99.99%)是52.6分钟,5个9(99.999%)是5分钟。

从这些时间指标上可以反向去推导IT能力不足的地方,比如说一个故障恢复时间很长,一定是自动恢复、运维意识、处理过程、系统架构等地方不对,导致了这个宕机时间过长;平均失效时间短,一定是系统的可靠性出了问题,找技术设计的问题,找依赖的硬件环境问题等等

二、影响可用性的因素

影响可用性的因素非常的多,但是可以从几个维度去看,人与组织、流程、技术和业务管理等四个维度。

1、人与组织

其实这个地方可以谈谈你的人和组织类型了,领导是否重视IT?是否重视运维?组织是否已经认识IT带来的价值,把IT当作自己的一个核心能力来看待?是否把面向用户的业务能力和IT能力很好的对接?是否建立起用户质量的组织文化?等等。

2、流程

流程是梳理多个角色自己的关系和职责。我们第一个要去看这个流程在面对故障的是否起到了积极的作用,比如说能够确保故障信息的准确送达,同时保证处理人的角色和职责是清晰的。其次不断去检查流程是否可以自动化驱动,而非人为驱动。人是不可靠之源!我们最终希望形成是一个自动化、标准化的流程,这样的流程不容易被异化,且能保证预期执行结果一致。

3、技术

很多时候大家看到的技术是运维技术,其实恰恰相反对于互联网业务来说,对其高可用的影响,必然是业务IT技术架构,因此在其中需要遵循很多原则,有一些原则需要有普适的参考价值。比如说服务降级、灰度发布、过载保护、服务公共化等等。这些方法论是否已经融入到研发和运维的架构设计哲学之中?现实是产品功能需求优先,而非可运维性优先,可运维性最终就是业务的质量。

4、业务管理

把你的IT能力最终都业务能力看板化,你可以转换成我们多个业务指标,比如说质量、可用性、用户体验、用户满意度、成本等等,有了这些业务导向性指标,才能把IT能力和业务更好的对接起来。否则很容易在组织内,形成“IT是支撑部门”认识,而非创造价值部门。这一点还有一个重要性,就是让IT部门也要足够的认识到,他们的能力直接和业务相关,需要增强业务敏感度。

三、如何提高系统的可用性

刚刚上面讲到了影响可用性的因素,分成了四个方面,但我想提高系统的可用性从另外一个角度来描述,能把握一些核心准则(其实还有更多)。

1、故障发生前,建立运维质量仪表盘

我们一定要建立运维数据看板,这个看板的数据并且要在业务、研发、测试和运维达成一致,让大家足够重视这份数据,这样数据便有了推动力。建议这个地方的核心数据指标不要太多,因为涉及到多个团队,大家不能够一致理解,特别是传达到管理层,太多的指标,容易失去关注的焦点。

通行的做法,就是用可用性来做运维的数据看板。可用性的计算方法有简单的方法,也有复杂的方法。简单的方法就是在监控系统中搞一些探针来模拟用户监控,最后我们能得出故障的时长和可用性的时间,这样我们可以建立每天、每周、每月、每Q的可用性,可以做到分业务、分服务(更细粒度)等等;复杂的方法在模拟数据的基础上,可以把事件系统记录的时间数据拿过来作为评估的标准。另外可以把可用性上升到质量层面,这个里面涉及到的评估维度(成本、用户体验、满意度)就更多了,数据获取的来源也变得更多,有些是来自于客服系统,有些是来自于舆情监控,有些是来自于运维容量系统,有些是来自于事件系统等等,不过最终呈现的指标就是一个—质量。

运维的数据看板,最好能变成产研侧KPI的一部分,同时在运维和研发侧,需要周期性的把这份数据推送到他们面前。有了KPI,同时有了持续滚动机制,一定能建立起很好的业务质量意识。

一直觉得,数据文化,是运维能够建立影响力的重要一步,否则你就是一个支撑的支撑部门!

2、故障发生前,设定技术准则和要求

运维需要和研发建立整体的技术标准和规范要求,这块是腾讯做得非常好的地方,把海量服务提炼成多个关键词海量服务运营之道】,网上可以搜索到。当然这些关键词对于很多企业来说,想理解准确,也会非常的困难。因此从运维的角度来说,我们需要设定一个路线图,最终服务于这个技术目标。比如说之前我提到的运维三部曲】里面讲到了先做标准化(修炼运维内功),然后做公共服务化(修炼架构内功)、最终服务无状态化(修炼业务内功)。

运维一定要把标准化作为核心要务来推进,建立标准化的运维环境,建立标准化的技术栈(和研发确定),建立标准化的高可用方法论,最终这个业务的可用性一定是有保证的。

3、故障发生时,恢复是第一要务

故障发生的时候,“恢复、恢复、恢复”必须是运维人脑子里面要时刻记住的。

在故障的当下,定位故障原因是大忌,这往往让故障时长变得不可控,因为会直接影响MTTR(平均修复时间),影响用户的业务使用。不过有人会有疑问,不知道故障原因怎么知道如何解决?从经验来看,你一定有一些简单粗暴的原则去隔离故障,比如说服务器重启,链路禁用,DNS切换等等。

4、故障发生后,仔细的复盘

每一次故障发生后,运维人需要牵头去复盘故障,刚刚说了我们恢复是第一要务,所以故障的根本原因我们可能还不知道,此时就需要运维、测试和研发一起仔细的去看整个的故障过程,看看到底哪儿有什么问题?基本上也是从刚才说的四个方面来评估。不断的审视我们运维的能力和IT的能力,说“故障是运维最好的老师”的原因也在于此,它能够不断驱使我们走向更高的成熟度。

运维是复盘的首要负责人,复盘是为了找到根因(Root
Cause),根因和故障现象不同,举个例子,故障现象是交换机故障,根因是因为技术架构没有对交换机故障做到容错,根因是运维对这种故障缺乏有效的临时应对机制。

复盘是为了让我们走向更好的运维阶段!

5、故障发生后,复盘措施有讲究

故障复盘后,我们一定会写改进措施,对于这些改进措施,还是有些讲究的,看过一些故障报告,非常的不合要求。我个人的经验如下:

故障的措施必须是可落实,且具体的,要落实到具体的负责人,具体的时间

故障的措施优先是必须技术的,然后是流程,最后是人的

故障的措施可以分为长期措施和临时措施

故障的措施一定要仅仅扣住故障的根因,避免流于形式和表面

故障的措施切忌“亡羊补牢”式的,需要全面细致的分析

故障的措施一定要保证后续的持续跟进

一叶可以障目,但也可以一叶知秋,就看我们是否真的去认真对待。你们真的重视故障了么?你们真的重视运维了么?故障不能带来运维人的春天,从根本上去意识到运维的重要性,那才是运维人真正的春天。


图片 2


最近互联网也是非常有意思,接二连三的发生故障,让我们一起先回顾一下。
2015年5月11号晚上21点左…

携程第四代架构探秘之运维基础架构升级

       
你的大脑装着什么,你就是什么,你看到的世界也就是什么。一个热恋中的人,满脑都是恋人的好,她一个动作,一个表情,一句话都会让你痴迷,不吃不喝的沉迷在其中。

从思考生命意义的羞耻感中解脱出来,希望自己在今后的岁月里,坚持对生命的思索,对自己的真实!

2017-07-26互联网后端架构

图片 3

图片 4

作为国内最大的OTA公司,携程为数以亿计的海内外用户提供优质的旅游产品及服务。2014年底携程技术中心的框架、系统和运维团队共同启动了架构改造项目,历时2年,涉及所有业务线。本文回顾了携程在整个技术架构改造过程中的一些实践和收获。

       
你的大脑装着伟大光明,你就走圣贤伟大光明之路。你的大脑装着得与失,你就走在与别人争名夺利之中,永远痛苦在不能满足上。

真实是全部

一、写在前面

图片 5

成长的经历让我意识到,看起来很快乐、忙碌、满满正能量是时刻应有的状态,而此刻之前,我的生活充满着大小不等的困惑、懊悔,它们消耗着意志,侵袭着青春和生命。这要源于世俗的“威逼利诱”,让我对讨好这个世界坚信不疑、乐此不疲,满心欢喜的以为,真实就是快乐、忙碌和积极,不快乐、不忙碌、不积极就是自己有问题,所以我常常陷入自我怀疑之中,为自己的“不真实”而自责。

随着携程业务量迅速增长、业务变化越来越敏捷,对于应用交付的效率也提出了更高的要求。根据统计,截止2014年底携程总应用数在5000个左右,平均每周约有3000次以上的发布需求。所以作为整体交付环节中极为重要的一环,应用的部署和发布是提高交付效率的关键,然而携程原来的发布系统Croller却成为了阻碍交付效率提升的一大瓶颈。

       
你的大脑装着孩子这不好那不行,你就走在不断纠正孩子的不好上,牺牲了孩子的人生,失去了与孩子幸福成长的时光。

自从开始增加认知的输入输出量之后,即学习和写作,我能更准确的表达自己的困惑,即进入了有所觉知的阶段,随着觉知次数的增长,我开始变得敏锐,却还是没能找到帮我理解和解决困惑的理论和方法,但我依然在思索生命的意义,这个阶段能将潜意识上表达更好的转化为意识,我开始对“真实”有更正确的体会。

【关于携程火车发布】

图片 6

直到这两天看到的电影《无问西东》和新生大学文章《比负能量更可怕的,是正能量狂魔》,仿佛我的困惑得到了部分解答,对生命的思索更深入了一步,对真实的理解更深刻了一些,这是觉知从量变到质变为觉醒的开始。

携程火车发布规定:每天定时安排发布车次,以pool为单位安排车厢,在一个pool中的应用必须在“同一车次”的“同一个车厢”内做发布。

       
有人说,人生就是选择,可选择又是什么?为什么选择那么困难?什么样的选择是正确的?值得我们去深深的思考!我们的大脑不分好坏,只要你有想法,它就会全力证明你是对的。丢东西是正常的事,不正常的是我们经常会把丢东西指向自己不好,为自己不好找一大堆理由,让自己吸取教训,结果是伤了心,浪费了宝贵的成长时间。

我们的生命需要快乐、忙碌、正能量,却不能让生活永远充满快乐、忙碌和正能量,否则就会本末倒置,陷入追求充实的麻木状态中,反而逐渐丧失了真实。

携程实际发布情况:每个应用在发布前需要“买票”,也就是申请和备案的过程,然后被分配到某个“车次”与同在一个pool且需要发布的其他应用形成一个“车厢”,当到达规定发布时间时,该“车厢”内的所有应用以灰度的方式做发布。

图片 7

对物质的追逐,对情感的表露,对情绪的表达,对价值的渴望本就是最真实的需求。我们要做的是不断和内心中的自我对话,挖掘自己内心最真实的渴望,但这份真实就像一盏烛火、一滴朝露,需小心呵护,一阵微风、一刻烈日便能让其消逝。

该模式的弊端:(1)如果提前准备好了发布,在未到达规定发车时间,只能等待,不能发布。(2)如果错过了某个发车时间点,只能等待下一次。(3)如果发布过程中,同一个车厢内有一个应用发布失败,则整个车厢中的应用全部发布失败。

人生问题的解决,永远不在问题之中,问题只能是超越,人生境界的提升。大脑里装着什么,才是最重要的。

具体来说,携程Croller设计的是火车模式发布,主要面临的核心问题包括:

图片 8

由于ASP.NET的应用占大多数,基本都采用的是Windows + IIS
的单机多应用的部署模式,应用和应用之间的隔离性较弱,且由于应用划分的颗粒度比较细,在单机上往往可能同时部署20~30个应用,多的甚至达到60个,导致大量不同应用之间共用应用程序池的情况存在,即多个应用运行在同一个进程下,这种情况下任何一个应用的发布都可能影响到其他的关联应用。

       
幸福脑学习,爱的教育,脑的学习,觉知生命,学习幸福,幸福学习,见证生命的奇迹!

使用硬件负载均衡设备承载应用的访问入口,以域名为单位隔离。单机上的多个应用程序共享同一个访问入口(同一个域名),所以健康检测也只能实现到服务器级别,无法识别应用级的故障。

由于治理系统中的应用信息不统一或不准确,影响监控和排障。

二、从破题到解题

1.破题思路

针对混乱又复杂的情况,如果要想从根本上去解决这些问题,提高交付效率,则必须要从配置管理、部署架构上全面支持以应用为最小颗粒度的管理能力。

我们解决思路包括:

(1)引入Group的概念,设计从App、Server、Pool、Group、Route的完整数据结构模型来描述应用相关的配置部署信息,并由CMS作为权威数据源向外提供数据接口,确保数据的一致性和准确性。

这些定义如下:

App代表一个应用,可以是web、service、job等

Server代表服务器

Pool部署了相同应用程序的一组服务器集合

Group一组相同应用的实例集合

图片 9

(2)引入七层负载均衡(SLB),实现应用的访问入口的隔离。使每个访问入口(集群)的成员(即应用进程实例)可具备独立的管理能力,实现应用级的健康检测。

图片 10

(3)设计实现新一代的发布系统Tars,解决Croller发布系统的痛点,支持应用级的发布。

图片 11

2.具体实现

虽然有了破题思路,但具体实现仍然有很多细节需要考虑,主要包括:

(1)统一配置(CMS)

(2)弹性路由(SLB)

(3)想发就发(TARS)

统一配置(CMS)

正如大型传统企业发展初期缺失ERP系统一样,互联网公司也需要发展到一定规模才能意识到一个完备的配置信息系统的重要性。互联网公司在整个产品研发和运行生命周期中不断产生大量的系统和工具,例如测试平台、发布平台、监控系统和资源管理工具等。业务产品研发效率和业务系统稳定运行依赖这些工具平台的高效协同工作。而如果要实现这种高效协同,关键就是拥有一个统一的配置信息平台。

不成熟的配置管理往往有以下特征:

配置系统之间相对独立和分散,缺少关联关系,且运维、研发工具、测试生产环境都有各自视角的局部配置管理系统;

缺少明确的定义和抽象。例如,不同语言开发的应用对配置的描述方式有很大的差异性;或者对集群、发布节点和访问入口等重要对象的定义很模糊;

配置信息不准,依赖手工维护,没有工具和流程约束,要执行者自己来保证操作和配置数据的一致性;

配置描述不完整,使得系统架构,比如集群、域名映射等关键环节缺乏严格的配置管理。

而携程这种配置管理暴露出很多问题,当监控到服务器资源异常时,例如CPU、内存出现异常,无法快速查找该异常影响的范围,造成不知道应该联系谁进行排障;而对于非.NET的应用无法提供发布工具,或只是提供了一些功能有限的发布模块,但由于不同技术使用的发布工具有着很大的差异性,给使用方和开发维护方都带来了极大的不便;当资源和应用之间的关系不清晰,运维无法实现完善的资源计费等重要管理职能。

要应对这些问题,需要定义统一的配置模型和一致的配置数据,清晰地描述组织、业务、应用、系统架构和资源等要素及互相间的关系。从更高层次设计一套配置管理系统,使得各个维度的配置信息既要专注于自身的领域,又能和其他相关的配置信息维度建立起关联,确保这些工具能以一致的定义来理解配置数据,进行顺畅而有效的协同工作。于是携程的配置管理系统CMS就应运而生了,CMS核心目标包括:

(1)数据准确(即与实际保持一致)且合规

(2)数据关系的查询方便高效

(3)数据变动可追溯

(4)系统高可用

(5)数据模型简洁易懂

  1. CMS系统演变过程

(1)抽象,定义,建立关系,存储数据;

对于应用层面运维所涉及到的对象进行统一地抽象,使得使用不同技术、不同架构的应用体系都能使用一样的模型结构来进行描述。根据携程的应用体系和管理方式,我们抽象出一套最核心的应用配置对象,包括组织、产品线、产品、应用、集群、发布节点、服务器等。经过与那些不同语言不同技术架构所开发的应用间的磨合实验,我们验证了这套抽象的配置对象有其普适性,并可以完备地描述携程范围内各种应用的配置状态。只要按照这套配置对象系统对一个应用完成了描述,那么该应用从发布到上线运行再到下线的全生命周期内,各种相关工具均能通过获取这些配置状态得到足够的信息进行工作。换句话说,通过这套统一的配置信息数据库,不同开发者、不同阶段、不同功能的平台实现了协同工作。

图片 12

(2)将CMS作为一种服务提供出去。

由于建立了描述应用体系的核心配置数据库,这必然会有大量用户和工具成为CMS的消费者。所以我们希望CMS消费者可以通过网络随时随地获取、维护和管理CMS。这要求CMS能提供完备的API和一套简洁直观的管理界面。

(3)通过Portal和工作流引擎完成配置变更,实现业务逻辑的自动化执行。

除了建立统一的应用配置模型,还要建立应用配置的生命周期管理,做到生成配置,修改配置以及销毁配置都合规,都经过授权,都有记录可查。

(4)搭建一个强壮可靠的配置管理体系。

通过更多的子模块助力搭建配置管理体系来提高稳定性和可用性,实现查错追溯和数据巡检纠错等功能。

  1. CMS系统架构

CMS系统在开发过程中遇到和解决了一系列的棘手问题,系统本身的架构也反映了这些方案的设计实施情况。

图片 13

(1)数据治理

CMS系统最基本而关键的需求是提供正确的数据,数据必须能真实反映生产环境的配置现状,并且还要符合公司制定的运维规范,不能出现违规配置。例如,携程不允许同一个应用在一台服务器上运行多于一个实例;不允许在一台服务器上运行多于一个Java应用;每个服务器上只能运行同样类型的应用等。

所以为保证数据的准确性,CMS数据需要持续治理。我们把这部分的治理工作通过一个相对独立的规则引擎来实现。该规则引擎主要完成的工作包括:

允许快速添加新规则,可以使用轻量的脚本语言快速定义各种规则进行数据检查;

针对复杂规则设计了场景和规则两层结构,不同场景可根据需求来配置不同规则;

数据入库时做检查,并进行定期巡检,最大限度查找和消灭错误配置。

图片 14

(2)关系管理和变更追溯

对配置数据关联关系的管理和使用是CMS用户最为看重的功能之一。被CMS管理着的组织、产品、应用、集群、服务器、域名、发布节点等配置间都有着千丝万缕的复杂关系,用户可能从任何一个配置对象开始查找与另一个配置对象的关系,比如从应用查找服务器;从服务器查找组织;从域名查找应用等等。为提供最便利强大的查找功能,我们专门设计了一套查询框架,根据定义好的对象关系快速生成配置对象之间的查询。现在用户可以通过CMS界面和API非常方便地查找到配置数据间的关联关系。

与此相关的还有变更历史的查找,用户除了需要查找一个配置对象自身的变更历史外,还经常需要查找一个配置对象相关的对象变更历史,比如要查找一个应用下面所有服务器的扩容缩容历史;查找一个集群中应用上下线的历史等等。于是我们采用了一种将变更消息沿对象关系链广播出去的方案,把变更和相关配置对象连接起来。

(3)完善的监控和应对访问压力

CMS因汇聚了生产环境核心的配置数据而被大量工具所依赖,因此其必须能够承受大量而密集的查询需求(工作时间内每分钟上万次请求是常态)。

下图是携程接口网关日志分析出的各种工具对CMS接口的调用情况。

图片 15

弹性路由(SLB)

携程部署架构采用的是单机多应用,每台服务器上部署了很多个应用。这些应用不一定存在紧密内联关系,且很可能属于不同团队,这种架构存在着明显的问题。

其实携程面临的这些问题并不是突然暴发的,而是经过十多年的演进和慢慢累积,最终大家不得不正视这些问题。从本质上讲,这些问题的根源是应用间的耦合,最好的解决方案就是单机单应用。因为单机单应用实现了应用间的天然物理隔离(部署在不同的服务器上),从而极大地降低了运维的复杂度,部署、排障、沟通、配置和个性化等都不用再担心会对其他应用有影响。单机单应用是业界普遍推荐和采用的一种部署架构,但对携程而言这却是个系统性的大工程,需要从底层基础设施到配套系统工具、从流程规范到开发人员的思维转变等方面投入大量的人力和时间。所以我们首先就要考虑如何在单机多应用的情况下,实现应用解耦,也就是做到应用粒度的运维。

相比应用粒度的运维目标,携程当时实际情况则是服务器的运维粒度,并且绝大多数的运维操作还是通过硬件LB来完成。虽然硬件LB的好处显而易见,例如,高吞吐量、高性能和优秀的稳定性等。但其缺点也同样明显:

(1)水平扩展成本高昂;

(2)基于规则无法建模,规则过多时就会陷入运维泥潭;

(3)无法进行高频次的变更,因为集中式管理模式中,配置数据一多,API性能就会急剧下降;

(4)只能由少数的专职运维人员做操作。

所以,硬件LB除了无法做到应用粒度外,低效也成为一个很重大缺陷。为了解决在路由运维方面的粒度和效率问题,携程决定打造自己的软负载(SLB)系统,替代掉硬件LB的七层路由职责。经过讨论,SLB确定了自己的职能目标,即可以高并发、实时、灵活、细粒度调整七层路由规则。从另一方面想,SLB还需要实现由面向机器运维到面向应用运维的转变,以及由硬件支撑到软件支撑的进化。

在携程SLB的开发过程中,最重要的几点是:

(1)面向应用建模;

(2)多次更新一次生效

(3)多并发操作的挑战;

(4)多角色运维冲突的问题;

(5)监控和告警。

  1. 面向应用建模

携程经过评估最终选择了Nginx来构建软负载系统。开发前我们参考了业界内其他公司的实现方式,基本包含几个特点:

(1)开发了一个Nginx配置文件的批量管理工具;

(2)需要专业的运维人员来操作;

(3)日常操作频率较低;

(4)和现有系统接合较松散。

结合携程的现状,我们在建模时还需要考虑:

(1)和现有系统无缝接合,融入现有系统的生态体系;

(2)支持高频率的并发操作;

但如何和现有建模体系融合起来?在开发人员眼中最重要最核心的常见模型就是一个一个的应用。所以SLB要做的是如何和应用模型融合起来,换句话说,所有对SLB的操作都要被抽象为对一个应用的操作。Nginx是基于文本配置文件,其内建了一个自己的模型,一次运维操作可以导致多个Nginx模型的变更。所以我们需要创建一个模型,这个模型可以和应用模型一一对应,又能被翻译成Nginx的内建模型,而这就是Group:

一个Group是一个应用在SLB的投影;

SLB上所有的操作都抽象成对Group的操作;

不同Group的操作互不影响。

图片 16

这样只要解决一个Group的问题,就相当于解决了1000个、甚至更多个Group的问题。

  1. 多次更新一次生效

建模成功地隐藏了Nginx的内存模型,并将操作转换成了对Group的操作。虽然隔离不同Group间的操作,但在SLB上对单一Group的操作仍然是一个有风险的行为(对某一具体应用而言)。为了降低这种风险性,可以引入3种机制,包括多版本系统、日志追踪和多次更新一次生效。

Group的每次变更都会产生一个新的版本;Group的所有变更都会留下日志;对Group的变更操作并不会直接对生产生效,可以在多次变更后,有一次明确的激活操作后,从而在生产环境正式生效。

图片 17

  1. 多并发操作

引入group后实现了应用的独立运维,但如果有上千个Group要同时进行扩容操作,那么如何做到每个Group的操作都在5秒内完成?因为Nginx是基于一个文本配置文件的,那么这样的要求就会转换为对配置文件的上千次操作,然后再对SLB重新加载上千次配置文件。假设一次操作花费1s,那么最后一个操作可能要等1000s,这种实现方式显然对于那些排在后面的Group更新者是无法接受的,而且SLB在这种高频度更新下,自身也无法工作。所以简单地把一次Group更新转换成一次Nginx的配置更新是肯定行不通的。

携程真实情况是Nginx变更日操作达到8万次,整个软负载API日请求数达到300万次。

为了实现Group更新的互不影响,并确保所有Group更新保持在一个稳定返回时间内,SLB确定了核心业务流程:

将一段时间内所有的Group更新操作(比如2秒内)缓存在一个任务队列中;

对任务队列中的所有操作进行合并,最终只对Nginx的配置文件做一次更新。

图片 18

这个流程的核心逻辑就是多次操作一次更新,最大程度减少对Nginx配置文件的操作,但外部看来Group更新操作是独立且保持在稳定返回时间内的。

  1. 多角色运维的冲突

一个Group可能会有多种角色进行更新,比如应用Owner、专业运维人员和发布系统人员等。这就引出了一个新的问题,即当一个角色对一个Group的服务器进行拉出操作后,另一个角色可不可以对这些服务器做拉入操作?比如,发布系统人员在发布完成后,准备做拉入,却发现运维人员对这台服务器进行了拉出操作。这时发系统应该如何决策?这不仅造成决策的困扰,也会使不同的角色产生联系,甚至相互耦合在一起。

为了解决这个问题,我们决定采用多状态的机制:

为每一种角色分配一个服务器状态;

一个角色对这个状态进行了失效操作,最终也只能由这个角色进行恢复操作;

SLB在所有角色都认为这台服务器有效时,才会认为这台服务器可工作。

图片 19

  1. 健康检测带来的瓶颈

SLB另一个核心功能是健康检测,即需要以一定频率对应用服务器进行心跳检测,连续失败多次后对服务器进行拉出操作,成功后再进行拉入恢复。大多数公司采用了节点独立检测造成了带宽浪费和服务器压力,而携程采用了节点共享检测,具体机制是一个独立的应用负责检测,然后把检测结果在SLB节点间传播共享。

图片 20

【携程的健康检测效果】

携程独立健康检测的运行效果良好,目前SLB系统已经负责了携程超过5万个结点的健康检测任务。而下图是由节点独立检测变为节点共享检测时的SLB单一服务器网络连接释放状况:

图片 21

  1. 监控数据采集和告警

SLB
负责了几乎所有的基于域名的http调度请求,所以也成为了进行请求流量统计和请求质量统计的绝佳场所。包括在有问题时进行报警;根据不同维度统计请求量;响应码分布和响应时间分布等,携程使用了分析access
log的方式来获得监控数据:

SLB服务器流式读取本机实时产生的access log;

分析聚合log数据,产生不同的统计数据。最终使用了语法树分析实现了高效分析,一秒可以分析14万条日志;

定期(1分钟)将统计数据吐到监控系统CAT等。

图片 22

以此可以产生多维度的监控统计数据,如下图:

图片 23

基于上述数据,可以查看整个携程或单个应用性能表现,进行相应的优化。在慢请求和非200请求的数量异常时,执行报警操作,确保及时恢复和挽回损失。

图片 24

想发就发(TARS)

解决了配置和路由问题后,发布系统前置障碍已基本扫除,而从OPS角度来看,发布系统还有几个重要目标:

灰度发布

简单易用

发布迅捷

1、灰度发布

通常发布有三种常规方法,蓝绿发布,滚动发布,金丝雀发布。对这三种发布类别做比较,可以发现:

蓝绿发布:需要额外的服务器集群支持,且数量可观,同时由于携程单机多应用的部署现状,就会造成发布一个应用需要替换整台服务器的情况,实现难度巨大且成本不经济。

滚动发布:虽然可以节省资源,但对应用的兼容性有较高要求,因为发布过程中同时会有两个版本对外提供服务。但这类问题相对容易解决,实际中往往会通过功能开关,dark
launch等方式来解决。

金丝雀发布,比较符合携程对灰度发布的预期,但可能需要精细的流控和数据的支持,同样有版本兼容的需求。

【发布相关说明】

蓝绿发布:优先将新版本发布到待发布的机器上,并进行验证,此时新版本服务器并不接入外部流量。发布和验证过程中老版本所在的服务器仍照常服务,验证通过后,经过流控处理把流量引导到新服务器,待全部流量切换完成,老版本服务器下线。

图片 25

滚动发布:从老版本服务器中挑选一批,停止老版本的服务,并更新为新版本,进行验证,通过后再分批增量更新剩余服务器。

金丝雀发布:往往从集群中挑选特定服务器或一小批符合要求的特征用户,对其进行版本更新及验证,随后逐步更新剩余服务器。

结合携程的实际情况,最终挑选的方式是滚动发布和金丝雀发布的结合体,首先允许对一个较大的应用集群,特别是跨IDC的应用集群按自定义的规则进行切分,形成较固定的发布单元。每个应用的每个发布单元称为“group”,这个group与之前提到的SLB的group是一一对应的。

图片 26

每个发布单元,即group在发布过程时,还可以再分批进行,完成滚动发布。而每个group中包含一台或多台堡垒机,必须先完成堡垒机的发布和验证,才能继续其他机器的发布,从而实现金丝雀发布。除堡垒机的发布外,其他机器可按照用户能接受的最大同时拉出比例来分批,分批间允许设置具体的验证等待时间。

每台机器在发布过程中都要经历拉出、下载、安装、点火和拉入这5个步骤,发布流程为:

图片 27

基于以上设计,携程新一代发布系统开发完成,命名为Tars 。

【Tars源代码】Tars已做了开源,开源版本地址:

2、简单易用

发布配置必须简单易懂,绝大部分的应用发布都是固定模式,不需要个性化配置,所以Tars只提供了几个核心配置项,包括(1)允许同时拉出的最大比例;(2)批次间的等待时间;(3)启动超时时间;(4)是否忽略点火。

除此以外,用户最关心的是发布过程中可操作按钮的易用性,Tars在这方面做了充分考虑,通过状态机的控制,保证用户在操作界面上同时最多只看到两个操作按钮,绝大部分情况下用户只需在“继续”或“终止”这样的0或1的选择中做出决策。

而图形化界面的展示,Tars也确保用户可以更直观地观察到发布的进展,以及出现的问题。

有了简单操作,危机时刻就会得到放大体现,比如,因生产故障做回滚时,能快速中断当前发布,并从界面中轻松地选到所需回滚的版本,然后一键无配置地触发完成回滚。

图片 28

图片 29

3、发布迅捷

天下武功无坚不摧,唯快不破,而发布也一样。发布速度快了,迭代速度研发效率也就提升了;回滚速度快了,生产故障造成的影响也就减轻了;扩容速度快了,弹性计算就能实施了,这样运维效率被大幅度提升。从上面对发布过程的描述中,不能发现在携程通常影响发布速度的步骤是下载和验证。

为了提高下载速度,携程在各个机房搭建了发布包专用的存储系统,实现了类似CDN的功能,编译和打包系统在任何一个写入点写入发布包,都会尽快同步到各个IDC及各个独立存储中,这样真正发布时,服务器只需从本IDC或本网段做下载。而回滚方面,Tars则是在服务器本地保留了n个版本(n根据服务器磁盘容量计算获得),做回滚时可快速地进行目录切换,进而省略了代码下载过程。

对于验证,携程在框架层面统一提供了验证入口和常规验证方法(携程称为“点火”),收口了所有应用的验证规范和标准,容错性得到提升。

Tars在系统设计方面充分考虑了速度需求。每个发布单元采用quick and
dirty的方式,不管成功或失败,优先尝试把版本发布完成,后续在解决个别发布失败的问题。根据同时拉出服务的最高比率(由用户设置)进行失败率控制,一旦达到比率,立即中断当前发布,从而对quick
and
dirty方式做保护(携程称为“刹车”)。发布单元中只要有任何一台服务器发布失败,都会被认为是发布局部失败,允许用户重试发布。发布过程中如发现服务器当前运行版本与发布目标版本一致,且验证通过,则直接skip。批次间可设置观察等待时长,从第3个批次起,允许设置0或较少的等待时长,以提高后几批次的速度(携程称为“尾单加速”)。

三、结果和未来

通过CMS+SLB+TARS几个系统的联动,并经历了长达一年半的项目推广阶段,终于实现了1+1+1>>3的效果。新发布系统对于研发效率和研发人员体验的提升都非常显著。

这可以通过一些数字来证明,与2年前相比,每周的发布迭代次数成长了4倍,但单次发布的平均时长从13分钟却降低到了3分钟。同时因为发布/回退效率的提升,当需要对线上代码做紧急修复时,或者将其回退到已发布的代码版本时,都会更快捷地完成,所以使得发布类故障的处理效率也得到了提升。对2015年至2017年的发布相关故障的统计后,发现该占比下降了一半以上。

因为CMS+SLB+TARS基于良好的配置数据模型设计,及其应用级的运维支持能力,为后续的技术架构改造带来了便捷和优势。这主要体现在:

高效的容量管理,实现了对应用容量的自动化监测,当发现容量不足时,无需研发介入,全自动地进行应用服务器扩容、发布、上线和投产等。

在应用容灾方面,基于准确的配置数据,可以很容易的将单数据中心的业务应用“克隆”到另外的数据中心来进行部署。

在应用技术栈的迁移(例如.net应用改造为java应用),用户也能自助地创建新的java应用,并通过SLB灵活实现灰度流量切换,进而自助、高效、稳定、安全地完成整个应用迁移。

发表评论

电子邮件地址不会被公开。 必填项已用*标注