随着国际火车票业务的高速发展，订单量快速增长，单数据库瓶颈层面的问题逐渐显露，常规的数据库优化已无法达到期望的效果。同时，原先的底层数据库设计，也存在一些历史遗留问题，比如存在部分无用字段、表通过自增主键关联和各个应用直连数据库等问题。

为此，经过讨论后，我们决定对订单库进行分库分表，同时对订单表进行重构，进而从根本上解决这些问题。

去哪儿机票售后为用户提供退票、改签、航班变动、行程服务、疫情政策等服务的业务。为解决复杂查询场景，我们设计了一套将数据从一个数据源聚合导入到另一个数据源，提供同构或者异构、低延时的、最终一致性的数据同步系统。

从2017年开始，携程用户搜索时使用的关键词发生了一些有趣的变化：虽然传统的热门目的地词如“上海、北京”依然占比很高，但是大量长尾词如冷门景点、新兴景点也开始在搜索热词榜上占据一席之地。

对此团队进行了相应的数据分析，发现这些长尾词的急剧上升与一些外部热点如微博热搜，抖音网红，小红书热门文章等呈现正相关关系。对这个问题深入研究后发现，随着互联网用户的年轻化，网民们探索问题的热情明显变高，认知闭合（cognitive closure）度高的用户数量开始快速上升，他们在外部媒体获取到了目的地的热点和信息后，有意愿来专业旅游网站获取更多的目的地资讯，减少不确定性。因此大量用户会搜索长尾词。

随着前端职能在互联网公司的重要性与日俱增，我们的前端代码库的体积也开始跟着膨胀，特别是基于 React 的应用，Size 常常以兆 (Mb) 计，给渲染的性能优化提出了巨大的挑战。除了体积，还有另一个问题是，在当下的前端同构 SSR 实践中，Server 端的主要用途是执行一些在服务端和客户端都能执行的通用渲染计算，很少能充分发掘 Server 端特有能力的场景。如何降低客户端 JS Size 以及更极致地挖掘服务端的优化能力，成为一个待解决的开放性问题。

Facebook 的 React Team 尝试给出了他们的一个探索方案——React Server Component。一种只运行在服务端的 React 组件化能力，我们来一探究竟。

领域驱动设计（Domain-Driven Design，简称 DDD）是一种软件开发设计思想，其旨在以领域为核心，让软件系统在实现时准确地基于对真实业务过程的建模，专注于业务问题域的需要。

DDD将软件系统设计分为了2个部分：战略设计和战术设计，战略设计用于提炼问题域并塑造应用程序的架构，战术设计用于帮助创建用于复杂有界上下文的有效模型。基于此，DDD强调专注于核心领域，通过协作对公共语言和知识进行提炼，并且持续致力于领域的知识提炼，让模型持续发展。

本文基于DDD思想，在携程国际火车票中台预订系统项目进行实践。

酒店差价由来已久。

携程一直注重用户的服务效率与服务体验，在售前、售中、售后全过程中给用户提供高效的客服支持。

用户访问客服页面后，会首先与智能客服进行对话，当智能客服给出的回答无法解决用户问题时便会接入人工客服，再由人工客服给出专业的解答。对话完成后，系统根据人工客服会话内容，应用NLP相关技术给出会话类别。这一结果将直接指导客服的管理与决策。本文将主要介绍携程机票在人工客服会话分类时使用的相关NLP技术和优化方案。

一旦需要进行问题排查的时候，往往重要且紧急，排查效率显得尤为重要。

在相同硬件资源下，QPS提升2~3倍，RT缩短近50%。

如果能够让现有的团队发挥最大的作用，最好的办法就是把老的创始人拉回来带着他们拼命跑一阵。

手势控制、布局原理、吸顶、懒加载。

私有云上已有10T+数据量，节约90%成本。

携程金融从成立至今，整体架构经历了从0到1再到10的变化，其中有多个场景使用了缓存来提升服务质量。从系统层面看，使用缓存的目的无外乎缓解DB压力（主要是读压力），提升服务响应速度。引入缓存，就不可避免地引入了缓存与业务DB数据的一致性问题，而不同的业务场景，对数据一致性的要求也不同。本文将从以下两个场景介绍我们的一些缓存实践方案：

• 最终一致性分布式缓存场景
• 强一致性分布式缓存场景

注：我们DB用的是MySQL，缓存介质用的是携程高可用Redis服务，存储介质的选型及存储服务的高可用不是本文重点，后文也不再做特别说明。

H5转换小程序时的选型考量、问题及处理方案。

文章主要介绍去哪儿是如何建立和完善去哪自己的DNS系统。

Server与SW2的BGP正常建立，BFD邻居不能正常建立。