上的能力~√1两种不同分页模式题目：解析视频：√2

2022年，Qunar技术沙龙继续秉持开放共享的交流原则，将公司的优秀技术实践输出为文字，通过文章与全行业工程师进行交流。今年，Qunar共为大家推送了三十余篇高价值含量的技术文章，最终受到数万名读者朋友的关注与认可。今天，小编为大家将全年文章进行分类汇总，期待可以对读者朋友们有所启发。【温馨提示】：点击标题即可阅读呦~大前端去哪儿网用户体验之端上优化实践作者：何宁凯&任佳&崔宇概要："快"是大多数体验优化的第一个目标。用户体验数字化平台落地作者：

作者介绍：何宁凯，公共前端体验优化负责人崔宇，机票主流程体验优化负责人任佳，国内酒店体验优化负责人一、背景去哪儿旅行APP作为我们用户流量的主要入口，其运行性能和用户体验的好坏，直接影响着用户操作的费力度，最终可能影响收益。因此我们一直很关注

作者介绍：魏子翔，2017年7月加入去哪儿网，主要负责Android原生和跨端框架方向的研发和维护，期间主导了客户端架构升级、稳定性提升、性能优化等多个重点项目，近期专注于用户体验优化治理相关事务。一、背景介绍（一）关于我们我们先看下网上对数字化平台的解释，是指由人员、流程和工具组成的定制化平台，即服务产品，使团队能够快速开发、迭代大规模运营的数字化服务。再来介绍下去哪儿网的业务，去哪儿网是一个典型的在线旅游平台，它上面的业务繁多，有机票、酒店、度假、火车票、汽车票等，细分业务线多达近40个，业务功能更新迭代快、同时伴随着产品开发人员更替、多技术栈混合使用，产品逻辑复杂多变。（二）为什么做体验平台那么我们为什么要开发用户体验数字化平台，其实有以下几个方面的原因：第一个是不同业务线对于相同指标口径和采集方式不一致，拿页面可交互时间指标来说，口径上有从页面跳转或者从页面创建开始采集的，采集方式上有使用插桩来也有手动埋点实现的。这样来看会比较混乱，不同的业务线也没办法横向对比，通过用户体验平台，在框架层面确定一致的采集方案，并统一指标采集口径。第二个是对体验维度的关注侧重点不同，比如有的业务线更关注应用的稳定性，有的业务更关注应用的流畅度，通过平台可以补齐各业务线的差异，确定不同指标的优先级，梳理出统一的用户体验度量模型。第三个也是最重要的是，客户端作为业务的主要入口，其所提供的用户体验是非常重要的。虽然我们一直都在致力于提升用户体验，但是我们缺少系统化的定量评价的手段，清楚的说明我们的用户体验当前处于状态和水平。通过该平台可以创建一个有效的机制，让我们对用户体验有量化认知，同时也让我们的日常治理活动可观测，更好的适应不断变化的环境，建立可持续的技术和运营基础。二、体验度量模型既然已经知道了构建用户体验平台的原因，那么重要的就是我们的体验度量模型，其中会包括我们的评测维度，评分标准以及如何对数据进行度量分析等。（一）模型接下来介绍下我们的用户体验度量模型：通过上述模型我们可以看出，主要是对流畅度、稳定性、能耗、磁盘占用和用户反馈五个方面进行评测，对用户使用应用相关的数据进行采集。如图中所示每个指标有P1

作者介绍：王坤，2020年加入去哪儿网，高级系统运维工程师、去哪儿云原生SIG、基础设施SIG成员，目前主要负责Kubernetes、容器指标监控等系统的运维和云原生相关工作。一、概述在云原生的体系下，面对高弹性、拆分微服务以及应用动态生命周期等特点，传统监控体系如

以内。通过数据缓存层，我们成功使得函数的调度响应平稳下来，实现了数据接收和缓存配置的可拓展性，减少了因缓存未命中的时间波动。数据缓存层通过定时任务主动触发缓存数据的更新，未来还会加入由

