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

PAGE 1 PAGE 1 携程第四代架构探秘之运维基础架构升级  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）   2014年底携程技术中心的框架、系统和运维团队共同启动了架构改造项目，历时2年，涉及全部业务线。本文回顾了携程在整个技术架构改造过程中的一些实践和收获。  作为国内最大的OTA公司，携程为数以亿计的海内外用户供应优质的旅游产品及服务。2014年底携程技术中心的框架、系统和运维团队共同启动了架构改造项目，历时2年，涉及全部业务线。本文回顾了携程在整个技术架构改造过程中的一些实践和收获。  一、写在前面  随着携程业务量快速增长、业务变化越来越机敏，对于应用交付的效率也提出了更高的要求。依据统计，截止2014年底携程总应用数在5000个左右，平均每周约有3000次以上的发布需求。所以作为整体交付环节中极为重要的一环，应用的部署和发布是提高交付效率的关键，然而携程原来的发布系统Croller却成为了阻碍交付效率提升