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 都已经比较成熟，基本上可以应对我们一般的分库分表需求。做过分库分表的同学应该知道，在给业务系统做分库分表改造过程中，难的不是如何使用这些组件进行分库分表，而是如何将非分库分表的系统平滑的升级成一个分库分表的系统，升级期间业务不可暂停，升级过程及升级后风险可控，这个过程就像是给飞行中的飞机更换引擎，处理不好会产生重大的业务事故。去哪儿网机票辅营业务就经历过从主从读写分离系统升级到分库分表系统的过程，并在多次迭代过程中形成了一种与业务轻相关的平滑的分库分表方案，后续业务升级分库分表只需通过配置切换就可以将单库单表系统瞬切至分库分表系统。
Qunar 大前端团队一直致力于提升 App 页面的用户体验，基于前端技术手段，提高页面的流畅度和稳定性。 国内酒店作为 Qunar 的核心业务，需要时刻关注、提升预订主流程各个页面的性能指标和用户体验。近期我们使用非关键模块延迟加载、Bundle 预加载、接口提速等方案提升核心页面的流畅度，均得到了很好的效果，但是酒店详情页还未实现页面秒开的目标，需要继续提升。 酒店详情页的功能是展示酒店的基础信息、房型报价，是为用户提供预订酒店下单服务的重要入口，而 TTI 是衡量页面秒开的重要标准。 本文从现状、优化空间、具体方案设计及优化效果等方面来讲解我们对提升酒店详情页 TTI 的思考和动作，希望能给读者一些启发。
目前开源的监控系统越来越多，不同的系统针对的侧重点和特性也不同，像 Zabbix/Nagios 这种老牌的监控系统侧重于主机系统层监控和告警，比如 Zabbix 和 Nagios 都自带有一套完善的系统层面监控插件，而且还允许运维很方便的利用 Shell 脚本或任何其他脚本语言来扩展自己想要的插件，同时 Zabbix 还提供了比较便利的 Discovery 功能，创建一套模板后，便能自动发现和检测相应主机状态，省掉了繁琐的配置过程。而 Graphite/Prometheus 这样的则更兼顾业务应用层监控，它们提供了一套机制，应用可以在代码里记录自己在运行时的状态数据，然后通过 Exporter 或者 Push 的方式将状态数据暴露或推送到 Server 端，Server 存储在时序 DB 中用于之后的分析、查看和告警等。 很多企业在用开源软件的一个路径大概都是这样的，纯开源使用 → 少量的定制化开发或外层封装 → 深度的二次开发 → 自研。
随着业务发展和微服务架构的普及，企业内微服务拆分粒度越来越细，服务间调用关系错综复杂。对于一些复杂的，比如机票和酒店售卖业务场景，可能动辄涉及上百个应用，当某个系统发生异常时会导致多个服务受到影响。此时 APM 系统就派上了用场，监控（Metrics）、调用链（Tracing）、日志（Logging）帮助业务同学快速定位问题。普通的业务监控报警能起到快速发现问题的作用，但具体case的排查还需要研发人员通过异常栈信息来分析，比如数据库连接异常、空指针等等。 去哪儿网很早就有了监控系统 Watcher，能够起到快速提醒业务响应异常的作用，然后开发同学排查是接到报警的系统本身的问题还是下游依赖的系统的问题，如果是下游系统的问题，就要这样一层层地找下去，有时候定位问题时间会比较长。当某个系统出现问题时最根本的表现就是产生异常，如果能直接提示开发同学系统产生了新的异常，或者异常量上涨了，就能够大大缩短开发同学排查问题的时间，做到快速恢复故障。
在移动互联网时代，良好的用户体验至关重要，但如何量化其对业务的贡献一直是痛点和难点。毋庸置疑，体验是必须要持续推进的事情，产品、交互以及开发同学也投入很大精力去进行体验优化，但是相关的ROI(投入产出比)无法快速量化。在大多数情况下，只能通过录屏、纯技术指标(FPS/FCP/TTI等)来表现技术优化对用户体验的数据提升，但这表征不了整体用户体验的状态，更无法量化体验优化所产生的业务价值。 通过调研发现，关于用户体验的度量标准有各种各样的规范和模型，较为典型的有下表中的 Google Pulse、Google Heart、支付宝 PTECH、阿里云 UES，其中有满意度、任务效率、体验性能、易用性、收益、留存率、参与度、接受度、与一致性等关键项，其中前三项是较为普遍的共识。
近来，Qunar 酒店的整体技术架构在基于 DDD 指导思想下，一直在进行调整。其中最主要的一个调整就是包含核心领域的团队交出各自的“应用层”，统一交给下游网关团队，组成统一的应用层。这种由多个网关合并成大前台(酒店业务网关)的融合，带来的好处是核心系统边界清晰了，但是对酒店业务网关来说，也带来了不小的困扰，系统面临的压力主要来自两方面：首先，一次性新增了几十万行大量硬编码、临时兼容、聚合业务规则的复杂代码且代码风格迥异，有些甚至是跨语言的代码迁移。其次，后续的复杂多变的应用层业务需求，之前分散在各个子网关中，现在在源源不断地汇总叠加到酒店业务网关。这就导致了一系列的问题