文件时，我们拿到了所有布局的嵌套关系，根据这个栈和我们拥有的嵌套关系去遍历，去匹配是否有布局嵌套，如果有就替换如果没有则进行下一次匹配。通过这种方式我们来解决嵌套布局的问题。Scss文件scss

作者介绍：李智勇2019年4月加入去哪儿旅行，在带领团队负责低代码平台的建设与落地工作中，成功赋能了企业中后台系统研发提效，成功接入中后台系统60+其中包含多个代码量级在50W行以上的系统，页面600+。目前技术上聚焦于组件化低代码平台建设，Serverless平台建设，跨端渲染、架构设计、服务可用性提升及运维，具备大型服务的落地实践经验。一、前言本文从团队所面临的背景出发，引出方案思考和选择，并阐述

语言的数据库自动化开发。一、背景新一代去哪儿数据库自动化平台设计整体架构如下：架构说明：【1】平台是分层构建，不同层级的模块功能专注不同的功能，上图只是列出部分模块。【2】Server

作者介绍余辉5年一线项目开发经验，2019年加入去哪儿网，深耕于去哪儿机票底层数据系统，擅长高并发系统的设计及开发。一、背景我所负责的机票运价系统是去哪儿机票底层最核心的价格计算和存储引擎，其提供的基础航班运价数据供去哪儿机票几乎所有业务系统使用，提供接口调用QPS

作者介绍：李全党2021年6月入职去哪儿网，酒店供应链高级技术经理、业务架构SIG成员、公司级内训师，目前负责酒店基础信息业务。主导搭建并落地多个DDD项目，并对高并发、分布式服务高可用，有建设优化经验，2021年落地公司“大主站+微服务”战略，并获得公司“金项奖”技术类三等奖，曾在QCon+做过技术分享。一、案例简述随着集团战略方向调整与业务重组，酒店供应链也面临全新的调整。酒店基础数据业务系统是从国际团队接手，属于10年前系统架构，涉及20多个微服务，架构老旧、系统耦合严重及业务边界模糊，加上业务的快速发展，导致系统灵活性不足及无法快速承接产品需求，产研合作出现效率问题。因此，酒店供应链技术侧结合酒店BU及公司相关成功案例，在2022年初主动发起基于DDD思想的技术架构调整，完整落地战略、战术设计及系统实现，本次重点介绍重构落地过程、设计原则及总结，另外阅读本文需要对DDD的基本概念及流程有一定基础，基本概念可以参考往期技术沙龙（链接见文末）。二、问题分析（一）业务需求复杂酒店基础信息业务系统最初是为去哪儿独立业务设计，主要包括酒店聚合、房型聚合、图片及城市等相关信息（见下图），最初业务划分比较清晰。2015年携程战略收购去哪儿网后，业务战略也随之发生变化，但当时并未对系统进行隔离和重构，随着需求迭代的不断演化，业务逻辑变得越来越复杂，加上产品经理的流动性较大，酒店基础数据PM、DEV、QA团队缺少业务专家，大家对于原始需求缺少理解，部分业务不确定能否下线等等。（二）系统过度耦合酒店基础数据涉及微服务20多个，系统之间耦合严重，模块彼此关联，我们的系统越来越冗杂。有时修改一个很小的产品需求，光回溯该需求涉及需要修改的系统及功能点就需要达到“天”级别，更别提修改带来的不可预知的影响面，无论还是产品、技术需求还是工单问题排查等，都给组内同学带来较高学习成本和开发成本。下图是我们酒店基础信息日常开发中的一个常见的系统耦合案例。这个案列是要完成的业务功能是支持运营人员手工添加酒店图片，当时预估工时时长8pd，实际工时11pd。上图看出从运营开始上传到我们最终将图片外网展示，整体流程涉及到了4个系统。以下这段话是当时开发这个产品需求的同学的“真情告白”：1、需求及系统设计阶段。接到TL的排期并阅读产品PRD，发现涉及4个业务系统，深入系统内部发现业务逻辑复杂及系统耦合严重，熟悉系统及编写设计方案花费3pd；2、系统开发阶段。按照设计进行功能开发发现，除正常多业务系统调用外，业务系统内部存在兜底定时任务，需要进一步熟悉其作用、数据存储及影响范围，花费6pd；3、系统自测阶段。系统自测涉及多个系统间的耦合及不同的数据库版本，自测花费2pd。如果我们的系统经过精心设计，这个案例是不需要8pd，更别说最终上线花费11pd。我们可以看出系统过度耦合，不但降低我们的开发效率，而且对于开发人员不够友好，这种情况对于人员的稳定性也造成很不好的影响，所以我们必须要做出改变。三、为什么选择DDDDDD有很多优势，我们站在EA角度，可以绑定业务架构和系统架构，作为中间层，将问题域与应用架构相剥离；我们站在软件复杂度角度，可以有效解决业务复杂度和软件复杂度问题；还比如DDD可以有效的从业务视角对软件系统进行拆解，是微服务划分最好的实践等等，作为基础数据重构，结合我们上面提到的业务需求复杂和业务过度耦合问题，我们主要从解决软件复杂度和微服务拆分角度考虑，最终选择DDD作为我们项目落地的指导原则。（一）软件复杂度应对Eric

