随着移动互联网和智能设备的普及，前端开发人员需要采用多端同构技术来适配不同的终端（小程序、App和Web）。这些终端之间存在着明显的差异，包括浏览器引擎、操作系统、交互方式以及代码语言等方面。 这些差异给前端开发人员带来了不少挑战。一方面，不同终端采用不同的浏览器引擎和操作系统，导致页面渲染和交互行为的表现各不相同。另一方面，不同终端所使用的代码语言和开发工具也存在差异，需要开发人员具备不同的技术背景和知识，才能编写多份代码来适配不同的终端。这样做不仅增加了研发人员的开发工作量和代码维护的难度，还可能导致用户在不同设备上遇到不一致的用户体验，影响产品的质量和用户满意度。 为了解决这些问题，多端同构技术应运而生。通过多端同构技术，旅游前端和公共团队合作多端探索与实践，根据不同终端的特性进行灵活的适配和定制。这样可以减少开发成本和维护难度，提高开发效率和代码的可复用性。同时，多端同构技术还能提供一致的用户体验，无论用户使用哪种设备访问应用程序，都能获得相似的界面和功能。
随着多终端的发展，前后端的数据交互的复杂性和多样性都在急剧增加。不同的终端，其屏幕尺寸和页面 UI 设计不一，对接口的数据需求也不尽相同。构建一套接口满足所有场景的传统方式，面对新的复杂性日益捉襟见肘。 在这个背景下，BFF 作为一种模式被提出。其全称是 Backend for frontend，即为前端服务的后端。它的特点是考虑了不同端的数据访问需求，并给予各端针对性的优化。 在这篇文章中，我们将介绍一种基于 RPC 和 TypeScript 的 BFF 设计与实践。我们称之为 RPC-BFF，它利用前后端都采用同一语言（TypeScript）的优势，实现了其它 BFF 技术方案所不具备的多项功能，可以显著提升前后端数据交互的性能、效率以及类型安全。
随着携程机票BU业务规模的不断提高，业务系统日趋复杂，各种问题和挑战也随之而来。对于研发测试团队，面临着各种效能困境，包括业务复杂度高、数据构造工作量大、回归测试全量回归、沟通成本高、测试用例数量多且难以复用、测试数据维护量大以及自动化用例管理等问题。每个都会影响测试团队的效率和质量，给软件研发过程带来挑战。 总结下来主要是两个核心困难点：成本与复杂度。 成本方面，我们通常需要在成本和质量之间做出取舍，需要在快速迭代的同时保证质量，又需要在限定的投入下保证质量。 复杂度方面，当业务规则积累一段时间后，业务流程、规则、场景和数据处理的复杂度在叠加后呈二次或者指数等形式增加，给测试质量工作带来很大的挑战。
携程作为在线旅游公司，对外提供机票、酒店、火车票、度假等丰富的旅游产品，其系统稳定性关乎用户是否具有顺滑的出行体验。然而，流量激增、代码发布、运维变更等都会给系统稳定性带来挑战。 我们在2020年对生产故障的“发现-定位-解决效率”提出了“1-5-10”的目标（即一分钟发现故障，五分钟定位故障，十分钟解决故障），这无疑对监控告警提出了很高的要求。订单量是生产故障异常检测场景中最核心最显性的指标，订单量在自身形态上具有周期性、规律上升和下降、业务高峰和低谷等特点，影响因素包括节假日、促销等。倘若数以万计的业务线通过人工配置规则的方式来覆盖到所有业务场景，并且做到高准确率和召回率，是非常不现实的。因此，迫切需要一套配置费力度低、普适性强、准确率高、时效性强的智能异常检测算法体系来及时发现异常。 指标异常检测是智能运维领域的重要落地场景，携程AIOPS团队致力于提升告警质量，寻找告警效率、准确率和真实故障召回率三者之间的平衡点。我们将统计学方法和机器学习方法结合，根据指标的历史数据，将训练的多个模型组成一套异常检测系统，在覆盖真实故障的基础上，减少告警数量，产生更有价值的告警。
本文主要介绍离在线数据仓库建设在携程旅游团队的落地与实践，将从业务痛点、业务目标、项目架构、项目建设等维度展开。
眨眼之间，距离 React 18.2.0 发布已过了一年多的时间，越来越多的开发者从当初的观望心态，逐步已经将 React18 的新特性投入开发/生产中了，当然，笔者所在的团队也不例外。 今天这篇文章就和大家简单聊聊 React 18 中的 Streaming 。
大多数的技术研发都对重构有所了解，而每个研发又都有自己的理解。从代码重构到架构重构，我参与了携程大型全链路重构项目，积累了一点经验心得，在此抛砖引玉和大家分享。
互联网蓬勃发展的今天是流量为王的时代，但随着流量红利逐渐消失，获客成本的日益增高，用户留存成为各大互联网公司的重点关注问题，其中流失用户的召回在当今的流量红海市场中显得尤为关键，为此，基于大数据和机器学习的智能营销技术应用而生。 携程火车票业务每周都会有短信营销活动，旨在通过对近期未下单的老客发送短信将其召回，促进复购，提升用户粘性（业务流程如图 1 所示）；原有业务策略是基于规则的方式随机从满足条件的用户池中选择一部分进行短信投放，针对该方法过于粗放、召回效果不佳、短信发送 ROI 不高的问题，我们分阶段提出基于 Response Model 的转化率预估模型、基于 Uplift Model 的短信敏感度预估模型，逐一对问题进行更科学的定义、拆解和优化。
目前我们团队小程序是使用 Taro 跨端方案 React 框架进行开发，基于现有样式方案，在编译打包后会产生大量的样式代码冗余，在项目编译后的产物中占有较大比例。
