e-works数字化企业网  »  文章频道  »  基础信息化  »  运维管理

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

2017/7/17    来源:极客头条    作者:佚名      
关键字:携程  运维  技术架构改造  
2014年底携程技术中心的框架、系统和运维团队共同启动了架构改造项目,历时2年,涉及所有业务线。本文回顾了携程在整个技术架构改造过程中的一些实践和收获。
    作为国内最大的OTA公司,携程为数以亿计的海内外用户提供优质的旅游产品及服务。2014年底携程技术中心的框架、系统和运维团队共同启动了架构改造项目,历时2年,涉及所有业务线。本文回顾了携程在整个技术架构改造过程中的一些实践和收获。
 
    一、写在前面
 
    随着携程业务量迅速增长、业务变化越来越敏捷,对于应用交付的效率也提出了更高的要求。根据统计,截止2014年底携程总应用数在5000个左右,平均每周约有3000次以上的发布需求。所以作为整体交付环节中极为重要的一环,应用的部署和发布是提高交付效率的关键,然而携程原来的发布系统Croller却成为了阻碍交付效率提升的一大瓶颈。
 
    【关于携程火车发布】 
 
    *携程火车发布规定:每天定时安排发布车次,以pool为单位安排车厢,在一个pool中的应用必须在“同一车次”的“同一个车厢”内做发布。 
 
    *携程实际发布情况:每个应用在发布前需要“买票”,也就是申请和备案的过程,然后被分配到某个“车次”与同在一个pool且需要发布的其他应用形成一个“车厢”,当到达规定发布时间时,该“车厢”内的所有应用以灰度的方式做发布。 
 
    *该模式的弊端:(1)如果提前准备好了发布,在未到达规定发车时间,只能等待,不能发布。(2)如果错过了某个发车时间点,只能等待下一次。(3)如果发布过程中,同一个车厢内有一个应用发布失败,则整个车厢中的应用全部发布失败。
 
    具体来说,携程Croller设计的是火车模式发布,主要面临的核心问题包括:
 
    (1)由于ASP.NET的应用占大多数,基本都采用的是Windows + IIS 的单机多应用的部署模式,应用和应用之间的隔离性较弱,且由于应用划分的颗粒度比较细,在单机上往往可能同时部署20~30个应用,多的甚至达到60个,导致大量不同应用之间共用应用程序池的情况存在,即多个应用运行在同一个进程下,这种情况下任何一个应用的发布都可能影响到其他的关联应用。
 
    (2)使用硬件负载均衡设备承载应用的访问入口,以域名为单位隔离。单机上的多个应用程序共享同一个访问入口(同一个域名),所以健康检测也只能实现到服务器级别,无法识别应用级的故障。
 
    (3)由于治理系统中的应用信息不统一或不准确,影响监控和排障。
 
    二、从破题到解题
 
    1.破题思路
 
    针对混乱又复杂的情况,如果要想从根本上去解决这些问题,提高交付效率,则必须要从配置管理、部署架构上全面支持以应用为最小颗粒度的管理能力。
 
    我们解决思路包括:
 
    (1)引入Group的概念,设计从App、Server、Pool、Group、Route的完整数据结构模型来描述应用相关的配置部署信息,并由CMS作为权威数据源向外提供数据接口,确保数据的一致性和准确性。
 
    这些定义如下: 
 
携程第四代架构探秘之运维基础架构升级
 
    (2)引入七层负载均衡(SLB),实现应用的访问入口的隔离。使每个访问入口(集群)的成员(即应用进程实例)可具备独立的管理能力,实现应用级的健康检测。
 
携程第四代架构探秘之运维基础架构升级
 
    (3)设计实现新一代的发布系统Tars,解决Croller发布系统的痛点,支持应用级的发布。
 
携程第四代架构探秘之运维基础架构升级
 
    2.具体实现
 
    虽然有了破题思路,但具体实现仍然有很多细节需要考虑,主要包括: 
 
    (1)统一配置(CMS) 
 
    (2)弹性路由(SLB) 
 
    (3)想发就发(TARS)
 
    统一配置(CMS)

责任编辑:李欢
本文为授权转载文章,任何人未经原授权方同意,不得复制、转载、摘编等任何方式进行使用,e-works不承担由此而产生的任何法律责任! 如有异议请及时告之,以便进行及时处理。联系方式:editor@e-works.net.cn tel:027-87592219/20/21。
e-works
官方微信
掌上
信息化
编辑推荐
新闻推荐
博客推荐
视频推荐