从0-1如果提升质量保障体系（上）
前言有赞搜索中台的前身是ES中间件，并没有一个中台的概念，相应的就会有一个问题，业务接入搜索场景的时候还需要为此投入开发资源同步搜索设计，一个需求上线往往耗时很久，重复性工作较多，所以就有了后来的搜索中台的成立，将搜索完整链路的复杂性折叠成一个简单完整的搜索产品，让业务方直击搜索需求，无需费心搜索实现；在此前提下，如何针对搜索中台进行一个从0到1的完整的质量保障也是一个挑战，且中台面临的问题可能跟传统业务面临的不大一样，保障手段也需要更多样化。
一、搜索质量面临的问题及痛点
目前搜索业务架构如下图所示，笼统的说可以分两层，最上面一层协同网络效应层，也就是服务业务层，包括商品、交易、会员、营销、资产这几个核心业务场景，还有外围的零售、教育、美业、直播业务，第二层折叠效应层，将各种底层能力折叠在一起，包括索引写，索引读，索引管理，集群管理，其中集群管理包括双机房同步、索引重建、重载、监控等，依赖的组件不限于ES，还有Hbase、DTS、Flink、DP等；
针对服务应用层、底层能力支撑层都面临着不同的问题，概括的分为三个部分，分别是影响面评估不准、流程规范为零、稳定性较差：
痛点1：影响面评估不准
服务业务层面临的最大的问题就是业务场景评估，目前有赞搜索业务几乎包含B端C端大部分核心业务，读场景占比量更大，例如B端商品管理页面、订单管理页面、会员业务搜索等，这时候就会遇到一个问题，如果ES进行了升级或者底层做了改造，怎样才能保障上游各个业务场景都没有问题，怎样保障回归用例完全覆盖，避免引发业务线上故障，是搜索中台核心要考虑的问题。
痛点2：底层稳定性较差
这块问题主要集中在底层集群，ES集群抖动会直接影响上游业务，在搜索前期不仅缺少一系列的监控报警，双机房切换也是纯手工一行一行操作，除此之外搜索涉及到的技术栈不止ES组件，还涉及到Hbase、Flink、DTS、NSQ等等，期间任何一个组件出现问题都会导致搜索读写异常，线上出现任何波动我们除了重启只能坐以待毙，需要整理出一套见招拆招的紧急预案； 除了集群自身的问题，业务方的正确使用也是一个关键点，例如大in操作或者数组oversize这些如何避免，慢查query如何及时检测优化等等。
痛点3：流程规范为零
有赞搜索中台刚开始是以ES中间件为基础一步步搭建起来的，流程规范为零，一条业务线从搭建初始到后面能够正常运转，中间少不了开发跟测试同学之间做好的各种约定，且双方能够很好的执行这些约定才能保障这条业务线的稳定性，搜索中台的业务迭代很复杂，除了一些项目支持、日常支持之外，还会有比较多的压测需求、索引迁移、集群切换等等，针对每个模块都需要制定相应的规范及约定。
为了解决上述痛点，搜索中台质量侧从如下几个方面进行落地实践：
二、多方位保障手段
1 基线用例集补齐
为了保证用例集尽可能的覆盖业务场景，搜索中台的持续集成包括三个部分：流量回放+小流量场景补全（ci集成用例）+场景用例执行集；
流量回放：目前搜索主要接流量回放的场景都是读场景，经评估搜索读应用可接入应用12个已接入12个，涉及读接口35个，每个读接口对应的场景都配置相应标签识别，整体可覆盖读场景80%以上，但是流量回放有个弊端，能覆盖80%的场景，剩余的20%的场景因流量太小可能采集不到，这样就需要额外的集成用例补充以保证用例集的完整；
CI集成用例：我们单独搭建了搜索测试工程：bit-search-platform，用以补充剩下的小流量场景用例及异常用例，包括业务层的ic-search和showcase-render，底层的es-proxy及console等等；
场景用例执行集：以上两种都是针对应用级别的用例，但是如果支持项目的话，需要单独的用例执行集，方便开发自测和测试回归，我们针对几个大模块在接口测试平台补充了相应的核心场景执行集，例如：C端商品搜索、B端商品搜索、搜索BOS场景等。
2 业务及集群稳定性实践
原架构中底层es-proxy承接整个公司的读写流量，不同业务公用一套应用难免就会相互影响，例如商品业务这边有大量读操作过来了，走到proxy会把线程池占满，请求会大量堆积在线程队列里无法处理，从而影响其他业务线。此问题是线上偶发问题，在测试环境和压测中会被放大，测试抛出风险推开发出优化方案。优化方案最终采取dubbo分组隔离的方式进行业务隔离，如下图：商品业务线走ic分组、交易业务线走trade分组，这样的话大流量的C端商品读并不会影响到交易订单搜索了，实现了业务单元的影响隔离；本次的架构升级给后续的整个搜索业务和集群的稳定性做了不少贡献。
接下来会从三个方面具体介绍搜索稳定性保障：性能专项、演练预案、监控治理：
2.1 性能专项测试
目前搜索业务的性能需求主要分以下三点：
业务域如交易域和商品域核心索引搜索场景基线SLA支持及es底层线上单链路摸高；
各业务方对ES千奇百怪的使用方式引发的超时reject等进行压测比对（nested嵌套、multi_search、agg等）；
ES版本升级时，官方提供的专门针对ES集群的压测工具，通过搭建集群环境及不同类型数据的准备,对ES单datanode和多datanode进行压测比对,得出集群整体基线SLA；
压测过程中共发现性能问题粗略计算下来26个，主要集中在强弱依赖，这就涉及到强依赖如何进行兜底、弱依赖如何降级的问题；
下面统计了一下从2019年中开始到目前为止通过性能压测手段间接推进落地的一些措施，核心在限流降级：
页:
[1]
