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

作者 | 百度小程序团队

导读 

多利熊稳定性建设，是指为了确保零碎或服务，在生产环境中的稳定性而采取的一系列措施和优化。这包含但不限于监控、预警、容错、自动化、标准、品质等方面的优化。通过稳定性建设，能够进步零碎的可靠性和可用性，从而为用户提供更好的应用体验和服务质量。

全文 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——

举荐浏览：

百度工程师的软件品质与测试随笔[](http://mp.weixin.qq.com/s?__biz=Mzg5MjU0NTI5OQ==&mid=22475598…)

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

基于 FFmpeg 和 Wasm 的 Web 端视频截帧计划

百度研发效力从度量到数字化变质之路

百度内容了解推理服务 FaaS 实战——Punica 零碎

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