case”。理论上，如果程序代码一样、数据一样的话，一样的操作就能复现一样的结果。在这个基础上，如果用最新开发的代码进行回放，数据一样，操作一样，但是结果不一样，那就可能是两个原因，一个是

CQRS，这个模式其实非常有用，至少我发现很多场景是能够用上它的，换句话说其实只要是数据异构的这种场景，都是比较适合去使用它的，当然这取决于你的查询模式。大家都知道查询模式其实有很多种的，比如说像

型也适合计算型流程。先看一个基本原则：有且仅有。意思是只有必须的流程，不会有多余，它的目的是避免浪费。浪费一定会导致变慢，因此我们应该遵守这一基本原则。常见的两个违反该原则的例子：存在不必要的计算或

）同步策略，当时有两种方案：（1）同步线上配置第一种方案为同步线上配置，这样可以保证测试环境的配置和线上一致性，不再需要手动维护测试环境配置。但从安全的角度出发，这个方案可能带了系统层面的风险，比如

/data/scripts/easybash/pg_dump/logs/202205/20220515/pg_dump_20220515_4_154652_errors.log[2022-05-15

dc(缩容次数)，maxuc(扩容上限次数)，mindc(缩容下限次数)，hpa阈值(hpa配置信息，cpu，内存，自定义指标阈值）,全集群最小副本数，全集群最大副本数。select

作者介绍于海影2014年加入去哪儿旅行，测试开发工程师，负责去哪儿机票服务端测试，21年开始负责混沌工程在去哪儿的推广落地，致力于依托混沌工程进行质量缺口探测和建设。一、前言去哪儿的混沌工程依托

事实上这些过程在接入共享缓存之前业务就有类似的代码，只需要按共享缓存的方式修改一下即可。这一点并不是本方案最大特点，最大的特点是，短时间内多次被缓存对象的多个表的多条数据更新，共享缓存只会触发一条

作者介绍刘鹏飞，2021年4月加入去哪儿网DBA团队，主要负责公司的MySQl的管理和运维，以及数据库的自动化平台开发。具有多年的数据库管理和优化经验。随着业务系统的快速迭代，对应的记录相关数据的表的结构也在快速的变化。但是，对于数据库来说，很多的表结构变更都是要花费很大代价的，如增删字段、更改字段数据类型等操作。更需要注意的是，对于原生的

】当下疫情严重，基本上每个人都或多或少受影响，这时候可以静下心来去思考一下自己需要提升些什么能力。疫情终究会过去的，愿一切美好如初~

区间这个指标都没有打数，那么它会被从缓存中清除。异步清理机制也解耦了指标更新逻辑，不用在每次更新时实时去检测是否有要清理的指标。一旦匹配到规则，立即返回，不继续向下匹配下图是部分示例代码：优化前的

作者介绍林书辉，2018年加入Qunar，大前端开发工程师。目前负责大客户端公共产品首页、用户中心、IM等功能的开发和维护。持续关注学习前沿的大前端技术，推崇技术创新带来的效率优化和性能提升。一、背景在上线动态化

作者介绍——李鑫2014年加入去哪儿网机票目的地事业群担任软件研发工程师，现负责国内酒店交易技术团队涉及订单交易、订单履约、资金结算、预售等相关业务领域迭代扩展和系统架构优化,对高并发、微服务高可用，有建设优化经验专注业务复杂度分离和突破技术复杂性、提升系统弹性之道Qunar技术系列-领域驱动设计优秀讲师本期讲解

作者介绍——李鑫2014年加入去哪儿网机票目的地事业群担任软件研发工程师，现负责国内酒店交易技术团队涉及订单交易、订单履约、资金结算、预售等相关业务领域迭代扩展和系统架构优化,对高并发、微服务高可用，有建设优化经验专注业务复杂度分离和突破技术复杂性、提升系统弹性之道Qunar技术系列-领域驱动设计优秀讲师一、前言一般情况软件设计开发主要分两种：【瀑布式】经过大量的业务分析后，会基于现有需求整理出一个基本模型，再将结果汇总传递给开发人员形成需求文档；我们发现瀑布式研发的方式最大的缺点就是反馈频率低，而且最终交付结果和预期可能产生会较大偏差。【敏捷式】前期同样也需要经过大量的业务分析，但敏捷式的核心重点不是快，简单地来说，敏捷开发并不追求前期完美的设计，而是力求在很短的周期内开发出产品的核心功能，尽早发布出可用的版本，后续不断迭代升级，同时拥抱变化。敏捷式研发的缺点，可能存在大量需求或业务模型变更、最终导致系统维护成本会变大，对开发和系统伸缩性各种要求也比较高。二、DDD

相关的资料，也推荐大家去官网上学习一下官方文档。如果大家有在自己的团队中落地业务架构的想法，希望本文介绍的案例能为大家带来参考。

端资源消耗的初衷相违背，所以我们选择方案二。七、设计1、整体流程整体流程设计如下所示：2、模块划分所有模块的目标：高性能、高可用、高扩展dubaiMeta说明由于基础服务不能提供高性能的

{"roomId":"42764865253","productId":507346697,"lastDate":"20220316","index":"

s通过调整参数，逐步并反复测试，结果如下：maintenance_work_memautovacuum_vacuum_cost_delayvacuum_cost_limitAUTOVACUUM

引申问题看似简单的需求，链路很长，总有团队即使没逻辑修改也要做透传的事情讨论技术方案时，不同团队对某个逻辑谁来实现意见不一致，本质是边界不够清晰3、问题分析一先来看一下主流程核心的交互图：（注：图中

战略设计这里我们总结了做好战略设计阶段的一些必要条件，可以概括为【两个前提】、【一个原则】和【一个方法】，具体为：两个前提：这个主要是对领域专家角色的要求，本质上是为了明确现状并能规划未来。a.

很难做到常态化：就像上面说的，在雪崩之前，并不能预测到当前数据库马上要故障了。就自动启动杀慢查询这个动作，因为数据库是一个动态服务，当前的服务水平，和服务能力，需要综合各种指标来判断，包括

关闭主交换机上连接服务器的接口此操作的目的是为了防止维护过程中服务器bond接口意外切回。提前记录UP的接口信息，在交换机完成重启接口恢复之后进行比对，检查是否有接口没有恢复。2.4

中的某个航班的公布运价发生变化，这个舱位的报价价格就需要更新重算代理商如果调整自己政策的策略，更新了某个航线的价格，同样这个航线代理商的报价也需要及时的更新。所以对报价内部，需要一个系统告知

命令输出结果/mysql_xxxx/data/ib_logfile0[OOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOO]

与逻辑的需求，也是选型的重要依据。页面装配的过程可以由以下伪代码实现：//各子页面适配器代码SessionListComponent.component.dartSessionListState{

备份期间，备份到某个数据库时，该数据库下的表都会处于只读状态，无法对表进行任何变更，直到该库下的表备份完毕，这对于线上环境一般是无法接受的。若是指定了--master-data或者

年年中，我从武汉去了上海，因为达梦在上海有一个新的宏伟目标，即从头写一个数据库-DM7，我有幸见证了这个过程。“从头写”，所言非虚，我加入到开发工作中的时候，已经具备了一个简单的建表功能了，B

在定义数据模型和搜索方式上非常灵活，数据模型可以采用静态数据映射与动态数据映射，搜索方式也支持多维度类型的搜索（结构化数据、非结构化数据、地理位置、指标参数等）。如果对事务性要求不高或者事务性操作在

作者介绍刘鹏飞，2021年4月加入去哪儿网DBA团队，负责公司的MySQL的管理和运维，以及数据库的自动化平台开发。具有多年的数据库管理和优化经验。一、背景去哪儿网数据库监控告警系统前期主要通过Nagios+NRPE插件来实现的。NRPE是Nagios的一个功能插件，可以实现监控主机的CPU负载情况、磁盘使用情况等，通过不同的检测命令实现获取不同的监控指标数据。使用NRPE，需要被监控主机上部署NRPE程序，Nagios上安装check_nrpe插件。具体架构如下图所示。流程说明：Nagios

作者介绍雷孝龙，去哪儿网资深DBA。2019年8月加入去哪儿网，负责公司的MySQL/Redis运维，以及自动化方案的设计与实施。曾就职于达梦数据库、映客直播；擅长于数据库管理、维护及优化等工作。一、背景作为

面对慢查询的海洋时，并不能有效地知道，每个慢查询对业务影响的严重程度，再加上解决慢查询的周期很长，可能针对一个慢查询，从开始到解决完成，需要跟踪半个月都不止，从而造成了慢查询的被动解决，成为

作者介绍李佳奇2014年加入去哪儿网机票事业部，担任Java工程师；曾负责旅行交通技术工作，完成了基于库存的搜索交易系统的全流程打通和改造；现从事机票主系统技术开发工作，致力于完善系统模型，改进开发流程，落地推广优秀技术等；一、背景1.1系统功能Qunar

作者介绍井显生，2019年加入去哪儿，现负责国内机票出票、退款、改签核心业务。在领域驱动设计(DDD)、高并发有大量实践经验。一、前言去哪儿网国内机票售后是为用户提供退票、改签、航班变动、行程服务、疫情政策等服务的业务。业务场景中有复杂的基于订单、客票、

点击蓝字关注我们崔迅2016年加入去哪儿网，负责国内机票报价搜索系统的维护工作，有丰富的搜索系统性能优化经验。现主要负责业务风控业务。背景BEIJING2018-2019

安全通告监控安全运营人员第一时间获取漏洞通告，对漏洞的评估研判、迅速响应和有序推动至关重要。早在19年，安全组借助应届生项目，实现了“安全漏洞智能感知系统”。系统主要功能为：CVE、CNVD

Unsplash文

众所周知，领域驱动设计（DDD）的概念出自Evic

是个很老的知识点，是后端工程师的经典必修课。这种知识具备的特点就是研究的人多，所以研究的趋势就会越来越深。当然分享的人也多，由于分享者水平参差不齐，也产生的大量错误理解。今天我再次分享

id苏州街1,2维亚大厦1维亚1桔子2酒店2大赛1有了倒排索引，能快速、灵活地实现各类搜索需求。整个搜索过程中我们不需要做任何文本的模糊匹配。例如，如果需要在上述两个文档中查询