借鉴经典图像算法，NLP领域“新词发现”任务的一种创新解法。

基于具体案例，分享选型与落地实践过程中的问题及思考。

随着移动端短视频的火热，音视频编辑工具在做内容类APP上的地位举足轻重。丰富的转场方式可以给短视频带来更多炫酷的效果，从而更好地赢得用户青睐。本议题主要包含了对OpenGL的简单介绍及相关API使用，GLSL着色器语言的基本使用，以及如何通过编写自定义的着色器程序来实现图片的转场效果。

列表页渲染、交互速度提升20%，大幅提升页面流畅度和用户体验。

编译打包速度提升30%+，大幅提升开发体验。

去哪儿旅行 UI 自动化系统 TARS 于 2020 年 3 月启动，到 2020 年底达成一期预计目标。覆盖公共、机票、酒店等多个部门接入，月版发版30多次，回归执行自动化上百次，200多个项目发布执行 400 多次，发版无 P1、P2 故障，节省人力近千 pd 。

沙箱提高8倍上线效率，限流、熔断大幅提高稳定性。

高性能、高可用、可扩展、可伸缩、可维护、安全性 等都是技术人员常聊的话题，也是每个后端工程师必须了解和掌握的通用技能。本篇文章将从软件性能入手，探究性能到底是什么、由什么组成，推演出性能提升主脉络，总结通用思想及方法，并配合跨领域的数个具体案例辅助理解，最终形成一套完整的高性能思维框架。

查询耗时提升4倍，写入稳定性提升。

Dynamo风格数据库来源于亚马逊的Dynamo: Amazon’s Highly Available Key-value Store 论文，在该论文中论述了一种无主复制的数据库，受此启发，携程酒店开发了多存储介质预定库Hare和高可用性高性能的动态信息存储服务InfoKeeper。本文将介绍Dynamo风格的无主复制数据库，及其在携程酒店的实践。

随着互联网世界产生的数据越来越多，数据之间的联系越来越复杂层次越来越深，人们希望从这些纷乱复杂的数据中探索各种关联的需求也在与日递增。为了更有效地应对这类场景，图技术受到了越来越多的关注及运用。

在携程，很早就有一些业务尝试了图技术，并将其运用到生产中，以Neo4j和JanusGraph为主。2021年开始，我们对图数据库进行集中的运维治理，期望规范业务的使用，并适配携程已有的各种系统，更好地服务业务方。经过调研，我们选择分布式图数据库Nebula Graph作为管理的对象，主要基于以下几个因素考虑：

1）Nebula Graph开源版本即拥有横向扩展能力，为大规模部署提供了基本条件；

2）使用自研的原生存储层，相比JanusGraph这类构建在第三方存储系统上的图数据库，性能和资源使用效率上具有优势；

3）支持两种语言，尤其是兼容主流的图技术语言Cypher，有助于用户从其他使用Cypher语言的图数据库（例如Neo4j）中迁移；

4）拥有后发优势（2019起开源），社区活跃，且主流的互联网公司都有参与（腾讯，快手，美团，网易等）；

5）使用技术主流，代码清晰，技术债较少，适合二次开发；

去哪儿旅行非常重视测试环境治理，提高开发和测试人员的使用效率。从 2018 年就开始了测试环境治理和优化之路，到目前为止总共进行了三轮环境治理和优化。

在携程国际化战略背景下，海外业务将成为新的发力点，为了保证用户高品质的服务体验，底层数据势必需要就近服务业务应用。一套标准且普适的数据复制解决方案能够提升业务决策效率，助力业务更快地触达目标用户。

DRC (Data Replicate Center) 作为携程内部数据库上云标准解决方案，支撑了包括但不限于即时通讯、用户账号、IBU在内的核心基础服务和国际业务顺利上云。

随着微服务架构的普及，这些微服务构成了复杂的分布式网络，在支撑我们海量查询的同时，也带来了一些问题。

机票前台预订主流程服务现在有若干个系统，每个系统部署了多个服务，每个服务又依赖多个API，用户通过终端设备（手机、PC等）预订了机票产品，过程中出现“系统异常”该如何分析排查呢？

运营人员将问题抛给开发/测试人员定位，开发/测试人员只知道有异常，如何高效地从复杂的调用链条中找到原因，这对开发/测试人员会带来很大的挑战。

开发/测试人员借助单点日志逐个排查的效率是非常低的，特别是一些UI层的“待确认”的问题，只依赖一些日志报文进行排查效率是非常低下的。

如何提高开发/测试人员的排查效率，同时降低非开发人员的使用门槛？答案或许就是携程机票前台Trace系统。

携程的冷数据规模在 10PB+，包括备份数据、图片语音训练数据和日志数据等，存储方案主要是本地磁盘和GlusterFS。在实际使用中这些方案遇到了不少痛点：

• GlusterFS 在单目录下文件众多时，ls命令速度很慢；
• 受疫情期间机器采购周期的制约，无法灵活地根据实际需求弹性扩缩容，存储成本控制困难；
• 磁盘损坏等故障带来的机器替换和扩缩容操作，使得运维成本居高不下。

随着云计算技术的发展，公有云厂商为混合云客户提供了海量冷数据的廉价存储方案，经过严谨的成本计算，我们发现使用公有云的对象存储可以显著降低存储和运维成本。为了减少迁移成本，我们一直在寻找后端存储能支持各类公有云对象存储、高性能的文件系统，直到JuiceFS 出现在我们的视野中。JuiceFS有以下优势：

• POSIX 接口，对应用无侵入
• 强一致性，文件修改立刻可见，为同一个 volume 被多台机器挂载的场景提供 了close-to-open 保证
• 支持了主流的公有云对象存储，支持开源软件作为元数据引擎（Redis、TiKV）等
• 支持云原生，能够将volume以 CSI 的方式挂载到Pod上
• 社区活跃，代码更新快

经过大半年的测试和使用，我们已经对接了数据库备份和 ElasticSearch 冷数据存储，将2PB+的数据迁移到了JuiceFS，预计后续还会有10PB+的数据接入。目前JuiceFS系统稳定，在降低运维成本和存储成本方面取得了良好的效果。本文将对JuiceFS原理以及我们在使用中所遇到的问题和采取的优化方案进行简单介绍。

乐高系统是携程市场研发部开发的活动搭建平台，主要满足运营所需的各种营销、广告、频道、定制等页面的快速灵活搭建。平台在自身发展的过程中不断改进。刚开始着力于满足运营配置需求，满足业务需求，不断扩充和丰富组件库，目前平台已配置了10000+ 有效页面，同时在线页面达到1000+，组件类型300+。当体量达到一定程度后，我们又在思考，平台能力的边界在哪里，如何推动平台创造更大的价值？

这个时候，建设平台不再局限于扩展组件等基础建设，会更多地考虑如何将平台建设为一种“开放性”的平台，将平台优秀，成熟，可扩展的“点“开放出去，使平台或者平台相关技术在其他团队或者场景中有更多的应用，产生更大的价值。这种开放性的思路，也积极促进了平台的进一步发展。

这篇文章将总结我们在平台建设中一些相关思考和实现细节。