剖析多利熊业务如何基于分布式架构实践稳定性建设

作者 | 百度小程序团队

导读

多利熊稳定性建设，是指为了确保系统或服务，在生产环境中的稳定性而采取的一系列措施和优化。这包括但不限于监控、预警、容错、自动化、规范、质量等方面的优化。通过稳定性建设，可以提高系统的可靠性和可用性，从而为用户提供更好的使用体验和服务质量。

全文4159字，预计阅读时间11分钟。

01 业务介绍

多利熊是百度旗下的本地生活服务平台，是针对本地生活行业的SaaS解决方案，利用中心化+去中心化分销渠道，帮助商家在百度内外广泛获客及持续经营，帮助用户发现所在地的商户，并给用户提供特色又优惠的吃喝玩乐商品服务。

多利熊生活服务平台，包含以下三个主要产品形态：

多利熊商家平台：主要是面向商家提供服务，是商家管理门店、核销订单、处理售后、资金提现的经营平台；包括PC后台、小程序、APP双端（多利熊掌柜）

多利熊运营平台：面向内部运转，用于商户审核、商品审核、套餐撰文等事务管理；包括PC后台、APP双端（熊管家）

多利熊用户平台：面向C端用户和达人，提供多利熊百度小程序、多利熊微信小程序、多利熊APP等

多利熊业务挑战，随着技术角色分工越来越细、技术专业化程度越来越深，分布式系统的架构特性为其稳定性建设中的架构设计、组织设计等带来了新的挑战。

• 随着模块微服务(用户、商品、订单、商家、券码、支付…)数量激增，如何保障架构健壮可拓展。

• 依赖内部服务多，调用链路长，如何保障服务性能以及稳定性。

• 依赖外部服务多(交易、营销、三方Saas…)，如何保证数据最终一致性。

• 迭代周期短，节奏快，如何平衡开发重构节奏，保障架构良性迭代。

02 建设理念

多利熊业务复杂性，对产品整体的稳定性质量建设，带来了巨大的挑战，实际建设过程中主要从技术规范、业务规范、微服务三个方面落地实践，具体如下：

多利熊稳定性建设，示意图：

03 实施过程

从开发到上线，如何保证稳定性？以多利熊业务稳定性建设落地实践介绍，主要从以下几个阶段：方案设计、技术评审、开发、CR、提测、上线、问题处理、Case沉淀 实施落地，具体内容如下图：

3.1 方案设计

方案设计旨在梳理需求背景，了解业务，确保需求合理性，可行性。方案设计带来的好处：

• 梳理需求背景，了解业务，确定需要做的事情，确保需求合理性，可行性。

• 跨团队、跨部门需求，需要达成一致性认知，对齐需求上下文。

• 详设可以有效纰漏潜在的风险；评估开发工作量，保证项目进度。

• 沉淀开发文档，保证项目开发文档详细准确，保证产品的项目开发文档的持续性，技术方案良构。

方案设计要包含内容如下：

方案版本：版本号、编写时间、变更内容、修改人等信息

开发文档：需求文档、需求 icafe(feature) 地址、prd地址、依赖文档地址、需求负责人，便于后续查询

项目背景：对项目功能进列举说明，项目背景梳理明白为什么我们要做这个项目、要实现什么功能

技术方案：技术架构、流程设计、模块交互、功能设计，需要将产品需求转变为技术实现的过程表达清楚

接口设计：提供的接口命名、参数定义(类型 大小限制 长度限制 是否必填 备注…)、响应结果、接口信息(描述信息 创建人 负责人…)等协议信息，解决前后端接口文档与实际情况不一致，随着时间推移，版本迭代，接口文档往往很容易就跟不上代码了等问题

存储设计：涉及库表、字段变更，必须考虑是否涉及上下游同步、数据兼容、表情符号、字段长度等

兼容性：数据兼容，新增字段或者上线前后修改逻辑不一致等；接口兼容，考虑接口升级，是否兼容；上线顺序兼容，考虑前后端上线顺序以及依赖关系，等其他需要考虑的兼容场景

监控告警：执行失败、异常场景监控告警。异常分支逻辑、运行时异常逻辑、关键路径逻辑「支付、注册等」

上线：上线前输出上线文档，包括资源、配置、授权、上下游依赖、上线顺序等等

3.2 技术评审

目的：技术文档沉淀以及技术文档持续性，同时保证技术方案良构。

目标：组件技术方案评审小组，输出技术方案评审标准(方案设计、评审内容、方案回顾)。

技术评审主要职责：

• 指定评审内容，收集技术方案文档，指定参与评审人员(值班)，发起评审会邀

• 输出准入规则，主要从竞品调研、架构、接口协议、性能、库表、核心流程可用性等方面，输出准入规约

• 方案周期回顾，定期组织技术方案 Review(值班)，进行技术方案合理性分析回顾，保障架构良构

3.3 编码现约

编码规范愿景是提效，保证代码质量，提升团队的协作效率，降低沟通成本。开发规约主要包含，编码规约、安全规约、Mysql规约、日志规约、异常规约等。开发规约目标：

• 保证代码质量

• 开发提效

• 提升团队的协作效率

• 降低沟通成本

• 提升线上服务稳定性

• 保障项目健康快速迭代

3.4 CodeReview

Code Review在保障代码质量准入重要一环，CR 的主要职责如下：

• 提前发现由于业务理解偏差、逻辑错误等带来的质量隐患，从而减少线上问题和异常case

• 编码风格的统一规范、设计的合理性、代码的健壮性等多方面

• CR标准指导，从硬编码、嵌套层级、日志、常量、方法定义、SQL使用、配置文件等方面对评审的标准进行了总结沉淀

