金融级系统海量流量下的高可用架构实践

1. 金融级系统海量流量下的高可用架构实践

2.

3. 开篇

4. 分享的视⻆⻩金链路金融系统电商⻩金链路、全链路、全场景、海量流量业务系统关注度影响范围

5. 分享的原因 02 01 成⻓变化 04 why or how 03 银弹

6. 定义篇

7. 不可用服务器 , 可控机房故障 01 光纤挖断，不可控外部事件 04 不可用 02 03 上线故障 , 内部人为事故 9.11 黑天鹅事件

8. 金融业务不可用表现信息泄露 • 信息盗取：木⻢病毒、假冒网站、数据安全事故 • 信息泄露：身份信息、账号密码泄露信贷欺诈交易欺诈账号盗用 • 身份冒用/非本人申请 • 盗刷 • 账号接管：登录、修改及管 • 身份美化 • 套现理身份、绑卡、窃取信息数 • 恶意逾期/恶意失联 • 盗帐号交易 • 线上业务交易欺诈据、动账转账

9. 不可用是什么已知未知⻛险不可用⻛险不可用是指潜在⻛险在一定条件触发下的结果呈现条件时间人

10. 业内定义 MTTR SLA 服务水平协议 04 03 SLI 平均故障时间 01 02 衡量服务质量的指标 MTBF 平均故障间隔时间

11. 业务视⻆不可用不可用 = L1.E1.D1.T1 + ….. + Ln.En.Dn.Tn • 业务资质 • 资损 • 舆情 • 客诉 • 用户体验 • 业务收入、预期 • P • P • P2 系统级别L 类型E • 核心业务 • 全部接口 • 100% 、80% 、…… 不可用程度D • 小时 • 分钟 • 秒时间T

12. 不可用的特性 PRAT PRAT PRAT 01 02 03 趋势性隐秘性爆发性不可用的等级有随时间及其他外部因素逐步提升的趋势⻛险的触发条件比较隐晦 • 交换机宕机 • 主机上其他应用有定时任务

13. 不可用原因 – 时代 – 业务 VUCA乌卡（易变性、不确定性、复杂性、模糊性）时代业务的现状是我们现在已经从单一的做业务，到业务生态，我们处在一个快速裂变的时代 VUCA 开放式架构企业级架构微服务架构单体架构工具化时代工具化时代信息化时代数字化时代

14. 不可用原因 – 时代 – 基础设施 2009 《 Above the Clouds : A Berkeley View of Cloud Computing 》 2019 《Cloud Programming Simplified: A Berkeley View on Serverless Computing》

15. 不可用原因 – 内因 ◆ 流量 ◆ 变化（时间 … ） ◆ 不可靠 ◆ 耦合 ◆ 系统架构 ◆ 上线

16. 不可用原因 – 成本可用性成本 VS ⻛险成本

17. 不可用原因 – 认知所有降级措施是有效的低优先级系统不需要备战上游已经替我做了保护下游是稳定的所有应急预案是可执行的流量洪峰后系统能快速恢复历史的经验是可靠的系统重试能解决问题

18. 不可用原因 ◆ 高可用涉及所有业务场景、系统各层级、软件开发的全生命周期、组织架构、团队分工，贯穿整个软件开发体系 ◆ 高可用的难点在于对软件的全景认知，对于（新）变化的感知，对于 (历史) ⻛险点的识别，在于事前预估与预案，事中有效处理，事后复盘总结，形成闭环即使付出了99%的努力，也会因为 1%的疏忽，带来意想不到的结果，所以高可用应该是一套需要持续完善和迭代的体系和方法论、需要持续的关注和投入 ◆

19. 结构篇

20. 结构单一结构复合结构复杂结构串联

21. 体系篇

22. 高可用指导思想 • • • 01 02 03 04 系统 -> 业务⻛险 -> 事故架构升级数据驱动追求业务连续性以不可用等级为评判标准追求业务收益与线上⻛险之间的平衡 • • • 减少⻛险点控制⻛险转化为事故有⻛险必有监控，有监控必有预案，有预案必经验证 • 通过架构升级，沉淀标准的业务模型、技术解决方案，降低人为错误几率，提升系统的可用性 • • 通过业务数据形成业务系统⻛险数据模型借助数据模型+AiOps 强化⻛险预警与提前部署预案能力

23. 高可用考虑因素成本 ● 研发成本 ● 管理成本 ● 资源成本系统 ● ● ● ● 软件生命周期现有解决方案容错性体系完善度（监控覆盖度、上线SOP 、预案）不可用等级人 ● 认知、能力要求 ● 组织架构

24. 高可用面临的挑战识别预防感知定位如何尽早识别未知⻛险如何全面预防事故发生如何尽快感知事故如何精准定位问题解决如何快速、有效解决问题

