在 iOS16 上，苹果推出了实时活动( Live Activities )。实时活动可以出现在用户锁屏界面，并可实时展示用户关心的一些核心信息。由于使用远程推送通道更新实时活动不需要主 app 保持开启，并且相比小组件需要用户手动添加到桌面这个门槛，实时活动功能是默认开启的，所以这一机制保证了信息的触达概率会远高于小组件。 笔者认为，实时活动是一种更高级的推送形态，对比传统的推送，实时活动显得灵活许多。传统推动在用户接收并读取到内容的瞬间信息就失效了，如果想要为用户提供持续更新的信息需要依赖一条接一条的推送才可以实现，这无论从成本还是用户体验上，都是难以接受的。而实时活动则会在持续期间，无干扰的保持着信息的更新，并且又会在合适的时机自行消失，因此用户体验极佳。 作为一家在线旅行产品平台，我们一直追求为用户提供极致的用户体验，在今年的上半年，我们上线了基于实时活动开发的实时出行信息展示功能，用户可以在出行全周期内，通过锁屏或者灵动岛看到最新实时的出行信息。
随着业务日益复杂，应用微服务化已成为主流趋势，业务领域通常在多个微服务应用中实现。DevOps 工程从应用角度，虽实现了应用流水线和项目流水线，但也面临着测试阶段管理多套应用流水线的复杂场景。通常情况下，这些业务会存在多套互相隔离的环境，而这些环境的构建也依赖人工处理资源申请和部署。由于构建不易，这些环境通常被长期反复使用，并需要定期与生产环境同步以确保开发和测试的有效准确。这些工作要求工程师对业务的应用架构熟悉且有时间频繁进行操作，但实际上这些工作大多落在项目资深的 DEV 或 QA 身上，浪费了宝贵的人力资源。因此，我们可以考虑建立“环境构建平台”，实现环境即用即建，让 DEV 和 QA 专注于自己擅长的事情，并最终节约人力资源提升效率。Qunar 的基础平台团队对此问题进行了长期实践，本文将分享 Qunar 在测试环境治理领域的实践经验和思考。
随着去哪儿网业务的发展和微服务架构的普及，公司内微服务的拆分粒度越来越细，导致服务间的调用错综复杂。比如机票和酒店的下单场景，就会涉及到成百上千个应用的调用，而当此类场景出现异常产生报警甚至产生故障时，对开学同学来说查找并定位问题是个很大的挑战。 去哪儿网构建了自己的 APM 系统，包括监控(metric)、日志(logging)和调用链路(Tracing)，帮助开发同学定位问题。但在实际排查问题的过程中，开发同学需要排查是报警的应用本身还是下游依赖的问题，需要逐层去排查调用链路、异常日志、监控指标等，这样就会导致有时定位问题的时间比较长。而对于影响业务的故障而言，导致的后果便是恢复时间较长，造成的损失较大。
对于去哪儿平台而言，酒店业务主要是通过整合不同货源，对客提供优质低价酒店。而我们本次提到的 SPA 系统（全称 supplier-product-adapter，中文全称为供应商产品报价适配系统），负责接入供应商的酒店信息以及报价信息，为上层应用提供了统一格式的报价数据。其在酒店业务定位中处于一个非常关键的位置。
在线应用的诊断一直是日常维护中的难点和痛点，2018年下半年，Alibaba 开源了 java 应用诊断工具 arthas ，让 java 应用的诊断能力上了一个台阶。作为基础架构团队，我们自然也对它非常感兴趣。研究后发现，arthas 确实是一个非常优秀的 java 诊断工具，但是也存在一些不足。 一是 arthas 更像是一个工具，而不像一个产品。如果要使用它，首先要登录相关机器，然后在机器上下载 arthas，再执行一些命令来运行。这整个流程里，下载可能出现问题，运行 arthas 也需要具有目标进程相应的权限，还需要先看看对应进程id等等...这些确实只是一些小问题，但也可以选择让这些问题不存在，让整个使用过程更加流畅。 二是 arthas 缺少 web 界面。命令行界面用起来确实很酷，但不可否认在相当一部分情况下 web 界面更直观更友好，很多需要查文档的情况在 web 界面下都可以直接操作，降低了使用门槛。 三是 arthas 所有功能都针对单台机器，实际上很多时候我们需要考虑和观察整个应用的运行情况，需要一个应用级的视角。 四是 arthas 是一个独立的工具。
去哪儿发布的数据显示，在过去一年中，其发布故障率始终保持在4‰ 以下并不断降低。作为一家出行旅游服务平台，去哪儿网如何在复杂的业务场景下，仍能保持如此低的故障率？其中功能测试左移功不可没。 本文介绍了去哪儿网通过自动化测试、智能推荐、本地化等平台的建设，在低成本、低故障率、高效率方面的显著成效，并详细介绍了各阶段的实践重难点。
2022年，Qunar 技术中心完成了轰轰烈烈的服务瘦身项目，在各个技术团队的努力下，最终完成了将上千个应用和千万行代码瘦身50%的目标。 在如此艰巨的任务达成目标之后，对于技术团队来讲，接下来的重点就变成了如何维持住这来之不易的成果，如何避免反弹。作为一家处于激烈竞争的互联网公司，Qunar 致力于不断为用户提供低价的产品，同时维持优秀的服务水平和用户体验，业务的演进和系统的迭代在持续不断的进行。随着业务的演进和系统的迭代，原本瘦下来的系统上会有新的代码填充进来，也会有新的应用加入或者拆分出来，这些动作都是会重新增加系统的臃肿程度，如果没有治理手段，会导致我们好不容易取得的瘦身成果慢慢流失。就像一个成功瘦身的人，如果瘦下来之后没有制定和执行合理健康的饮食计划和运动计划，迟早又会回到身体臃肿的状态。 基于此，在瘦身项目推进的同时，Qunar 技术中心启动了系统防腐化治理的项目，目的是在瘦身项目达成目标之后，建立和运用治理手段，防止或者减缓系统不受控制的膨胀，将系统的维护成本维持在较低的水平。这项工作由作者牵头，Qunar 技术中心业务架构 SIG 承接。
Qunar 的实时日志平台使用的是 ELK 架构，其中 Elasticsearch 集群（以下简称：ES 集群）和 kibana 平台在机房 A，Logstash 集群在机房B。 目前机房 A 在使用过程中存在以下一些问题隐患： 机房 A 目前为饱和状态，批量新增机器难以支持 机房 A 主要由 Hadoop、ES 集群组成，业务交互会产生大量跨机房流量，峰值会影响到业务 基于上述因素，与 Ops 同事沟通后，决定整体迁移 ES 集群到机房 B。这样不仅可以解决上述两个问题，和写入端的 Logstash 集群也同在一个机房，网络通信更有保障。 此文主要介绍 ES 集群节点迁移实战过程中的一些实践与探索演进经验，对于日常的平台开发与运维也能有所借鉴和参考。
分库分表是大型互联网应用经常采用的一种数据层优化方案，常见的分库分表中间件如 sharding-jdbc、mycat 都已经比较成熟，基本上可以应对我们一般的分库分表需求。做过分库分表的同学应该知道，在给业务系统做分库分表改造过程中，难的不是如何使用这些组件进行分库分表，而是如何将非分库分表的系统平滑的升级成一个分库分表的系统，升级期间业务不可暂停，升级过程及升级后风险可控，这个过程就像是给飞行中的飞机更换引擎，处理不好会产生重大的业务事故。去哪儿网机票辅营业务就经历过从主从读写分离系统升级到分库分表系统的过程，并在多次迭代过程中形成了一种与业务轻相关的平滑的分库分表方案，后续业务升级分库分表只需通过配置切换就可以将单库单表系统瞬切至分库分表系统。
