在上个月，携程网刚过完自己的 21 周岁生日。

在年初，听到了很多关于携程业务量锐减的新闻，当然这是无法避免的过程。当时我就在想，这样大体量的公司，如何在“业务量很轻松”的情况下，继续激发人员进行技术开发，保持斗志？如何继续修炼技术内功呢？

恰巧在准备 12 月 20 日QCon 全球 软件开发大会（上海站）的时候，有幸邀请到携程商旅事业部 CTO 宋涛老师来担任高可用架构专题出品人，我也借机问了一些关心的问题。

宋涛加入携程前，曾在微软，亚马逊总部长期担任技术管理工作，在操作系统内核和云计算等领域有着丰富的经验。担任过 AWS 云存储服务技术主管，对系统可靠性，高并发和数据一致性有深入研究。2017 年加入携程集团，先后担任机票事业部技术总监，商旅事业部 CTO 等职务。领导研发了携程新一代机票搜索引擎，显著提升了高并发查询下的系统性能和可靠性。架构设计、人才培养、技术改造

宋涛目前在商旅事业部主要负责携程商旅的技术发展战略和方向，以及具体的落地方案和计划。同时负责关键项目的架构设计，技术选型以及运维模式。另外，为技术团队的管理工作提供指导，OKR 制定和人才培养。目前商旅需要解决的关键问题包括：提升系统发布质量，提高研发产品流转效率，以及加快对客户需求的反应速度。

在担任商旅 CTO 之前，宋涛曾担任携程集团机票业务技术总监。很多人都会问技术总监升 CTO 后的工作模式有哪些变化，在认知上需要做哪些转换。

宋涛说，工作的主要转变是从一个以执行落地为主的角色，转变为一个以方向及目标设定为主的角色。另外，CTO 是技术团队的带头人，同时又是技术团队的代言人。需要能使用非技术性语言和业务团队以及客户交流，有效沟通传递业务和技术双方的观点。

宋涛在微软 Windows 团队和亚马逊 AWS 云计算团队工作多年，受两个公司的工程师文化影响比较大。

这两个团队对系统可靠性有着极高的要求，实现方式则各有不同。Windows 团队通过对代码和测试的质量提升，来减少问题出现的可能性；AWS 云计算通过对 DevOps 和敏捷开发的重视，强调质量问题的快速发现和恢复。

在国外多年的工作历练，某种程度上也帮助了宋涛在处理内部团队交流和技术选型等方面所遇到的问题。所以，目前对商旅技术团队的技术水平和运维能力有一个比较客观的评价，并根据业务需要和当前的现状，制定合理的目标。基础架构升级

携程机票 / 酒旅的业务模型是多元化的，这些特性对基础架构产生的挑战可想而知。

携程机票系统是要实现在高并发情况下的高可用。同时，由于机票搜索需要进行动态的航路分析，航段组合和税费计算，对实时计算的性能要求很高。宋涛说，为了补充产品丰富性，机票事业部引入了国际上一些机票分销系统（GDS）和廉价航司直联系统。这些外部数据源的处理要求携程的系统在高 I/O 的情况下保持较高的性能。

为了应对这些挑战，在基础架构上，携程针对业务特点进行了持续的技术改造，打造了世界领先的机票引擎。

宋涛在此前的“日均 20 亿流量：携程机票查询系统的架构升级”演讲中详细阐述了基础架构的构成：三个独立的数据中心：可以互相做灾备，已实现其中一个数据中心完全宕机情况下，携程业务不受影响技术栈：携程 DataCenter 技术栈是采用 SpringCloud+K8s+ 云服务（海外）模式基于开源 DevOps 构建了整套 DevOps 工具和框架多种存储方案：携程内部有可用度比较高的存储方案，包括 MySQL，Redis，MangoDB……网络可靠性：携程非常注重网络的可靠性，做了很多 DR 的开发，做了很多 SRE 实践，广泛推动了熔断，限流等等，以保证用户高质量的服务

