剖析多利熊业务如何基于分布式架构实践稳定性建设
GEEK TALK
01
业务介绍
多利熊是百度旗下的本地生活服务平台，是针对本地生活行业的SaaS解决方案，利用中心化+去中心化分销渠道，帮助商家在百度内外广泛获客及持续经营，帮助用户发现所在地的商户，并给用户提供特色又优惠的吃喝玩乐商品服务。
多利熊生活服务平台，包含以下三个主要产品形态：
多利熊商家平台：主要是面向商家提供服务，是商家管理门店、核销订单、处理售后、资金提现的经营平台；包括PC后台、小程序、APP双端（多利熊掌柜）
多利熊运营平台：面向内部运转，用于商户审核、商品审核、套餐撰文等事务管理；包括PC后台、APP双端（熊管家）
多利熊用户平台：面向C端用户和达人，提供多利熊百度小程序、多利熊微信小程序、多利熊APP等
多利熊业务挑战，随着技术角色分工越来越细、技术专业化程度越来越深，分布式系统的架构特性为其稳定性建设中的架构设计、组织设计等带来了新的挑战。
随着模块微服务(用户、商品、订单、商家、券码、支付...)数量激增，如何保障架构健壮可拓展。
依赖内部服务多，调用链路长，如何保障服务性能以及稳定性。
依赖外部服务多(交易、营销、三方Saas...)，如何保证数据最终一致性。
迭代周期短，节奏快，如何平衡开发重构节奏，保障架构良性迭代。
GEEK TALK
02
建设理念
多利熊业务复杂性，对产品整体的稳定性质量建设，带来了巨大的挑战，实际建设过程中主要从技术规范、业务规范、微服务三个方面落地实践，具体如下：
多利熊稳定性建设，示意图：
GEEK TALK
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
【问题影响】待统计
【问题原因】待确定
GEEK TALK
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 其他
业务成长，周期邀请产品、运营分享业务知识，以及产品交流，生活服务研发做到『快』、『懂业务』和『正影响』。
技术成长，架构师周期分享前言技术，技术培训，定期分析讨论架构，基础服务研发做到『及时性』、『专业性』、『稳定性』和『安全性』。
GEEK TALK
05
规划
自动化缩容
基于个性能指标或者Prometheus自定义指标来进行扩缩容，满足秒杀、大促等场景。
服务智能化容错
核心业务流程(下单、支付、核销...)降级处理，依赖服务资源(Redis、MQ...)降级处理，保障用户体验。
END