聊聊大数据元数据管理重要的一环字段血缘。

最近组内同学遇到一个问题，说数据库被业务打死了，无响应，只好用 kill -9 pid 杀掉，然后重启，幸好此时的数据库角色是从库，影响不大。同学自述，在杀掉重启的时候，心里默念，千万别启不来啊，这个库的数据量有点大，快要达到 4T 了。做运维的人都知道，事情就不能念叨，一念叨，这事儿就准发生。这次也不例外，确实是出现了。现象是长时间启动不了，基本卡死状态。

一道 Sequence 的“开水白菜”，敬请“享用”。

随着携程海外酒店业务的发展，遍布全球的海外供应商与携程总部IDC之间的数据传输量快速增长。技术上，这种日益增长的数据量对跨境网络专线的带宽、延迟等提出了更高的要求；业务上，由于当前有限的跨境网络专线资源对业务处理效率及用户体验也造成了一定的影响；成本上，跨境网络专线作为一种昂贵的资源，通过单纯的专线扩容又会给IT成本造成巨大压力。所以我们开始思考是否可以通过公有云结合酒店直连的业务特性来解决日益增长的带宽压力和供应商接口延迟的问题。

酒店直连系统主要是使用自动化接口实现供应商或集团与携程之间的系统对接，实现静态信息、动态信息、订单功能等都通过系统的方式流转交互。目前携程大量海外酒店业务是通过酒店直连系统对接。

本文将主要从携程酒店直连服务迁移部署至AWS过程中所进行的应用架构调整及云原生改造，使用AWS后取得的技术和业务收益，在部署过程中对EKS（Amazon Elastic Kubernates Service）、DNS查询延时和跨AZ流量降低所做的成本优化等几方面进行详细介绍。

一个表的数据量达到一定程度后，稳定性和性能就会出现瓶颈，"化整为零"对DBA 来说无疑是一个很好的选择，此时如何分表就成为摆在业务线开发同学和 DBA 面前的一道不可回避的课题。

相对于传统的开发同学自己根据业务及自己在应用代码中实现分表的方案，本文介绍一下 PostgreSQL 中如何实现对业务相对透明的分区方案。

Qunar 机票作为 Qunar 的核心业务之一，每天都有成千上万用户在 Qunar 的平台上完成搜索预定生单等操作， Qunar 也一如既往地为用户提供优质的出行体验和保证。

探索采用非人工标注文本数据的方式来建立训练数据集的可行性。

Google Play 商店在 2021 年第 3、4 季度正式加强对应用 targetSdkVersion 的限制，要求应用必须以 API 级别 30 (Android 11) 或更高版本为目标运行环境。

作为第一个强制要求分区存储的 API 级别，Android 11无疑是近几年适配工作较为复杂的版本，各个 APP 的适配进度也被寄予期盼。Trip.com APP 在 2021 年第一季度进行了 Android 11 的适配，本文将从方案设计和技术改造等⻆度，聊一聊我们的实践与感想。

随着公司业务的不断扩张，无论是后端、前端抑或是客户端，都面临着应用越来越复杂，越来越庞大以至于难以维护和治理的问题，为了解决这个问题，后端的微服务架构就应运而生了；同理，前端的业务也遇到了类似的问题，自然而然的微服务架构的思想照搬到前端，于是前端的微前端架构应用而生：

一种由独立交付的多个前端应用组成整体的架构风格。具体来说就是将前端应用分解成一些更小、更简单的能够独立开发、测试、部署的小块，而在用户看来仍然是内聚的单个产品。

在进入页面的过程中，用户不可避免地会看到一个加载动画。但加载动画往往比较古板，如果加载耗时稍微长一点，用户就会失去耐心离开页面。为了让用户有更好的浏览体验，骨架屏是一种较好的渐进式加载方案。

骨架屏的实现，也是视觉稿直出代码实现方案的 MVP (Minimum Viable Product)。本文会探讨骨架屏方案的优劣，以及一种前端智能化的骨架屏代码自动生成方案实践。

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

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

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

从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思想，在携程国际火车票中台预订系统项目进行实践。

酒店差价由来已久。