此外，在基础架构方面，携程推动了多数据中心的部署，实现了常规的数据备份和灾难恢复演练。在系统架构方面，机票系统对缓存和任务 pooling 进行多次演进，并建立了基于 React Programming 的异步非阻塞的主流程改进。

这里可以介绍几个比较典型的架构演进方面的知识点，例如缓存架构的演进，一级缓存使用了 Redis，当时主要考虑读写性能好，快速，水平扩展性能强，能够提高存储量以及带宽。

可在当前设计中有两个局限性：首先为了简单，使用了固定的 TTL，这是为了保证返回结果的相对新鲜。第二，为了命中率和新鲜度，研发团队还在不断地改善。

其次是缓存架构上，二级缓存最早采用了 MongoDB，其读写性能较好，同时支持二级缓存。但也有一些局限性，多引入一种存储方式会增加维护成本。其次，MongoDB 的 License 模式使得费用非常高。

针对 MongoDB，研发团队做了提升，把它切成 Redis，这个改进方案的结果，是成本降低了 90%，读写性能提升了 30%。业务需求和体系结构升级换代之间的平衡点

技术要给业务赋能，这是技术团队的重要价值。宋涛说，针对架构升级可以着重把握两个点，一是要有前瞻性，一般而言，一个架构能满足“3 年 5 倍”的业务增长速度，就已经有足够的前瞻了。

其次，是要能用量化指标发现架构的瓶颈，并用适度的创新来解决瓶颈问题。宋涛在国外工作期间，常听到的一句话就是“No measurements，no improvements”。要创建多维度的监控指标，用数据来发现系统和架构的瓶颈。在瓶颈确认之后，确实需要下一定的决心，投入资源进行重构。对于其中的关键组件，要事先想清楚替代组件的灰度替换计划。对于复杂度高的核心系统，在架构升级时，可以先把一部分功能独立出来，重构之后再以微服务的形式灰度接入原有大的系统，采用小步慢跑的方式逐步实现重构。

另外，有一个思维陷阱要尽量规避，当一个新的 owner 接手系统时，往往由于对原有的系统不太了解产生一种不安全感，会有重构的冲动，潜意识里是希望通过重构来掌握系统细节。这种冲动和真实的技术需求要区分开。

在基础架构演进的过程中，多数人都会碰到棘手的技术问题，宋涛提到一个缓存演进经历过一个 Redis 到 MangoDB 又回归 Redis 的历程，其中有一个功能丰富度和系统运维能力的权衡。对于大流量高并发的系统，采用成熟技术并提升团队运维和灾难恢复能力是技术团队需要优先考虑的问题。

在谈到基础架构的发展是否要先于业务的时候，宋涛说，有 Spring Cloud 的各种开源系统和国内外头部互联网的实践做基础，基础架构的前瞻性研究难度已经大幅下降。挑战比较大的是如何做权衡（tradeoff）。而根据各个公司和业务的情况不同，大家要权衡的因素会差别很大。

对于像携程这种有 20 年历史的科技公司，对历史架构的兼容是一个很大的挑战，某些场景下甚至是很大的负担。在对技术趋势充分了解的情况下，重点技术选型向业界流行标准靠拢会是一个相对稳妥的方案。时刻带领团队修炼技术内功

疫情期间，携程商旅团队密切跟踪疫情的进展并积极向客户提供急需的各项功能服务，其中包括广泛使用的疫情通告和员工健康管理功能。另外，为了纾解受疫情影响客户的财务问题，商旅技术团队对结算系统进行了多次敏捷发布，把国家公布的针对企业的各项财务税收优惠政策，第一时间落地。同时，根据疫情期间业务量下降的情况，携程商旅及时调整资源，推动多项技术改造项目，极大的提升了商旅系统的易用性和数据一致性。

伴随着疫情的缓解，携程商旅的努力得到了回报，多项业务指标不仅超过去年同期水平，还连创新高，通过质量和服务的提升，进一步巩固了携程商旅在市场上的领先地位。

关注我并转发此篇文章，私信我“领取资料”，即可免费获得InfoQ价值4999元迷你书，点击文末「了解更多」，即可移步InfoQ官网，获取最新资讯～

相关文章