随着历史业务不断迭代和业务场景越来越复杂，携程用车、租车（简称两车）面临历史技术债和系统复杂度越来越高带来的理解、维护、迭代困难等问题，我们开始寻求如何更有效的降低复杂度和提升效率的方法。 本文描述了两车如何利用DDD（Domain-driven Design，领域驱动设计）方法论降低系统复杂度以及在重构历史系统中的取舍和思考。对于复杂业务场景下的领域驱动设计具有借鉴意义。
携程小程序自动化错误预警方案是一套完整且通用的小程序前端错误监控方案。此方案提供小程序错误自动采集SDK，并对错误所在的页面路径进行偏移矫正，能够准确通知相应的开发负责人；将错误信息分为生产、测试、开发3种阶段，根据错误发生的阶段提供相应的错误预警及处理方案；开发负责人只需在小程序管理平台配置告警所需信息，即可快速接入、实时监控生产报错、生成告警通知；源码映射能力可以帮助开发者快速定位错误原因，提升修复效率。接入此方案可实时捕获开发环境错误，确保在小程序发布上线前发现并解决业务报错，可极大地减少线上小程序的错误量。
在软件开发过程中，团队协作效率的提高是我们共同关注的问题。为了解决这一问题，许多团队都开始使用智能化工具。Design2Code（简称D2C）工具是其中一种广受欢迎的选择。 在本文中，我们将分享D2C工具的核心算法方案设计和实现过程，以及一系列的解决方案。无论你是开发人员，还是设计师，本文都将为你提供有价值的信息。我们希望，通过阅读本文，能帮助你更好地了解D2C工具，并在实际工作中发挥出最大的价值。
在容器化部署成为主流的现在，降低集群中单个容器的资源需求的意义已经不只限于更少的硬件成本，同时也意味着整个集群更加轻量化，这通常会带来一系列其他优势：例如更短的恢复时间，更精确的资源控制和调度，和更快速的伸缩和部署等。但在另一方面，一味的追求压缩容器配置必然会严重影响应用在稳定性、响应耗时和吞吐量等方面的表现，所以轻量化的措施需要在多个性能维度上进行仔细的权衡取舍，以达到一个总体更优的结果。 作为携程计算量最大的接口之一，酒店查询服务一直承担着沉重的硬件成本压力，仅仅详情页集群就包含了千余台服务器实例和数十TB的Redis资源，因此对应用进行全面的轻量化有着很高的必要性和预期收益。在内存方向上，我们的主要目标是将单个容器的内存从32GB压缩到16GB，并在以下两个基本方向上进行了探索： 减少内存增长速度：压缩本地缓存，减少浮动内存的产生，并对线程，类库，参数和代码逻辑进行针对性的优化和调整。 提升内存管理效率：加强JVM等服务依赖的基础组件其本身的性能。 由于第一个方向需要根据应用的具体代码实现来分析和排查，普适性相对较差
今天这篇文章中和大家聊一聊号称世界上第一个 O(1) 的 JavaScript SSR 框架：qwik。 别担心，如果你不是特别了解 SSR 也没关系，文章大概会从以下几个方面作为切入点： 首先会围绕对比 SSR 与 SPA 各自的优劣势，从而展开 SSR 的运行机制以及 SSR 相较于 SPA 究竟为了解决什么问题。 之后，会根据 NextJs 的运行机制思考针对目前主流 SSR 框架设计思路上存在的不足从而引出 qwik 为何会在众多成熟框架中脱颖而出。 最后，会针对于 qwik 提出自己的看法以及聊聊目前 qwik 存在的“问题”。 诸如社区内部 SSR 框架其实已经产生了非常优秀的作品，比如大名鼎鼎的 NextJS 以及新兴势力代表的 Remix 和 isLands 架构的 Astro、Fresh 等等优秀框架。 为何 qwik 可以在众多老牌优秀框架中脱颖而出。接下来，让我们一起来一探究竟吧。
本文将从以下五部分切入，讲述日志系统的演进之路：携程日志的背景和现状、如何搭建一套日志系统、从 ElasticSearch 到 Clickhouse 存储演进、日志3.0重构及未来计划。
Taro-CRN是帮助携程开发者基于Taro开发CRN项目的框架，实现一套代码在小程序和APP上的跨端开发，也为后续携程的跨端开发生态打下基础。Taro-CRN由携程机票团队与火车票团队共建而成。Taro本身是业内比较成熟的跨平台解决方案，目前已经支持转换到多平台小程序、H5、RN页面，并且有很好的社区支持。 在携程内部，Taro也拥有同样广泛的使用基础。多个业务线应用Taro来实现多平台小程序的开发，也有大量的H5业务页面是由Taro-H5转换而成。然而，Taro-RN作为Taro跨端开发方案的最后一块拼图，在携程内部却很少有团队应用，其根本原因在于其难以与携程的CRN框架结合使用。CRN是适用于携程APP业务开发的React Native框架，在携程系APP上有极为广泛的应用。CRN会在构建过程中，进行一些针对携程业务的分包、混淆、引入公共包等优化策略。这一点与Taro-RN那种直接打出bundle包的方案难以融合。
MySQL在业界流行多年，很好地支撑了携程的业务发展。但随着技术多元化及业务的不断发展，MySQL也遇到了新的挑战，主要体现在：业务数据模型呈现多元化，OLTP和OLAP出现融合的趋势；在MySQL数据库上慢查询治理成本高；使用传统的分库分表方案对开发不友好，核心数据库改造成分库分表方案，时间一般以年为单位。 分布式数据库能比较好地解决上述问题，同时也带来了新的挑战。2021年，OceanBase（简称OB）开源，携程开始逐步探索OceanBase的基本特性和应用场景。OceanBase兼容大部分MySQL的功能和语法，同时提供水平扩展性、强一致性和高可用性，能满足业务需求并降低运维成本。因此，我们开始推进部分MySQL实例迁移到OB。为保证迁移顺畅，我们设计了迁移评估工具、OB迁移流程、OB监控大盘和OB故障诊断工具等。并将迁移过程中遇到的问题和大家进行分享。
携程微服务产品起步于2013年。最初，公司基于开源项目ServiceStack进行二次开发，推出.Net平台下的微服务框架CServiceStack。 2014年，公司推出Java平台下同CServiceStack完全互通的自研微服务框架Baiji和第一代服务注册中心。该服务注册中心后续经历多次重构，目前使用的已是第四代产品。 2017年,公司正式引进开源产品Dubbo，推出整合携程治理能力的CDubbo框架。该框架最初基于Dubbo 2.5.4版本进行二次开发，经历多次版本升级后，目前使用Dubbo 2.7.7版本。 2020年,公司正式开始探索落地Service Mesh项目。目前，相关产品已经在生产环节正式落地，正在进行接入推广工作。
