干货 | 携程第四代架构探秘之运维基础架构升级（上）

作者简介

本文由携程技术中心框架研发部吴其敏、王兴朝，技术保障中心高峻、王潇俊、陈劼联合撰写。

作为国内最大的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）

正如大型传统企业发展初期缺失ERP系统一样，互联网公司也需要发展到一定规模才能意识到一个完备的配置信息系统的重要性。

互联网公司在整个产品研发和运行生命周期中不断产生大量的系统和工具，例如测试平台、发布平台、监控系统和资源管理工具等。业务产品研发效率和业务系统稳定运行依赖这些工具平台的高效协同工作。而如果要实现这种高效协同，关键就是拥有一个统一的配置信息平台。

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

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

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

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

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

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

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

于是携程的配置管理系统CMS就应运而生了，CMS核心目标包括：

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

（2）数据关系的查询方便高效

（3）数据变动可追溯

（4）系统高可用

（5）数据模型简洁易懂

1. CMS系统演变过程

（1）抽象，定义，建立关系，存储数据；

对于应用层面运维所涉及到的对象进行统一地抽象，使得使用不同技术、不同架构的应用体系都能使用一样的模型结构来进行描述。

根据携程的应用体系和管理方式，我们抽象出一套最核心的应用配置对象，包括组织、产品线、产品、应用、集群、发布节点、服务器等。经过与那些不同语言不同技术架构所开发的应用间的磨合实验，我们验证了这套抽象的配置对象有其普适性，并可以完备地描述携程范围内各种应用的配置状态。

只要按照这套配置对象系统对一个应用完成了描述，那么该应用从发布到上线运行再到下线的全生命周期内，各种相关工具均能通过获取这些配置状态得到足够的信息进行工作。换句话说，通过这套统一的配置信息数据库，不同开发者、不同阶段、不同功能的平台实现了协同工作。

（2）将CMS作为一种服务提供出去。

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

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

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

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

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

2. CMS系统架构

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

（1）数据治理

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

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

• 允许快速添加新规则，可以使用轻量的脚本语言快速定义各种规则进行数据检查；
• 针对复杂规则设计了场景和规则两层结构，不同场景可根据需求来配置不同规则；
• 数据入库时做检查，并进行定期巡检，最大限度查找和消灭错误配置。

（2）关系管理和变更追溯

对配置数据关联关系的管理和使用是CMS用户最为看重的功能之一。被CMS管理着的组织、产品、应用、集群、服务器、域名、发布节点等配置间都有着千丝万缕的复杂关系，用户可能从任何一个配置对象开始查找与另一个配置对象的关系，比如从应用查找服务器；从服务器查找组织；从域名查找应用等等。

为提供最便利强大的查找功能，我们专门设计了一套查询框架，根据定义好的对象关系快速生成配置对象之间的查询。现在用户可以通过CMS界面和API非常方便地查找到配置数据间的关联关系。

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

（3）完善的监控和应对访问压力

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

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

（未完待续）