建筑师（JiaGouX）
我们都是建筑师！
架构未来，你来吗？
多莉熊稳定性建设是指在生产环境中，为了保证系统或服务的稳定性而采取的一系列措施和优化，包括但不限于监控、预警、容错、自动化、标准化、质量等方面的优化，通过稳定性建设可以提高系统的可靠性和可用性，从而为用户提供更好的用户体验和服务质量。
01 业务介绍
多莉熊是百度旗下本地生活服务平台，是针对本地生活行业的SaaS解决方案，通过中心化+去中心化的分销渠道，帮助商家在百度内外获客并持续运营，帮助用户发现本地商家，为用户提供特色鲜明、优惠的吃喝玩乐及产品服务。
多莉熊生活服务平台包含以下三种主要产品形态：
多莉熊商家平台：主要为商家提供服务，是商家管理店铺、核销订单、处理售后、提现的运营平台；包含PC后台、小程序、APP双端（多莉熊掌柜）
多莉熊运营平台：面向内部运营，用于业务审核、产品审核、包写等事务管理；包含PC后台和APP双端（熊管家）
多莉熊用户平台：面向C端用户及专家，提供多莉熊百度小程序、多莉熊微信小程序、多莉熊APP等。
多莉熊业务挑战：随着技术角色分工越来越细、技术专业化程度越来越深，分布式系统的架构特点对其稳定性建设中的架构设计和组织设计带来了新的挑战。
02 建设理念
多莉熊业务的复杂性给产品整体的稳定性和质量带来了巨大的挑战。 在实际的建设过程中，主要从技术规范、业务规范、微服务三个方面进行实践，具体如下：
Dolly Bear稳定性结构，示意图：
03 实施过程
从开发到上线，稳定性如何保障？以多莉熊业务稳定性建设实施实践为例，主要包括方案设计、技术评审、开发、CR、测试、上线、问题处置、案例沉淀实施等阶段。具体内容如下：
3.1 解决方案设计
解决方案设计的目的是理清需求背景，了解业务，保证需求的合理性、可行性。解决方案设计的好处：
方案设计应包括以下内容：
解决方案版本：版本号、编写时间、变更内容、编辑者等。
开发文档：需求文档、需求icafe（feature）地址、prd地址、依赖文档地址、需求负责人，方便后续查询
项目背景：列举并讲解项目功能，梳理项目背景，了解我们为什么要做这个项目，想要实现什么功能
技术方案：技术架构、流程设计、模块交互、功能设计，将产品需求转化为技术实现的过程需要清晰地表达出来
接口设计：提供接口命名、参数定义（类型大小限制、长度限制、是否必填、备注等）、响应结果、接口信息（描述信息、创建者、负责人等）等协议信息，解决前后端接口文档与实际情况不一致的问题，随着时间的推移和版本的迭代，接口文档经常跟不上代码的更新。
存储设计：当涉及到数据库表、字段的变更时，需要考虑是否涉及到上下游同步、数据兼容、表情、字段长度等。
兼容性：数据兼容性，上线前后增加新字段或者改变逻辑等；接口兼容性，考虑接口升级，是否兼容；线上订单兼容性，考虑线上订单以及前后端的依赖关系等需要考虑的兼容性场景
监控报警：执行失败、异常场景监控报警。异常分支逻辑、运行时异常逻辑、关键路径逻辑（支付、注册等）
上线：输出上线前的上线文档，包括资源、配置、授权、上下游依赖、上线顺序等。
3.2 技术评审
目的：积累技术文档，保证技术文档的连续性，同时保证技术方案的良好结构。
目的：组件技术方案评审小组，输出技术方案评审标准（方案设计、评审内容、方案评审）。
技术评审主要职责：
3.3 编码和当前协议
编码标准的愿景是提高效率，保证代码质量，增强团队协作效率，降低沟通成本。开发标准主要包括编码标准、安全标准、MySQL标准、日志标准、异常标准等。开发标准目标：
3.4代码审查
Code Review是保证代码质量的重要环节，CR的主要职责如下：
基于多莉熊业务，我们也逐步推行和完善了一套CR流程实践，流程如下：
3.5 在线操作
拟上线的内容需告知模块负责人、通过上线计划审核、完成上线内容登记、上线公告后进行上线操作。
上线后进行线上回归测试（线上未覆盖的回归场景需告知相应PM&QA同事，避免遗漏风险），完成监控报警的添加与确认，并持续关注监控以及线上业务和数据是否符合预期
3.6 问题解决
问题处理原则：先通知、先止损、后调查问题。线上问题优先跟进处理，最短时间内线上修复。
在线发布问题的原则：在线 Bugfix 分支不应该与业务发布混杂，应该独立发布，以避免回滚风险：
【问题通知】问题描述
【问题描述】x年x月，因xx原因发生xx问题
【目前进度】xxx
【问题影响】待统计
[问题原因] 待定
04 实战
基于多莉熊业务，我们也逐步落地并完善了一套稳定性建设流程实践闭环。
4.1 稳定性闭环
稳定性建设各环节之间的相互作用如下：
4.2 最终一致性
Dolly Bear业务依赖很多内外部服务，为了保证性能和服务稳定性，最终的解决方案如下：
Dolly Bear服务调用实现最终一致性的流程如下：
4.3 重试幂等性
幂等性：多次调用不会改变业务状态，多次调用得到的结果是一样的，对某个请求的资源应该产生相同的副作用。
对于HTTP请求来说，有三种状态：成功、失败、超时。成功失败比较明确，容易处理，而超时是未知的。超时可能是网络传输丢包、请求超时、返回结果超时等原因造成的。这时候可以重试吗？
幂等性和防重复
防重复主要是避免出现重复数据或者脏数据，对返回没有太多的要求，主要包括前端重复点击，网络重试等。
幂等性比防重复的要求更加严格，除了避免出现重复或者脏数据之外，还要求每次都返回相同的结果。
常见的幂等性问题场景
Dolly Bear 服务幂等性设计与实现。设计幂等性需要全局唯一 ID 来标记唯一性。通常使用 UUID 或雪花算法生成全局唯一 ID。Dolly Bear 使用防重表方法实现幂等性。流程如下：
4.4 监测警告
Dolly Bear业务部署采用了k8s和云原生的prome监控，本节主要介绍Dolly Bear涉及的监控与报警技术的选型，以及监控与报警处理流程的实践。
Trace与天眼（一站式日志服务平台）的区别
天眼是面向分布式服务的一站式日志服务平台，具备日志采集、处理、存储、检索、报警等功能，为业务团队提供低延迟、高性能、高可用的日志服务，提升业务排查效率和能力。
Trace是基于日志处理的全链路一站式查询分析协议，可以快速定位出问题的业务，尤其适合长链接的业务。
监控报警处理流程如下：
Dolly Bear业务监控的选型包括Trace、SkyEye、Actuator、Prometheus、Grafana，整体实施效果如下：
4.5 其他
随着业务的增长，我们定期邀请产品和运营人员进行业务知识分享、产品理念交流，让生活服务的研发能够“快”起来、“懂业务”起来、“产生积极影响”。
技术成长，架构师定期进行前沿技术分享、技术培训，定期进行架构分析讨论，基础服务开发做到“时效性”、“专业性”、“稳定性”、“安全性”。
极客对话
05
规划
自动缩放
根据单项性能指标或者Prometheus自定义指标进行扩缩容，满足秒杀、大促等场景。
智能容错服务
将核心业务流程（下单，支付，核销...）降级，依赖的服务资源（Redis，MQ...）也降级，保证用户体验。
如果你喜欢这篇文章，请点击右上角分享给你的朋友。
如果想了解更多技术点，请给若飞留言，安排分享
由于公众号推送规则变更，请点击“阅读”并加“Star”，以便第一时间获取精彩的技术分享。
·结尾·
相关阅读：