25. 高可用体系 ◆ 识别指标体系 ◆ 混沌工程 ◆ 报警体系复盘 ◆ 自动化 ◆ 平台化解决 ◆ 日常/大促预案 ◆ 硬件异常预案 ◆ 业务异常预案 ◆ 大促预案 ◆ 异常执行规范 01 06 05 预防 ◆ 研发规范 02 体系打造 ◆ 安全漏洞修复 ◆ 容量保障 ◆ 代码质量提升 ◆ 报警收敛 ◆ 容灾 03 感知 ◆ 监控大屏 04 ◆ 上下游沟通机制定位 ◆ 值班机制 ◆ 硬件监控平台 ◆ 链路监控平台 ◆ 业务监控平台

26. 识别 – 指标体系场景层应用程序层用户访问次数及时⻓统计场景流量交互 QPS TPS 内部消息积压质量基础设施层错误码统计报警数量 CPU Memory 负载线程数 I/O Statistics Network

27. 识别 – 混沌工程 MYSQL故障 REDIS故障 RPC故障 06 01 02 CPU负载故障 05 混沌工程 03 磁盘故障 04 网络延迟故障

28. 预防 – 研发生命周期需求确认测试 ● 业务本质确认 ● 结构影响评估 ● 承载系统确认 ● 单侧覆盖 ● 流量回放上线设计 ● 架构设计 ● 组件设计 ● 技术方案设计开发 ● 代码质量提升 ● 报警收敛研发生命周期 ● 上线SO ● 灰度上线 ● 白天上线 ● Serverless 运营 ● ● ● ● 指标体系监控大屏预案备战

29. 预防 – 弱依赖基于 MySQL自身高可用，以及一定的容灾设计（如热备、读写分离、冷热分离、内存DB、延时异步入库等），最终达到数据库整体架构的高可用强依赖数据库架构弱依赖数据库架构 Mysql 数据库集群-异地多机房架构机房（异地备）机房（同城从）半同步机房（主）其他存储异常切换 Redis集群业务系统 clickhouse db2 db1 db3 … db84 缓存集群 ES+HBASE 消息队列1 大数据 … 表1 表2 表3 表150 对象存储 db 消息队列2

30. 定位 – 全域可观测核心场景链路可视化流量漏斗可视化 ■ 多层级监控体系业务指标可视化 ■ AIOPS 应用监控、链路追踪中间件监控应用日志主机监控容器监控

31. 解决 – 降级体系体验功能降级 01 02 业务功能降级会话级核心功能降级 03 04 多级降级、全链路降级 05 兜底

32. 成败藏在细节里 ◆ https的证书大小是多少 ◆ 已经设置了有效期的缓存如何设置为不过期 ◆ 影响TPS的因素到底有哪些，影响的程度分别是什么

33. 架构篇

34. 研发的本质软件的本质是基于对业务本质理解进行的业务建模并打造描述业务模型的复杂概念结构，结合业务发展持续演进，使用机器语言语言表达这些概念结构，在空间和时间限制下将他们映射成

35. 方法论之争业务 VS 技术是什么 VS 怎么做语言 VS 机器 lambda calculus VS 图灵机

36. 语言的演进计算机以二进制系统为基础，并使用比特去描述和映射世界，而万物皆比特，语言的终点是 DSL

37. PaaS化架构金融场景场景层零售场景智慧城市线下场景物流场景标准 API ……… H5 / PC 开放平台输出体系规则策略实名路由服务层信贷类人脸账号核身合同四要素合同签约账号转化科技类财富类人脸证件合同企业认证数科账号适配业务线叠加服务编排编排层 …… 平台管控物流类核身合同四要素企业认证合同 …… 安全管理 …… …… 产品注册登录安全核身实名等级组件配置领域层技术层刷脸实名分布式锁 OCR 分库分表无损文档转换流量回放标准合同签约规则引擎电子营业执照编排引擎打款认证表达式引擎营销规则鉴权规则监控管理流程编排代码质量资源管理能力层公安网区块链人工智能对象存储实时智能计算平台流量回放平台用户管理

38. PaaS化架构特点场景隔离标准化实现系统缩减 API 收敛用户洞察 PaaS化架构

39. 架构未来演进 03 PaaS化架构是什么 | 怎么做微服务架构 02 架构升级是什么 + 怎么做单体架构 01 04 数字化架构现在是什么-应该是什么 | 怎么做

40. 总结 ◆ 高可用是一个零和游戏，只有0和100分 , 成败藏在每一个细节里 ◆ 高可用需要一套持续迭代的 ◆ 体系是通过企业级体系来保障架构的升级来实现，提升可用性的同时，降低系统复杂度和研发成本 ◆ 高可用的背后是业务与技术之间的博弈和平衡，在数字化和云原生的时代，演进的方向是从矛盾的对立走向统一，实现业务与技术的双轮驱动