系统架构基础+流程改进

    勋章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.容量预估 .一种是上线前,一种是上线后排查.

1. 接口流量统计
   业务层接口统计 .
   
2. 容量现状梳理
   蛇口(qq)机房 机器现状 梳理
3. 基于数据的统计的数据分析能力.
   
4. 容量模型
   专快容量模型
5. 容量切分
   api-web流量拆分

6. 业务模块，压测通过 全链路压测进行：

   压测步骤：

   压测数据

4.

    勋章5-服务化实践

        痛点:

       遇到的问题:

           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	首页和列表页红点返回空	首页红点接口 司机固定路线页面tab红点 乘客固定路线页面tab红点	部分用户无法收到最新的消息提示	减轻后端压力	通过Apollo开启	beatles_api_service_degradation_lv3
	高流量接口做降级		1、位置不上报，无影响 2、首页运营弹窗不展示 3、位置共享功能不可用	降低对于API服务PHP的压力，提升响应时间 降低对于order数据库的压力
	运营相关信息降级	首页浮层弹窗	用户无法看到弹窗	降低运营系统的压力 提升API接口性能
Lv2	yellowstar整体功能降级	乘客固定路线页面 乘客发单等待页面 司机固定路线页面列表 司机临时路线列表页面	yellowstar相关功能都无法使用，包括自动同行和邀请	降低对后端的压力 降低API数据库压力	通过Apollo开关控制	beatles_api_invite_automatch
	部分乘客端列表不展示	乘客固定路线页面 乘客发单等待页面 附近的车主 跨城车主	乘客看不到司机路线信息	降低对后端的压力 提升API的响应时间	通过Apollo控制	beatles_api_service_degradation_lv2
Lv1	部分司机端列表不展示	固定路线页面列表 临时路线列表页面 附近的乘客 跨城的乘客	司机无法看到乘客的订单列表	降低对后端订单相关系统的压力	通过Apollo控制	beatles_api_service_degradation_lv1
	用户发单但不分单	用户发单接口	用户发单之后始终没有司机抢单	降低后端分单系统的压力
Lv0	暂无

 

负责人

第一负责人：蒋志斌

第二负责人: 杨晨晨 奚媛

以上几人有Apollo相关的操作权限，如果服务有必要进行操作，请按照顺序联系以上几人

    勋章8-容灾设计

      异地双活目标不是为了避免容灾后服务切换.而是为了让用户体验更好.

     1. 每张表都有主归属者.

     2. 基于这个所有设计都好设计了. 每个请求都带有地址信息和操作者维度,根据归属维度判断,如果是该归属维度,通过地址信息寻找最近的数据中心,同时对该数据主键加锁,加锁失败,先解锁,然后加锁.

    3. 对于移动的ip,计算层先进行ip清洗,指定上一个相似的ip. 这个dns和各个网关层都可以替换.