携程的运维架构分析
本帖最后由 monicazhang 于 2017-8-22 15:40 编辑作为国内最大的 OTA 公司，携程为数以亿计的海内外用户提供优质的旅游产品及服务。2014 年底携程技术中心的框架、系统和运维团队共同启动了架构改造项目，历时 2 年，涉及所有业务线。本文回顾了携程在整个技术架构改造过程中的一些实践和收获。写在前面随着携程业务量迅速增长、业务变化越来越敏捷，对于应用交付的效率也提出了更高的要求。根据统计，截止 2014 年底携程总应用数在 5000 个左右，平均每周约有 3000 次以上的发布需求。所以作为整体交付环节中极为重要的一环，应用的部署和发布是提高交付效率的关键，然而携程原来的发布系统 Croller 却成为了阻碍交付效率提升的一大瓶颈。关于携程火车发布
[*]携程火车发布规定：每天定时安排发布车次，以 pool 为单位安排车厢，在一个 pool 中的应用必须在“同一车次”的“同一个车厢”内做发布。
[*]携程实际发布情况：每个应用在发布前需要“买票”，也就是申请和备案的过程，然后被分配到某个“车次”与同在一个 pool 且需要发布的其他应用形成一个“车厢”，当到达规定发布时间时，该“车厢”内的所有应用以灰度的方式做发布。
[*]该模式的弊端：（1）如果提前准备好了发布，在未到达规定发车时间，只能等待，不能发布。（2）如果错过了某个发车时间点，只能等待下一次。（3）如果发布过程中，同一个车厢内有一个应用发布失败，则整个车厢中的应用全部发布失败。
具体来说，携程 Croller 设计的是火车模式发布，主要面临的核心问题包括：
[*]由于 ASP.NET 的应用占大多数，基本都采用的是 Windows + IIS 的单机多应用的部署模式，应用和应用之间的隔离性较弱，且由于应用划分的颗粒度比较细，在单机上往往可能同时部署 20~30 个应用，多的甚至达到 60 个，导致大量不同应用之间共用应用程序池的情况存在，即多个应用运行在同一个进程下，这种情况下任何一个应用的发布都可能影响到其他的关联应用。
[*]使用硬件负载均衡设备承载应用的访问入口，以域名为单位隔离。单机上的多个应用程序共享同一个访问入口（同一个域名），所以健康检测也只能实现到服务器级别，无法识别应用级的故障。
[*]由于治理系统中的应用信息不统一或不准确，影响监控和排障。
破题思路针对混乱又复杂的情况，如果要想从根本上去解决这些问题，提高交付效率，则必须要从配置管理、部署架构上全面支持以应用为最小颗粒度的管理能力。具体有三种解决方案。其一，引入 Group 的概念，设计从 App、Server、Pool、Group、Route 的完整数据结构模型来描述应用相关的配置部署信息，并由 CMS 作为权威数据源向外提供数据接口，确保数据的一致性和准确性。其中 App 代表代表一个应用，可以是 web、service、job 等。Server 代表服务器。Pool 代表部署了相同应用程序的一组服务器集合。Group 代表一组相同应用的实例集合。其二，引入七层负载均衡（SLB），实现应用的访问入口的隔离。使每个访问入口（集群）的成员（即应用进程实例）可具备独立的管理能力，实现应用级的健康检测。其三，设计实现新一代的发布系统 Tars，解决 Croller 发布系统的痛点，支持应用级的发布。落地解题虽然有了破题思路，但具体实现仍然有很多细节需要考虑，主要包括统一配置（CMS）、弹性路由（SLB）、想发就发（TARS）。统一配置（CMS）正如大型传统企业发展初期缺失 ERP 系统一样，互联网公司也需要发展到一定规模才能意识到一个完备的配置信息系统的重要性。互联网公司在整个产品研发和运行生命周期中不断产生大量的系统和工具，例如测试平台、发布平台、监控系统和资源管理工具等。业务产品研发效率和业务系统稳定运行依赖这些工具平台的高效协同工作。而如果要实现这种高效协同，关键就是拥有一个统一的配置信息平台。不成熟的配置管理往往有以下特征：
[*]配置系统之间相对独立和分散，缺少关联关系，且运维、研发工具、测试生产环境都有各自视角的局部配置管理系统；
[*]缺少明确的定义和抽象。例如，不同语言开发的应用对配置的描述方式有很大的差异性；或者对集群、发布节点和访问入口等重要对象的定义很模糊；
[*]配置信息不准，依赖手工维护，没有工具和流程约束，要执行者自己来保证操作和配置数据的一致性；
[*]配置描述不完整，使得系统架构，比如集群、域名映射等关键环节缺乏严格的配置管理。
而携程这种配置管理 出很多问题，当监控到服务器资源异常时，例如 CPU、内存出现异常，无法快速查找该异常影响的范围，造成不知道应该联系谁进行排障；而对于非.NET 的应用无法提供发布工具，或只是提供了一些功能有限的发布模块，但由于不同技术使用的发布工具有着很大的差异性，给使用方和开发维护方都带来了极大的不便；当资源和应用之间的关系不清晰，运维无法实现完善的资源计费等重要管理职能。要应对这些问题，需要定义统一的配置模型和一致的配置数据，清晰地描述组织、业务、应用、系统架构和资源等要素及互相间的关系。从更高层次设计一套配置管理系统，使得各个维度的配置信息既要专注于自身的领域，又能和其他相关的配置信息维度建立起关联，确保这些工具能以一致的定义来理解配置数据，进行顺畅而有效的协同工作。于是携程的配置管理系统 CMS 就应运而生了，CMS 核心目标包括：
[*]数据准确（即与实际保持一致）且合规
[*]数据关系的查询方便高效
[*]数据变动可追溯
[*]系统高可用
[*]数据模型简洁易懂
CMS 系统演变过程1. 抽象、定义、建立关系、存储数据对于应用层面运维所涉及到的对象进行统一地抽象，使得使用不同技术、不同架构的应用体系都能使用一样的模型结构来进行描述。根据携程的应用体系和管理方式，我们抽象出一套最核心的应用配置对象，包括组织、产品线、产品、应用、集群、发布节点、服务器等。经过与那些不同语言不同技术架构所开发的应用间的磨合实验，我们验证了这套抽象的配置对象有其普适性，并可以完备地描述携程范围内各种应用的配置状态。只要按照这套配置对象系统对一个应用完成了描述，那么该应用从发布到上线运行再到下线的全生命周期内，各种相关工具均能通过获取这些配置状态得到足够的信息进行工作。换句话说，通过这套统一的配置信息数据库，不同开发者、不同阶段、不同功能的平台实现了协同工作。2. 将 CMS 作为一种服务提供出去由于建立了描述应用体系的核心配置数据库，这必然会有大量用户和工具成为 CMS 的消费者。所以我们希望 CMS 消费者可以通过网络随时随地获取、维护和管理 CMS。这要求 CMS 能提供完备的 API 和一套简洁直观的管理界面。3. 通过 Portal 和工作流引擎完成配置变更，实现业务逻辑的自动化执行除了建立统一的应用配置模型，还要建立应用配置的生命周期管理，做到生成配置，修改配置以及销毁配置都合规，都经过授权，都有记录可查。4. 搭建一个强壮可靠的配置管理体系通过更多的子模块助力搭建配置管理体系来提高稳定性和可用性，实现查错追溯和数据巡检纠错等功能。 CMS 系统架构CMS 系统在开发过程中遇到和解决了一系列的棘手问题，系统本身的架构也反映了这些方案的设计实施情况。1. 数据治理CMS 系统最基本而关键的需求是提供正确的数据，数据必须能真实反映生产环境的配置现状，并且还要符合公司制定的运维规范，不能出现违规配置。例如，携程不允许同一个应用在一台服务器上运行多于一个实例；不允许在一台服务器上运行多于一个 Java 应用；每个服务器上只能运行同样类型的应用等。所以为保证数据的准确性，CMS 数据需要持续治理。我们把这部分的治理工作通过一个相对独立的规则引擎来实现。该规则引擎主要完成的工作包括：
[*]允许快速添加新规则，可以使用轻量的脚本语言快速定义各种规则进行数据检查；
[*]针对复杂规则设计了场景和规则两层结构，不同场景可根据需求来配置不同规则；
[*]数据入库时做检查，并进行定期巡检，最大限度查找和消灭错误配置。
2. 关系管理和变更追溯对配置数据关联关系的管理和使用是 CMS 用户最为看重的功能之一。被 CMS 管理着的组织、产品、应用、集群、服务器、域名、发布节点等配置间都有着千丝万缕的复杂关系，用户可能从任何一个配置对象开始查找与另一个配置对象的关系，比如从应用查找服务器；从服务器查找组织；从域名查找应用等等。为提供最便利强大的查找功能，我们专门设计了一套查询框架，根据定义好的对象关系快速生成配置对象之间的查询。现在用户可以通过 CMS 界面和 API 非常方便地查找到配置数据间的关联关系。与此相关的还有变更历史的查找，用户除了需要查找一个配置对象自身的变更历史外，还经常需要查找一个配置对象相关的对象变更历史，比如要查找一个应用下面所有服务器的扩容缩容历史；查找一个集群中应用上下线的历史等等。于是我们采用了一种将变更消息沿对象关系链广播出去的方案，把变更和相关配置对象连接起来。3. 完善的监控和应对访问压力CMS 因汇聚了生产环境核心的配置数据而被大量工具所依赖，因此其必须能够承受大量而密集的查询需求（工作时间内每分钟上万次请求是常态）。下图是携程接口网关日志分析出的各种工具对 CMS 接口的调用情况。弹性路由（SLB）携程部署架构采用的是单机多应用，每台服务器上部署了很多个应用。这些应用不一定存在紧密内联关系，且很可能属于不同团队，这种架构存在着明显的问题。其实携程面临的这些问题并不是突然暴发的，而是经过十多年的演进和慢慢累积，最终大家不得不正视这些问题。从本质上讲，这些问题的根源是应用间的耦合，最好的解决方案就是单机单应用。因为单机单应用实现了应用间的天然物理隔离（部署在不同的服务器上），从而极大地降低了运维的复杂度，部署、排障、沟通、配置和个性化等都不用再担心会对其他应用有影响。单机单应用是业界普遍推荐和采用的一种部署架构，但对携程而言这却是个系统性的大工程，需要从底层基础设施到配套系统工具、从流程规范到开发人员的思维转变等方面投入大量的人力和时间。所以我们首先就要考虑如何在单机多应用的情况下，实现应用解耦，也就是做到应用粒度的运维。相比应用粒度的运维目标，携程当时实际情况则是服务器的运维粒度，并且绝大多数的运维操作还是通过硬件 LB 来完成。虽然硬件 LB 的好处显而易见，例如，高吞吐量、高性能和优秀的稳定性等。但其缺点也同样明显：
[*]水平扩展成本高昂；
[*]基于规则无法建模，规则过多时就会陷入运维泥潭；
[*]无法进行高频次的变更，因为集中式管理模式中，配置数据一多，API 性能就会急剧下降；
[*]只能由少数的专职运维人员做操作。
所以，硬件 LB 除了无法做到应用粒度外，低效也成为一个很重大缺陷。为了解决在路由运维方面的粒度和效率问题，携程决定打造自己的软负载（SLB）系统，替代掉硬件 LB 的七层路由职责。经过讨论，SLB 确定了自己的职能目标，即可以高并发、实时、灵活、细粒度调整七层路由规则。从另一方面想，SLB 还需要实现由面向机器运维到面向应用运维的转变，以及由硬件支撑到软件支撑的进化。在携程 SLB 的开发过程中，最重要的几点是：
[*]面向应用建模；
[*]多次更新一次生效
[*]多并发操作的挑战；
[*]多角色运维冲突的问题；
[*]监控和告警。
面向应用建模携程经过评估最终选择了 Nginx 来构建软负载系统。开发前我们参考了业界内其他公司的实现方式，基本包含几个特点：
[*]开发了一个 Nginx 配置文件的批量管理工具；
[*]需要专业的运维人员来操作；
[*]日常操作频率较低；
[*]和现有系统接合较松散。
结合携程的现状，我们在建模时还需要考虑：
[*]和现有系统无缝接合，融入现有系统的生态体系；
[*]支持高频率的并发操作；
但如何和现有建模体系融合起来？在开发人员眼中最重要最核心的常见模型就是一个一个的应用。所以 SLB 要做的是如何和应用模型融合起来，换句话说，所有对 SLB 的操作都要被抽象为对一个应用的操作。Nginx 是基于文本配置文件，其内建了一个自己的模型，一次运维操作可以导致多个 Nginx 模型的变更。所以我们需要创建一个模型，这个模型可以和应用模型一一对应，又能被翻译成 Nginx 的内建模型，而这就是 Group：
[*]一个 Group 是一个应用在 SLB 的投影；
[*]SLB 上所有的操作都抽象成对 Group 的操作；
[*]不同 Group 的操作互不影响。
这样只要解决一个 Group 的问题，就相当于解决了 1000 个、甚至更多个 Group 的问题。 多次更新一次生效建模成功地隐藏了 Nginx 的内存模型，并将操作转换成了对 Group 的操作。虽然隔离不同 Group 间的操作，但在 SLB 上对单一 Group 的操作仍然是一个有风险的行为（对某一具体应用而言）。为了降低这种风险性，可以引入 3 种机制，包括多版本系统、日志追踪和多次更新一次生效。Group 的每次变更都会产生一个新的版本；Group 的所有变更都会留下日志；对 Group 的变更操作并不会直接对生产生效，可以在多次变更后，有一次明确的激活操作后，从而在生产环境正式生效。 多并发操作引入 group 后实现了应用的独立运维，但如果有上千个 Group 要同时进行扩容操作，那么如何做到每个 Group 的操作都在 5 秒内完成？因为 Nginx 是基于一个文本配置文件的，那么这样的要求就会转换为对配置文件的上千次操作，然后再对 SLB 重新加载上千次配置文件。假设一次操作花费 1s，那么最后一个操作可能要等 1000s，这种实现方式显然对于那些排在后面的 Group 更新者是无法接受的，而且 SLB 在这种高频度更新下，自身也无法工作。所以简单地把一次 Group 更新转换成一次 Nginx 的配置更新是肯定行不通的。携程真实情况是 Nginx 变更日操作达到 8 万次，整个软负载 API 日请求数达到 300 万次。为了实现 Group 更新的互不影响，并确保所有 Group 更新保持在一个稳定返回时间内，SLB 确定了核心业务流程：
[*]将一段时间内所有的 Group 更新操作（比如 2 秒内）缓存在一个任务队列中；
[*]对任务队列中的所有操作进行合并，最终只对 Nginx 的配置文件做一次更新。
这个流程的核心逻辑就是多次操作一次更新，最大程度减少对 Nginx 配置文件的操作，但外部看来 Group 更新操作是独立且保持在稳定返回时间内的。 多角色运维的冲突一个 Group 可能会有多种角色进行更新，比如应用 Owner、专业运维人员和发布系统人员等。这就引出了一个新的问题，即当一个角色对一个 Group 的服务器进行拉出操作后，另一个角色可不可以对这些服务器做拉入操作？比如，发布系统人员在发布完成后，准备做拉入，却发现运维人员对这台服务器进行了拉出操作。这时发系统应该如何决策？这不仅造成决策的困扰，也会使不同的角色产生联系，甚至相互耦合在一起。为了解决这个问题，我们决定采用多状态的机制：
[*]为每一种角色分配一个服务器状态；
[*]一个角色对这个状态进行了失效操作，最终也只能由这个角色进行恢复操作；
[*]SLB 在所有角色都认为这台服务器有效时，才会认为这台服务器可工作；
健康检测带来的瓶颈SLB 另一个核心功能是健康检测，即需要以一定频率对应用服务器进行心跳检测，连续失败多次后对服务器进行拉出操作，成功后再进行拉入恢复。大多数公司采用了节点独立检测造成了带宽浪费和服务器压力，而携程采用了节点共享检测，具体机制是一个独立的应用负责检测，然后把检测结果在 SLB 节点间传播共享。携程独立健康检测的运行效果良好，目前 SLB 系统已经负责了携程超过 5 万个结点的健康检测任务。而下图是由节点独立检测变为节点共享检测时的 SLB 单一服务器网络连接释放状况： 监控数据采集和告警SLB 负责了几乎所有的基于域名的 http 调度请求，所以也成为了进行请求流量统计和请求质量统计的绝佳场所。包括在有问题时进行报警；根据不同维度统计请求量；响应码分布和响应时间分布等，携程使用了分析 access log 的方式来获得监控数据：
[*]SLB 服务器流式读取本机实时产生的 access log；
[*]分析聚合 log 数据，产生不同的统计数据。最终使用了语法树分析实现了高效分析，一秒可以分析 14 万条日志；
[*]定期（1 分钟）将统计数据吐到监控系统 CAT 等。
以此可以产生多维度的监控统计数据，如下图：基于上述数据，可以查看整个携程或单个应用性能表现，进行相应的优化。在慢请求和非 200 请求的数量异常时，执行报警操作，确保及时恢复和挽回损失。想发就发 (TARS)解决了配置和路由问题后，发布系统前置障碍已基本扫除，而从 OPS 角度来看，发布系统还有几个重要目标：
[*]灰度发布
[*]简单易用
[*]发布迅捷
灰度发布通常发布有三种常规方法，蓝绿发布，滚动发布，金丝雀发布。对这三种发布类别做比较，可以发现：（1）蓝绿发布：需要额外的服务器集群支持，且数量可观，同时由于携程单机多应用的部署现状，就会造成发布一个应用需要替换整台服务器的情况，实现难度巨大且成本不经济。（2）滚动发布：虽然可以节省资源，但对应用的兼容性有较高要求，因为发布过程中同时会有两个版本对外提供服务。但这类问题相对容易解决，实际中往往会通过功能开关，dark launch 等方式来解决。（3）金丝雀发布，比较符合携程对灰度发布的预期，但可能需要精细的流控和数据的支持，同样有版本兼容的需求。
[*]发布相关说明 *
蓝绿发布：优先将新版本发布到待发布的机器上，并进行验证，此时新版本服务器并不接入外部流量。发布和验证过程中老版本所在的服务器仍照常服务，验证通过后，经过流控处理把流量引导到新服务器，待全部流量切换完成，老版本服务器下线。滚动发布：从老版本服务器中挑选一批，停止老版本的服务，并更新为新版本，进行验证，通过后再分批增量更新剩余服务器。金丝雀发布：往往从集群中挑选特定服务器或一小批符合要求的特征用户，对其进行版本更新及验证，随后逐步更新剩余服务器。结合携程的实际情况，最终挑选的方式是滚动发布和金丝雀发布的结合体，首先允许对一个较大的应用集群，特别是跨 IDC 的应用集群按自定义的规则进行切分，形成较固定的发布单元。每个应用的每个发布单元称为“group”，这个 group 与之前提到的 SLB 的 group 是一一对应的。每个发布单元，即 group 在发布过程时，还可以再分批进行，完成滚动发布。而每个 group 中包含一台或多台堡垒机，必须先完成堡垒机的发布和验证，才能继续其他机器的发布，从而实现金丝雀发布。除堡垒机的发布外，其他机器可按照用户能接受的最大同时拉出比例来分批，分批间允许设置具体的验证等待时间。每台机器在发布过程中都要经历拉出、下载、安装、点火和拉入这 5 个步骤，发布流程为：基于以上设计，携程新一代发布系统开发完成，命名为 Tars 。Tars 已做了开源，开源版本地址：ctripcorp/tars 简单易用发布配置必须简单易懂，绝大部分的应用发布都是固定模式，不需要个性化配置，所以 Tars 只提供了几个核心配置项，包括（1）允许同时拉出的最大比例；（2）批次间的等待时间；（3）启动超时时间；（4）是否忽略点火。除此以外，用户最关心的是发布过程中可操作按钮的易用性，Tars 在这方面做了充分考虑，通过状态机的控制，保证用户在操作界面上同时最多只看到两个操作按钮，绝大部分情况下用户只需在“继续”或“终止”这样的 0 或 1 的选择中做出决策。而图形化界面的展示，Tars 也确保用户可以更直观地观察到发布的进展，以及出现的问题。有了简单操作，危机时刻就会得到放大体现，比如，因生产故障做回滚时，能快速中断当前发布，并从界面中轻松地选到所需回滚的版本，然后一键无配置地触发完成回滚。 发布迅捷天下武功无坚不摧，唯快不破，而发布也一样。发布速度快了，迭代速度研发效率也就提升了；回滚速度快了，生产故障造成的影响也就减轻了；扩容速度快了，弹性计算就能实施了，这样运维效率被大幅度提升。从上面对发布过程的描述中，不能发现在携程通常影响发布速度的步骤是下载和验证。（1）为了提高下载速度，携程在各个机房搭建了发布包专用的存储系统，实现了类似 CDN 的功能，编译和打包系统在任何一个写入点写入发布包，都会尽快同步到各个 IDC 及各个独立存储中，这样真正发布时，服务器只需从本 IDC 或本网段做下载。而回滚方面，Tars 则是在服务器本地保留了 n 个版本（n 根据服务器磁盘容量计算获得），做回滚时可快速地进行目录切换，进而省略了代码下载过程。（2）对于验证，携程在框架层面统一提供了验证入口和常规验证方法（携程称为“点火”），收口了所有应用的验证规范和标准，容错性得到提升。（3）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 灵活实现灰度流量切换，进而自助、高效、稳定、安全地完成整个应用迁移。
原创：吴其敏等
页:
[1]