多利熊基于分布式架构实践稳定性建设

栏目:成人教育  时间:2023-04-26
手机版

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

  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...)降级处理,保障用户体验。

上一篇:以“美”赋能,毛戈平美妆研发工厂花开杭州
下一篇:2023湖北省院校排名大更新:武汉大学有优势,华中科大稳健前行

最近更新成人教育