公司去年签了一家国内排名第一的 TO B 商超的项目, 从立项到结项, 到最终交付, 前前后后进行了一年, 对于公司无疑是赔本的买卖. 后半年基本上过的是惊心动魄, 如履薄冰. 时刻有可能找来一封律师函, 怕的不行....
先来一张当前部署图, 公司的平台是一个 SAAS 系统, 内部是公司的核心系统模块, 目前承接 的客户在 200 家左右, 包括大客户, 定制化, 标准客户三种类型, 案例中的客户是 TO B 大客户
整个服务部署在客户内网, 公司的自 SAAS 平台部署在公网. 时序图如下
是不是感觉没有毛病? 很板正的, 没毛病. 这是一个定制化系统是一个, TO B 系统, 业务量处理每天大概 8 万左右, 月末月初业务量翻倍. 是不是感觉很 easy. 如果是一个 TO C 系统, 这点业务量压力还不如服务放个屁呢. 当你知道 TO B 的一个单子有可能是 8000-10000 条数据, 大概 20M 数据的时候, 你可能会感觉不可思议. 业务量稳定, 业务数据体量大, 数据流转复杂 (可能没有体现), 喜欢自建内网, 要求严格, 时不时的会发律师函的那种哦.
当时投诉高峰阶段最严重的问题, 主要分析平台因素, 定制化系统下次讲一下
1. 自建 rabbitmq 集群, 极度不稳定
2. 平台系统强依赖, 稳定性指数下降
3. 网络问题, 丢包问题严重
第一个问题是生产 bug 最高的因素, 欢乐的时候, 一周四次, 每次宕机 30 分钟 - 60 分钟不等
第二个问题是偶发性问题, 一月发作一次的概率
第三个问题内网的网络环境, 每天不定时出现
自建 rabbitmq 集群, 极度不稳定
第一个问题确确实实是 MQ 作为开源项目一个不足的地方, 在一些极限情况下, 莫名其妙的宕机, 不知道有多少在讲 ACK 机制, 确保 MQ 的可靠性, 这个问题运维和平台还没有官宣原因, 目前的判断是 MQ 本身机制问题: 高峰情况下, MQ 会接受数据失败, 另外会出现 ACK OK, 数据丢失的情况
所以大家不要在吹嘘 ack 机制问题了大爷们. 另外此次 MQ 的的问题在于使用场景也有很大关系, 当前 MQ 接受的消息有可能是接近 20M 的数据, 假设每秒接受 60 条这样的消息, 每秒一个 G 的数据涌过来, 但是消费端从队列拉取 20m 1 秒估计拉不下来, 很有可能导致消费端被占满, MQ 的消息堆积, 其实这个并不可怕, 可怕的是没有任何 plan B 来应对这种情况. 这个是系统历史遗留问题, 一直没有得到实质性的解决. 后续的解决方案比较粗暴直接切换为一家商用的 MQ 服务, 运行了一段时间, 效果超级棒!!!! 商业系统用商业服务, 还是有必要的
平台系统强依赖, 稳定性指数下降
这个问题比较好理解, 串行的系统 A B C , 假设系统的稳定性是 90%, 那么三个系统中整体的稳定性就是 90%*90%*90%===73%, 可不可怕, 这个也是整个平台不稳定的重要因素, 虽然后续平台升级重做, 但是好像并没有解决这个问题, 甚至问题要被放大化了. 串行依赖的系统在各大公司都有存在, 如果么有一个较好的容错的机制, 估计过的都不开心. 所说的容错机制, A 系统依赖 B 系统, B 系统实在宕机了, A 系统如何在应对.
A: 快回答我啊, 你醒醒啊
B:....
A: 起来干活了
B:....
A: 你死了 我也装死...
客户端: A 你有本事接请求, 你有本事处理啊, 处理处理处理啊, 别给老娘玩装死, 我知道你在家
虽然都在讲 HA, 但是在 HA 完全达到之前, 强依赖的情况做好容错方案, 可以让事情简单点.
网络问题
比较好理解, 数据量比较大的时候, 如何保证数据能传输, 答案就是, 数据切片 + 异步; 这个是一个整体方案, 不是说客户端的传输方式改变, 服务器的接受方式会变得更复杂, 如何判断整个传输任务是否完成, 传输完成前的数据存储在哪里, 数据如何切分, 如何合并. 异步就是
平台中间数据如何存储, 切片数据如何保证最终完整传输, 如果中间传输失败, 如何处理, 大家可以留言讨论一下!!!!
期间还有很多其他有趣的事情, 都是因为这个客户的入驻, 才导致的林林总总的问题, 也算是对于平台的一次考验. 目前稳定交付. 号称中国业务最复杂要求最高的商超也这样被拿下了. 这次系统中暴漏了一个问题, 平台缺少一个可行的回调中心, 减少对接系统轮询的压力, 也是后续平台与所有客户系统很关键的一个部分, 目前每天要处理上百万的业务数据, 还有其他非业务数据的回调. 目前系统再规划中, 下次拿来跟大家分享
个人微信号: treenpool 欢迎骚扰
微信公众号: treenpool
treenpool 主页: treenpool.com 专注于知识体系的搭建网站, 知识积累更高效
哎呀列表: 点关注不迷路
8000 字 程序员跳槽攻略
关于 "锁" 最惊心的一次面试
换个角度讲 Redis
来源: http://www.jianshu.com/p/481dee459438