我们都是架构师！
关注架构师(JiaGouX)，添加“星标”
获取每天技术干货，一起成为牛逼架构师
技术群请加若飞：1321113940 进架构师群
投稿、合作、版权等邮箱：admin@137x.com
本地生活服务平台基于分布式架构实践
多利熊稳定性建设，是指为了确保系统或服务，在生产环境中的稳定性而采取的一系列措施和优化。这包括但不限于监控、预警、容错、自动化、规范、质量等方面的优化。通过稳定性建设，可以提高系统的可靠性和可用性，从而为用户提供更好的使用体验和服务质量。
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 其他
业务成长，周期邀请产品、运营分享业务知识，以及产品交流，生活服务研发做到『快』、『懂业务』和『正影响』。
技术成长，架构师周期分享前言技术，技术培训，定期分析讨论架构，基础服务研发做到『及时性』、『专业性』、『稳定性』和『安全性』。
GEEK TALK
05
规划
自动化缩容
基于个性能指标或者Prometheus自定义指标来进行扩缩容，满足秒杀、大促等场景。
服务智能化容错
核心业务流程(下单、支付、核销...)降级处理，依赖服务资源(Redis、MQ...)降级处理，保障用户体验。
如喜欢本文，请点击右上角，把文章分享到朋友圈
如有想了解学习的技术点，请留言给若飞安排分享
因公众号更改推送规则，请点“在看”并加“星标”第一时间获取精彩技术分享
·END·
相关阅读：
一张图看懂微服务架构路线 基于Spring Cloud的微服务架构分析 微服务等于Spring Cloud？了解微服务架构和框架 如何构建基于 DDD 领域驱动的微服务？ 微服务架构实施原理详解 微服务的简介和技术栈 微服务场景下的数据一致性解决方案 设计一个容错的微服务架构
作者：百度小程序团队
来源：百度Geek说
版权申明：内容来源网络，仅供学习研究，版权归原创者所有。如有侵权烦请告知，我们会立即删除并表示歉意。谢谢!