接口服务规划的个人想法

Java基础

浏览数:76

2019-8-20

AD:资源代下载服务

遇到的问题:

  1. 过去一年事故频发
  2. 事故恢复时间过长
  3. 对事故现场没有很好的取证,不便于日后的分析
  4. 架构模块在使用的时候没有实质性对产生影响做分析,带有盲目性

解决方案的个人想法:

  1. 容灾:
    1. 关键参数
      1. NRO – 网络恢复目标(灾难后的网络恢复时间)
      2. RPO – 恢复点目标 (灾难前最后一次备份的时间,数据丢失)
      3. RTO – 时间恢复目标 (灾难后恢复物理系统环境的时间)
      4. RAP – 访问恢复目标(验证应用功能是否正常运行的时间)
  2. 保存现场
  3. 故障转移
  4. 事故恢复
  5. 逻辑优化

重构,借用工具。上线必须保证:httpunit功能测试,LoadRunner负载测试通过。

  1. 性能优化
  2. 后期优化

利用大数据分析,将业务问题转化为大数据问题。日志分析,监控异常,逻辑优化,响应时长分析,并发分析,数据恢复,保存现场数据,提供可持续改进的数据基础。

提供数据的频率:

  1. 流量异常:必须实时或近实时的进行
  2. 战略性业务业务决策的趋势分析:分析可采用批量模式
  3. 数据采集(后续)

反正我的blog除了乐视同事也没有别人看,不涉及信息安全。把接口架构图放在这里,以后好找:

不是我画的图果然就看起来高端大气上档次[汗]。性能优化是我的日常工作,可以慢慢来。如果遇到什么闹心的线上事故,建议看看

《打错一个字母-瘫痪半个互联网    亚马逊AWS的云存储服务S3超高错误率宕机事件》

《google.com宕机一小时》

《gitlab程序猿用一条错误命令误删了整个数据库》

心情会好很多!

今天开会确定的方案,这里备忘一下:

1 从上面架构图中可以看出安外联通的cbase只是做了一个冷备,会面临网络抖动的问题;马驹桥电信一旦故障,需要手动切换。冷备的机器虽然是正常写入的,但是数据没有经过检验,切换后的数据一致性隐患问题;跨机房的性能问题。所以我们决定改成联通和电信做一个物理隔离。这样做需要解决的问题:swiftq给联通和电信发消息,两端接受和处理消息的时机不一样,但是只有两段都更新成功后才能给各端发通知消息的更新,涉及到策略的问题。一旦一边更新失败,需要有补偿机制,补偿的策略问题。部署的复杂性提高,合理部署的问题。

2 memcache的mget在数据量大时性能急剧下降的问题。性能急剧下降时占用连接导致阻塞的问题。测试时需要注意key的数量以及value大小的双重变化影响。

3 cbase读写分离的问题

另外,我们是基础服务部门,应该可以不使用http协议来调用

作者:编程一生