首页 > 代码库 > 接口服务规划的个人想法
接口服务规划的个人想法
遇到的问题:
- 过去一年事故频发
- 事故恢复时间过长
- 对事故现场没有很好的取证,不便于日后的分析
- 架构模块在使用的时候没有实质性对产生影响做分析,带有盲目性
解决方案的个人想法:
- 容灾:
- 关键参数
- NRO - 网络恢复目标(灾难后的网络恢复时间)
- RPO - 恢复点目标 (灾难前最后一次备份的时间,数据丢失)
- RTO - 时间恢复目标 (灾难后恢复物理系统环境的时间)
- RAP - 访问恢复目标(验证应用功能是否正常运行的时间)
- 关键参数
- 保存现场
- 故障转移
- 事故恢复
- 逻辑优化
重构,借用工具。上线必须保证:httpunit功能测试,LoadRunner负载测试通过。
- 性能优化
- 后期优化
利用大数据分析,将业务问题转化为大数据问题。日志分析,监控异常,逻辑优化,响应时长分析,并发分析,数据恢复,保存现场数据,提供可持续改进的数据基础。
提供数据的频率:
- 流量异常:必须实时或近实时的进行
- 战略性业务业务决策的趋势分析:分析可采用批量模式
- 数据采集(后续)
反正我的blog除了乐视同事也没有别人看,不涉及信息安全。把接口架构图放在这里,以后好找:
不是我画的图果然就看起来高端大气上档次[汗]。性能优化是我的日常工作,可以慢慢来。如果遇到什么闹心的线上事故,建议看看
《打错一个字母-瘫痪半个互联网 亚马逊AWS的云存储服务S3超高错误率宕机事件》
《google.com宕机一小时》
《gitlab程序猿用一条错误命令误删了整个数据库》
心情会好很多!
接口服务规划的个人想法
声明:以上内容来自用户投稿及互联网公开渠道收集整理发布,本网站不拥有所有权,未作人工编辑处理,也不承担相关法律责任,若内容有误或涉及侵权可进行投诉: 投诉/举报 工作人员会在5个工作日内联系你,一经查实,本站将立刻删除涉嫌侵权内容。