基于多利熊业务，我们也逐步落实和完善了一套CR流程实践，流程如下：

• 开发提交CR，开发自测完成之后发起，需经同模块内小组同学和负责人分别评审，评审人给出评审意见和打分。

• 集中式CR，涉及到多个模块联动的，以需求为单位，在上线前发起，此环节是上线前质量把控很重要的一个环节，可以发现模块间由于理解偏差导致的依赖使用问题或逻辑问题。

3.5 操作上线

上线内容，需要周知模块负责人，通过上线方案评审，完成上线内容登记，上线通告后，进行上线操作。

• 上线窗口，对上线窗口没有严格限制，周五原则上尽量不上线

• 上线前准备，完成上线方案设计并通过评审，涉及不兼容、或者风险较高上线，周知 PM 确认是否需要发上线通告，上线通知模板如下：

• 预览上线，先上线预览环境，观察服务是否符合预期

• 操作上线，保障无损上线，上线顺序如下

• 单边单台，停留 10 分钟，观察服务是否符合预期（验证改动功能符合预期），出现问题第一时间回滚，止损

• 单边，全量

• 上线后，线上回归测试（对于线上没有覆盖到的回归场景，必须周知相应 PM&QA 同学，纰漏风险），完成监控告警添加以及确认，持续关注监控以及上线业务及数据是否符合预期

3.6 问题处理

问题处理原则：先通告，止损，再排查问题，线上问题优先跟进处理，最短时间上线修复。

问题上线原则：线上 bugfix 分支，不与业务上线混合上线，应独立上线，避免回滚风险：

• PM/QA/RD谁先发现问题，第一时间反馈，同时记录 icafe 跟进

• 跟进原则，问题定位前：谁先报出问题，谁负责推动定位问题，问题定位后：相应问题负责人跟进

• 通告模板

• 【问题通报】问题描述

  【问题描述】x年x月x日，因xx原因导致xx问题现象

  【当前进展】xxx

  【问题影响】待统计

  【问题原因】待确定

04 实战

基于多利熊业务，我们也逐步落实和完善了一套稳定性建设流程实践闭环。

4.1 稳定性闭环

稳定性建设各个环节交互如下：

4.2 最终一致性

多利熊业务内外部依赖服务较多，为了保障性能以及服务稳定性，最终采用方案如下：

• 异步调用，保障服务性能，同时引入异常情况下，数据不一致问题

• 最终一致性，通用解决方案有 本地消息表、外部消息表、Seata等。多利熊选则了 本地消息表方案，实现最终一致性，解决异步调用数据不一致问题

多利熊业务业务调用，最终一致性实现流程如下：

4.3 重试幂等

幂等介绍：多次调用不会改变业务状态，多次调用获得相同结果，对于请求的某一个资源应该具有同样的副作用。

对于 Http 请求，会有三个状态：成功，失败，或者超时。成功、失败是明确业务是很好处理的，超时是未知的，超时可能是网络传输丢包，也可能是请求超时，还有可能是返回结果超时。这时候我们是否可以重试呢？

幂等和防重

防重，主要为了避免产生重复数据或者脏数据，对返回没有太多要求。主要有，前端重复点击，网络重试等等

幂等，比防重要求更加严苛，除了避免产生重复数据或者脏数据，还要求每次返回一样的结果

常见幂等问题场景

• 前端重复提交，多次点击，服务端收到多次请求

• 超时重试，调用下游服务或者依赖外部服务处理超时，或者因为网络原因导致超时

• 消息重复消费，使用消息中间件 pulsar、mq 等，重复消息发送，或者 ack 异常重复消费

• 高并发，唯一 ID 生成碰撞，重复写入，边界控制等

多利熊业务幂等设计实现，设计幂等都需要一个 全局唯一的ID，标记独一无二。通常使用 UUID 或者 雪花算法生成全局唯一 ID，多利熊采用的 防重表方式 实现幂等，流程如下：

4.4 监控警告

多利熊业务部署采用 k8s以及云原生prome监控，本节主要介绍，多利熊涉及监控告警技术选型，以及监控告警处理流程实践。

Trace 和 天眼（一站式日志服务平台）区别

天眼，应用于分布式服务的具有日志采集、加工、存储、检索、告警等功能的一站式日志服务平台，为业务团队提供低延迟, 高性能, 高可用的日志服务, 提升业务排障效率与能力

Trace，基于日志处理的全链路一站式查询分析协议，特别对于链路较长业务，可以快速定位到那个业务出现了问题。

监控告警处理流程如图：

多利熊业务监控选型，Trace，天眼，Actuator，Prometheus、Grafana，整体实现效果如下：

4.5 其他

业务成长，周期邀请产品、运营分享业务知识，以及产品交流，生活服务研发做到『快』、『懂业务』和『正影响』。

技术成长，架构师周期分享前言技术，技术培训，定期分析讨论架构，基础服务研发做到『及时性』、『专业性』、『稳定性』和『安全性』。

05 规划

自动化缩容

基于个性能指标或者Prometheus自定义指标来进行扩缩容，满足秒杀、大促等场景。

服务智能化容错

核心业务流程(下单、支付、核销…)降级处理，依赖服务资源(Redis、MQ…)降级处理，保障用户体验。

——END——

推荐阅读：

百度工程师的软件质量与测试随笔

百度APP iOS端包体积50M优化实践(一)总览

基于FFmpeg和Wasm的Web端视频截帧方案

百度研发效能从度量到数字化蜕变之路

百度内容理解推理服务FaaS实战——Punica系统

精准水位在流批一体数据仓库的探索和实践