针对简书的崩溃给出自己的建议

简书确实几乎每个月都会崩溃,一次崩很长时间....作为一个研发人员,为了更好的使用这个平台,对于我目前发现的问题,我给出自己的一点点建议

一 .简书每次崩溃,破坏面极大,这次整个简书直接完球了,还一连抢救了10多个小时才搞定....

1.1 建议: 针对这个情况,我的建议是微服务拆分

比如拆分为评论服务(服务,包括完整的CURD),点赞服务,内容查询服务,内容修改服务,用户服务,其他服务(定时任务或者数据数据等),一定要安全脱离耦合情况,比如文章详情页文章内容就从内容查询服务查,这个文章的评论,只能从平台中台查,评论做异步加载不要和内容查询在一起;

如果服务一定不能及时修复 全力保住内容查询服务,保住内容列表查询功能,这样对系统内用户友好 全力保住内容查询服务,保住内容详情查询功能,这样对系统内外用户友好,百度这边存储了大量简书的快照,人家一点击进入详情连接就发现简书宕机了,这种影响面......人家发现基础服务都会宕机,还敢用你平台吗?

1.2 目的:影响范围缩小,出问题易发现易解决,保障主要服务,用户能接受,外部用户不受影响

二 .问题:服务可靠性极低,我注意到这次好多人崩溃好多人出现了文章和粉丝数据的大量丢失

这种事故真的非常严重了,你要是增量数据丢失我觉得还可以理解一下,但是历史数据为啥会丢???

2.1建议: 存储中间件上集群

比如Mysql,Redis,上集群版,做好主从切换,宕机恢复的事情,另外数据定期存档,

2.2 目的: 加强服务可靠性以及数据安全性

三.问题 反馈机制极差

平台几乎没有运营人员维护,简书出了问题,大家只能等崩溃修复后才能去平台进行反馈,而且反馈压根得不到官方回复

3.1 建议:都21世纪了,即时平台没有自研IM反馈麻烦拉群吧