眨眼之间，距离 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 组件，从而为我们的业务带来更多的价值。
在现今的信息时代，微服务技术已成为一种重要的解决方案，微服务技术可以使系统的规模和功能变的更加灵活，从而获得更高的可扩展性和可用性。然而，微服务调用中出现的超时问题，却也成为系统可用性的一大隐患。超时会导致客户端的性能下降，甚至可能无法正常工作。本文针对超时问题，提出相关的优化手段，降低微服务调用超时的风险。
注册风控是企业风控场景中重要的一环，黑产用户想要进行各式各样的欺诈行为，首先需要注册账户。通常，这些黑产用户会采用技术手段批量注册虚假账号，而后进行一系列恶意行为。那么，如何准确快速地识别注册用户是否是异常聚集的黑产用户，这是注册风控场景中需要解决的一个问题。 因此，本文介绍了一种当前在携程商旅应用的基于注册图网络的恶意账户聚集检测模型。
