接口服务规划的个人想法

遇到的问题：

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协议来调用