写点什么

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

作者:百度Geek说
  • 2023-04-18
    上海
  • 本文字数:3950 字

    阅读完需:约 13 分钟

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

作者 | 百度小程序团队


导读

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


全文 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系统


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

发布于: 刚刚阅读数: 4
用户头像

百度Geek说

关注

百度官方技术账号 2021-01-22 加入

关注我们,带你了解更多百度技术干货。

评论

发布
暂无评论
剖析多利熊业务如何基于分布式架构实践稳定性建设_分布式_百度Geek说_InfoQ写作社区