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

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

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

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

　　一、写在上面

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

　　【关于同程优采云发布】

　　具体来说，携程Croller设计的是优采云模式发布，主要面临的核心问题包括：

　　二、从破题到解题

　　1.破题思路

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

　　我们解决思路包括：

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

　　这些定义如下：

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

　　Server

　　代表服务器

　　Pool

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

　　Group

　　一组相同应用的实例集合

　　

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

　　

　　（3）设计实现新一代的发布系统Tars，解决Croller发布系统的疼点，支持应用级的发布。

　　

　　2.具体实现

　　虽然有了破题思路，但具体实现一直有很多细节须要考虑，主要包括：

　　（1）统一配置（CMS）

　　（2）弹性路由（SLB）

　　（3）想发就发（TARS）

　　统一配置（CMS）

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

　　不成熟的配置管理常常有以下特点：

　　而艺龙这些配置管理曝露出好多问题，当监控到服务器资源异常时，例如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插口的调用情况。

　　

　　弹性路由（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：

　　2. 多次更新一次生效

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

　　Group的每次变更就会形成一个新的版本；Group的所有变更就会留下日志；对Group的变更操作并不会直接对生产生效，可以在多次变更后，有一次明晰的激活操作后，从而在生产环境即将生效。

　　

　　3. 多并发操作

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

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

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

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

　　4. 多角色运维的冲突

　　一个Group可能会有多种角色进行更新，比如应用Owner、专业运维人员和发布系统人员等。这就引出了一个新的问题，即当一个角色对一个Group的服务器进行拉出操作后，另一个角色可不可以对这种服务器做拉入操作？比如，发布系统人员在发布完成后，准备做拉入，却发觉运维人员对这台服务器进行了拉出操作。这时发系统应当怎样决策？这除了导致决策的困惑，也会使不同的角色形成联系，甚至互相耦合在一起。

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

　　5. 健康检查带来的困局

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

　　

　　【携程的健康检查疗效】

　　携程独立健康检查的运行疗效良好，目前SLB系统早已负责了艺龙超过5万个结点的健康检查任务。而下图是由节点独立测量变为节点共享检查时的SLB单一服务器网路联接释放状况：

　　

　　6. 监控数据采集和告警

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

　　以此可以形成多维度的监控统计数据，如下图：

　　

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

　　

　　想发就发(TARS)

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

　　1、灰度发布

　　通常发布有三种常规方式，蓝绿发布，滚动发布，金丝雀发布。对这三种发布类别做比较，可以发觉：

　　【发布相关说明】

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

　　

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

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

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

　　

　　每个发布单元，即group在发布过程时，还可以再分批进行，完成滚动发布。而每位group中收录一台或多台堡垒机，必须先完成堡垒机的发布和验证，才能继续其他机器的发布，从而实*敏*感*词*丝雀发布。除堡垒机的发布外，其他机器可根据用户能接受的最大同时拉出比列来分批，分批间容许设置具体的验证等待时间。

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

　　

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

　　【Tars源代码】Tars已做了开源，开源版本地址：

　　2、简单易用

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

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

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

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

　　

　　

　　3、发布迅捷

　　天下武功无坚不摧，唯快不破，而发布也一样。发布速率快了，迭代速率研制效率也就提高了；回滚速率快了，生产故障导致的影响也就减少了；扩容速率快了，弹性估算才能施行了，这样运维效率被大幅度提高。从里面对发布过程的描述中，不能发觉在同程一般影响发布速率的步骤是下载和验证。

　　三、结果和未来

　　通过CMS+SLB+TARS几个系统的联动，并经历了历时一年半的项目推广阶段，终于实现了1+1+1>>3的疗效。新发布系统对于研制效率和研制人员体验的提高都十分明显。

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

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

　　全天候聚焦IaaS/PaaS/SaaS最新技术动态，深度挖掘技术大咖第一手实践，及时推送云行业重大新闻，一键关注，总览*敏*感*词*云计算大势！