公司去年签了一家国内排名第一的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专注于知识体系的搭建网站，知识积累更高效
哎呀列表：点关注不迷路
网友评论