携程作为在线旅游公司，对外提供机票、酒店、火车票、度假等丰富的旅游产品，其系统稳定性关乎用户是否具有顺滑的出行体验。然而，流量激增、代码发布、运维变更等都会给系统稳定性带来挑战。 我们在2020年对生产故障的“发现-定位-解决效率”提出了“1-5-10”的目标（即一分钟发现故障，五分钟定位故障，十分钟解决故障），这无疑对监控告警提出了很高的要求。订单量是生产故障异常检测场景中最核心最显性的指标，订单量在自身形态上具有周期性、规律上升和下降、业务高峰和低谷等特点，影响因素包括节假日、促销等。倘若数以万计的业务线通过人工配置规则的方式来覆盖到所有业务场景，并且做到高准确率和召回率，是非常不现实的。因此，迫切需要一套配置费力度低、普适性强、准确率高、时效性强的智能异常检测算法体系来及时发现异常。 指标异常检测是智能运维领域的重要落地场景，携程AIOPS团队致力于提升告警质量，寻找告警效率、准确率和真实故障召回率三者之间的平衡点。我们将统计学方法和机器学习方法结合，根据指标的历史数据，将训练的多个模型组成一套异常检测系统，在覆盖真实故障的基础上，减少告警数量，产生更有价值的告警。
本文主要介绍离在线数据仓库建设在携程旅游团队的落地与实践，将从业务痛点、业务目标、项目架构、项目建设等维度展开。
眨眼之间，距离 React 18.2.0 发布已过了一年多的时间，越来越多的开发者从当初的观望心态，逐步已经将 React18 的新特性投入开发/生产中了，当然，笔者所在的团队也不例外。 今天这篇文章就和大家简单聊聊 React 18 中的 Streaming 。
大多数的技术研发都对重构有所了解，而每个研发又都有自己的理解。从代码重构到架构重构，我参与了携程大型全链路重构项目，积累了一点经验心得，在此抛砖引玉和大家分享。
互联网蓬勃发展的今天是流量为王的时代，但随着流量红利逐渐消失，获客成本的日益增高，用户留存成为各大互联网公司的重点关注问题，其中流失用户的召回在当今的流量红海市场中显得尤为关键，为此，基于大数据和机器学习的智能营销技术应用而生。 携程火车票业务每周都会有短信营销活动，旨在通过对近期未下单的老客发送短信将其召回，促进复购，提升用户粘性（业务流程如图 1 所示）；原有业务策略是基于规则的方式随机从满足条件的用户池中选择一部分进行短信投放，针对该方法过于粗放、召回效果不佳、短信发送 ROI 不高的问题，我们分阶段提出基于 Response Model 的转化率预估模型、基于 Uplift Model 的短信敏感度预估模型，逐一对问题进行更科学的定义、拆解和优化。
目前我们团队小程序是使用 Taro 跨端方案 React 框架进行开发，基于现有样式方案，在编译打包后会产生大量的样式代码冗余，在项目编译后的产物中占有较大比例。
随着上云项目的不断推进，大量的应用需要部署到 aws 上，其中有很多应用都依赖延迟队列的功能。而在 aws 上，我们选择以 Kafka 作为消息队列，但是 Kafka 本身不支持延迟队列，这就需要思考如何基于 Kafka 来实现延迟队列。
携程火车票营销页使用 css 制作动画很多年了，这大大提高了动画给予页面丰富的视觉体验。不过，在开发的过程中，也遇到了一些性能相关问题和用户反馈，比如头部动画卡顿、页面打开时间较长、页面打开后部分数据加载时间较长等问题。为解决这些问题，我们借助性能检测工具定位问题，并查阅源码、文档等资源解决问题，形成了这篇文章。
我们在开发 H5 营销活动后，通常会将营销活动的入口投放到多端，包括 App、小程序。常见的投放形式有：Native 原生页面、React Native 页面和小程序页面的内嵌弹窗。那么此时，就需要 Native、RN、小程序端的人力投入。由此，整个流程从仅需 H5 开发演变成需要多端开发、沟通，从 H5 营销活动灵活上线演变成受制于 App 和小程序的版本发布。 为了优化此流程，我们引入了一种全新的方案——跨端共享 Web 组件。这一方案秉承“一套 Web 代码，多端共享”的理念，旨在缩短上线周期、降低人力成本、并快速响应迭代。采用跨端共享 Web 组件，我们能够高效地实现多端共享，同时也能够更加丰富地展示 Web 组件，从而为我们的业务带来更多的价值。
