勋章1-上线流程
勋章2-持续集成
勋章3-架构设计
勋章4-容量预估
勋章5-服务化实践
勋章6-监控建设
勋章7-降级实施
勋章8-容灾设计
基于 git 轻量化分支.实现需求和 task 的统一管理. 极大的解决了效率,和加塞的问题.
1.上线流程:
预发.
自动化case.
按城市小流量.
基于监控系统自动化识别判断是否有问题. 持续exception
监控告警
checkList截图+文字. + 自动化识别. 结合到上线步骤中.
2. 持续集成:
自动化case. 1. mock架构 2.基于接口的mock 3.mockMVc,mockDubbo
3. 架构设计checklist
0. 目标
1、功能理解
- 需求理解和描述是否清晰
- 功能拆分是否合理
- 功能是否有遗漏
- 本期不支持但可能的功能有哪些
2、架构整体设计
- 系统上下文说明是否清晰
- 模块拆分
- 模块是否有层次
- 模块功能是否内聚
- 模块依赖是否有环状
- 模块拆分粒度是否合理
- 模块类型分析
- 计算类型 | IO类型 | 数据存储类型
- 在线服务 | 离线worker
- 功能可扩展性
- 可扩展但不过度设计
- 技术选型
- 语言选型--c++/go/php
- 开发框架选型
- 基础组件选型
- 组件成熟度
- 是否有op支持
4、接口设计
- 关键接口的处理流程图
- 接口可扩展
- 统一采用输入Req,返回Rsp
- 接口可读性强
- 接口数目尽可能少
- 相近接口不宜过多
- 是否需要批量接口
- 异常返回方式一致
- 错误码定义清晰有条理
5、数据设计
- 存储数据
- 各数据结构定义是否合理
- 各数据之间的关系是否合理
- 字段的可扩展性
- 数据的存储效率
- 存储组件的选型
- 缓存数据
- 字段的可扩展性
- 过期时间是否设置及是否合理
- 缓存数据和存储数据的同步是否及时
6、算法设计
- 算法接口可扩展和变更,但不过度设计
- 算法性能
- 算法效果
- 算法ab实验支持
7、监控统计支持
- 日志是否规范
- 系统指标监控统计
- 接口监控统计--qps、时延、成功率
- 是否有业务指标监控统计
8、容量预估
- 容量预估公式是否合理
- 容量是否有可扩展性
- 扩容方式是什么样
- 是否可快速扩容
9、部署方式
- 灰度机制
- 回滚机制
- 部署依赖
10、容灾降级
- 单点级别–进程、机器、IDC
- 雪崩预防--超时&重试
- 一键降级
11、实施相关
- 项目组织方式
- 实施计划
4.容量预估 .一种是上线前,一种是上线后排查.
- 接口流量统计
业务层接口统计 .
- 容量现状梳理
蛇口(qq)机房 机器现状 梳理 - 基于数据的统计的数据分析能力.
- 容量模型
专快容量模型 - 容量切分
api-web流量拆分 -
业务模块,压测通过 全链路压测进行:
压测步骤:
压测数据
4.
痛点:
遇到的问题:
1. 单人项目化,领域先行,back顶上,避免和业务拒绝.
2. 后续的业务逐步服务化.
3. 日志排查,统一的flag,线程,等所有的封装filter.
4. 组合层.太重,参数泛化,透传的变成jsonString.不然变动较大,了解对方业务.
5. 单测mock,接口test实现. 集成层.
勋章 6.监控建设
分钟级接口日志请求监控error,请求量,时间图,,耗时图.
基于此的耗时相关性统计.找出抖动真凶.
zipkin监控
基于数据库的业务bi监控
解析日志后的code统计监控.(用户体检角度)
分布式数据一致性监控.
勋章7-降级实施
1. 防雪崩
2. 修改用户入口,增强用户体验
3. 前后端结合,返回特定错误码,或者修改http跳转链接. 进行引流和降级.
4. 有损降级,基于风控,流控的降级,削平流量高峰.
预案级别
预案级别说明:
Lv0:核心服务完全不可用
Lv1:核心服务有损
Lv2:核心服务无损,影响体验
Lv3:核心服务无损,不影响体验,特性效果消失(如:红点提醒)
降级措施
降级级别 | 措施 | 相关接口 | 用户影响 | 降级效果 | 如何开启 | Apollo开关 |
---|---|---|---|---|---|---|
降级级别 | 措施 | 相关接口 | 用户影响 | 降级效果 | 如何开启 | Apollo开关 |
Lv3 | 首页和列表页红点返回空 |
| 部分用户无法收到最新的消息提示 | 减轻后端压力 | 通过Apollo开启 | beatles_api_service_degradation_lv3 |
高流量接口做降级 |
| 1、位置不上报,无影响 2、首页运营弹窗不展示 3、位置共享功能不可用 |
| |||
运营相关信息降级 |
| 用户无法看到弹窗 |
| |||
Lv2 | yellowstar整体功能降级 |
| yellowstar相关功能都无法使用,包括自动同行和邀请 |
| 通过Apollo开关控制 | beatles_api_invite_automatch |
部分乘客端列表不展示 |
|
乘客看不到司机路线信息 |
| 通过Apollo控制 | beatles_api_service_degradation_lv2 | |
Lv1 | 部分司机端列表不展示 |
|
| 降低对后端订单相关系统的压力 | 通过Apollo控制 | beatles_api_service_degradation_lv1 |
用户发单但不分单 |
| 用户发单之后始终没有司机抢单 | 降低后端分单系统的压力 | |||
Lv0 | 暂无 |
负责人
第一负责人:蒋志斌
第二负责人: 杨晨晨 奚媛
以上几人有Apollo相关的操作权限,如果服务有必要进行操作,请按照顺序联系以上几人
异地双活目标不是为了避免容灾后服务切换.而是为了让用户体验更好.
1. 每张表都有主归属者.
2. 基于这个所有设计都好设计了. 每个请求都带有地址信息和操作者维度,根据归属维度判断,如果是该归属维度,通过地址信息寻找最近的数据中心,同时对该数据主键加锁,加锁失败,先解锁,然后加锁.
3. 对于移动的ip,计算层先进行ip清洗,指定上一个相似的ip. 这个dns和各个网关层都可以替换.