公司:携程
携程集团有限公司(英语:Trip.com Group Ltd),是一家总部设立在上海的中国大型旅游网站,1999年创办。2003年12月,该公司在美国纳斯达克(股票代码:TCOM)上市。目前携程已在中国大陆的北京、广州等17个城市设立分支机构,在南通设立服务联络中心,并在香港及台湾皆有旗下事业,占中国在线旅游市场份额一半以上,是中国最大的在线旅行社,也是全球最大的在线旅行社之一。携程旗下拥有携程网、去哪儿网、Skyscanner、Trip.com四个主要品牌,以及驴评网、鸿鹄逸游、永安、易游等多个支线品牌。
去哪儿旅行混沌工程落地实践
去哪儿旅行微服务架构下的系统强弱依赖演练以及攻防演练的成功实践。
携程微信小程序如何进行Size治理
包体积过大必将导致新增业务受限、启动慢等问题。
支持10X增长,携程机票订单库Sharding实践
随着机票订单业务的不断增长,当前订单处理系统的架构已经不能满足日益增长的业务需求,系统性能捉襟见肘,主要体现在以下方面:
-
数据库CPU资源在业务高峰期经常达到50%以上,运行状况亮起了黄灯
-
磁盘存储空间严重不足,需要经常清理磁盘数据腾挪可用空间
-
系统扩容能力不足,如果需要提升处理能力只能更换配置更好的硬件资源
因此我们迫切需要调整和优化机票订单数据库的架构,从而提升订单系统的处理性能。通过建立良好的水平扩展能力,来满足日益增长的业务需求,为后续系统优化和支撑10x订单量的增长打下良好基础。
业务缓存之体系化设计与开发
进入持续维护期的项目在性能优化过程中,缓存侧体系化设计与开发的真实案例。
携程机票前端Svelte生产实践
以一种新的思路实现了响应式。
从47%到80%,携程酒店APP流畅度提升实践
数据量化的意识,用户视角出发优化和解决问题。
不要再使用MySQL online DDL了
如何更优雅的执行DDL操作,怎么避免线上踩坑,一文带你选择更合适的操作方法。
携程公共技术支持运营实践
帮助研发团队节省35%人力投入,为用户节省50%报障处理时长。
携程百亿级缓存系统探索之路——本地缓存结构选型与内存压缩
携程酒店查询服务是酒店BU后端的核心服务,主要负责提供所有酒店动态数据计算的统一接口。在处理请求的过程中,需要使用到酒店基础属性信息、价格信息等多维度的数据信息。为了保证服务的响应性能,酒店查询服务对所有在请求过程中需要使用到的相关数据进行了缓存。随着携程酒店业务的发展,查询服务目前在保证数据最终一致性以及增量秒级更新延迟的情况下,在包括服务器本地内存以及Redis等多种介质上缓存了百亿级的数据。
本文将主要讨论酒店查询服务技术团队是如何在保证读取效率的前提下,针对存储在服务器本地的缓存数据进行存储结构选型以及优化的过程。
写好技术原创文章的一点建议
分享自己写技术原创文章的一些经验和心得,希望能起到一定的指导的作用。
携程机票跨端跨框架 UI 自动化测试方案 Flybirds
多端研发对于当今时代的前端开发来说是个绕不过去的话题,为了解决这些问题,行业内推出了很多开发方案,但是跨端 UI 自动化测试的解决方案并不多。
Flybirds从2022年初开源至今已有3月有余,通过与社区内活跃用户的交流和反馈,推出了v0.2 版本的跨端跨框架测试方案,一套脚本多端运行,插件化的架构设计,也方便社区开发者自由加入扩展,一起共建成长。
携程基于BookKeeper的延迟消息架构落地实践
消息业务和存储层面完全分离,延迟消息服务可轻易伸缩。
去哪儿旅行海量指标数据采集与存储
基于去哪儿网真实生产案例,轻松解决海量指标收集遇到的瓶颈问题。
携程机票iOS Widget实践
Widget俗称小组件,是苹果推出的众多App Extension中的一款。因此在介绍Widget之前,需要先了解App Extension及其工作原理。
携程 SOA 的 Service Mesh 架构落地
已接入 2000 个应用、4000 个服务和 6000 个 Pods。
动态化UI在Qunar客户端首页的应用
在上线动态化 UI 之前,Qunar 大客户端的首页内容基本都是基于 Native 进行开发的。在保证 APP 的冷启动性能,为用户带来流畅的体验的同时,其实也存在着以下的一些痛点:
- 首页功能的修改大部分需要发版解决,导致了功能迭代周期较长
- 线上如果发现问题的话,修复成本较高,修复时机会有较大延迟
针对以上的痛点,我们针对首页,引入了动态化 UI,当时的期望如下:
- 性能媲美 native,保证用户体验;
- 功能可以通过热发迭代,对动态化内容进行在线实时发布,实时灰度,实时下线,保证功能的稳定可控;
- 动态化内容易于编辑,学习成本较低,前端开发可以轻松进行UI样式的开发、实时预览;
- 支持数据绑定,模板样式与业务模型解耦;