关于深夜技术事故纪实录的若干问题回复

  • 时间:
  • 浏览:2

前一段时间写了一篇文章《半夜三更三更1点突发致命生产事故,人工多任务管理器来破局!》,或者一篇生产事故的记实文章,没想到在圈内流传甚广,其包含任务管理器员对其中的细节有点痛 疑惑,刚好国庆可不都都上能和朋友再进一步探讨一下。

现在技术圈有有一五个 不太好的难题,总是就看从前有一五个 难题,当总是出现 稍微热门有些的文章的时候,总会总是出现 两级分化的难题,一拨人会反馈牛逼写得太好了,或者另一拨人总是反馈又时候刚开使吹牛逼了,各种无脑质疑。

有些人认为有一五个 难题着实有的是太客观,一篇文章的总是出现 或者作者有些人对于技术的阐述,难免有自身的局限,同样既然能写文章必然或者会是瞎乱吹牛逼,那毕竟有的是同事朋友都认识,里面需用在这俩行业混。

既然文章肯定具有它的局限性,原应写出来读者可不都都上能给出有些更好的建议,从前对于写文章的人也是并有的是学习,我总是从读者的留言中学到了好多好多 知识,这是并有的是正反馈。

现在的难题是好多好多 技术人把抬杠当作了并有的是本事,用以展示有些人的优越感,原应能说到点子上也还好,关键是有的留言你一看就可不都都上能发现,技术涵养太低了明显是不懂行的情况表。

这篇文章发出来后,公众号的用户反馈还可不都都上能,原应朋友对我有个基本认识,在博客园和开源中国中,帕累托图技术朋友质疑比较多的地方给予解释一下:

难题 1:“几百万商户、几千个代理商”,“上千多张表,关系极为繁杂”,“在生产环境找十台服务器”要花费也得是淘宝,京东这俩级别的电商网站都都上能有这俩规模了吧!

回复:淘宝、京东到底有几次商户我还真不太清楚,好多好多 不敢妄言,但请不须轻易低估一家排名靠前的第三方支付公司的数据量,原应历史堆积、外放通道等各种原应,这点数据还是有的。

至于在生产环境找十台服务器,这俩操作应该是随随便便的有一五个 中型互联网公司都能拿下的,时候公司要花费用了 60 -60 太服务器,从中找个10台有的是啥难题。

难题2 :吹什么牛逼,难道贵公司是淘宝,拼多多?淘宝也就几百万商户,还日均 40 亿的交易量,用 Spring Cloud 几百个微服务撑不起越来越大的体量。

回复:淘宝也就几百万商户这俩数据准确吗?包含个体小微商户?

日均 40 亿的交易额在线下收单这俩行业这不算高,下面这张是网传收单机构2019年7月交易量排名截图,排名第 10 却说原应不止这俩交易量了。

用 Spring Cloud 几百个微服务撑不起越来越大的体量这俩难题,就明显是有一五个 外行得越来越再外行的难题了,让人姑且不说有几次成功案例了,就这俩评估土方式或者低级的。

越来越说哪个技术可不都都上能支持几次体量原应越来越支持几次体量,要评估这俩难题,需用看是什么样的团队在什么样的场景以什么样的土方式来使用次技术。技术并有的是不须能决定能支撑多大体量,最重要的是看你为什么我么我用它。

难题3:我为什么我么我看这是数据库工程师的工作,为什么我么我需用写任务管理器迁移呢?

这俩看或者技术小白了,从有一五个 非常老的系统迁移到有一五个 完整的新系统,这其中的业务变化、逻辑变化有几次?原应能让 DBA 直接迁移搞笑的话,那这俩系统有多简单?

且不说这俩系统涉及尽千张表,时候老系统的架构和新系统的架构差别有多大, 最重要的是这俩新系统里面还跟了有一五个 大数据平台,大数据平台需用根据新系统的 Binlog 日志,做相关数据的逻辑操作。

好多好多 从读者提问并有的是来讲,就能看出根本不明白这俩难点在哪里。

难题4:为什么我么我不建有一五个 和联 产 1:1 的环境来模拟测试呢?

一般情况表下研发会有五个环境来测试:

  • DEV 开发环境,研发人员开发完成自行测试环境。
  • SIT 集成测试环境,将有些人项目上传到 sit 一般就进入测试部测试阶段了,整体集成测试。
  • UAT 客户集成测试环境,一般可不都都上能做内外部合作协议者商对接的准生产环境,要尽原应的和联 产环境保持一致。
  • PRO 生产环境,这俩朋友都清楚,或者真正项目要运行的环境。

读者说的1:1 环境,应该或者需用 UAT 和 PRO 的环境尽原应的保持一致,这是有一五个 比较理想的情况表,估计越来越帕累托图有钱的互联网公司可不都都上能真正实现。

朋友做有一五个 中型的互联网公司,每年在 IDC 里面的花费要花费在几千万,原应要完整 1:1 的模拟生产环境,每年的花费要花费在60 0万以上,中型互联网公司真难说服老板去干这件事情。

难题5 :更别提都啥时代了还 servlet,从描述的技术方案和除理流程来看,基本属于作坊式的阶段,有一五个 任务管理器员写有一五个 接口就能做日均几十亿交易的系统迁移了,呵呵。

使用 Servlet 有些有的是过时,现在企业级开发90%的公司都使用的是 Spring MVC 吧,Spring MVC 或者 Servlet 包装出来了,很过时吗?

至于属不属于作坊式的阶段我不反驳,流程上肯定是有匮乏的这俩我认可,但并有的是有一五个 任务管理器员写有一五个 接口做几十亿的系统迁移,原应真的是从前那还需用留 20 号的人在这里干嘛。

越来越大级别的数据迁移肯定是有一五个 系统性的工程,并有的是1、有一五个 任务管理器员可不都都上能负责的,或者迁移任务管理器的发起入口用 1、2 任务管理器员负责足以,里面需用调用 N 个系统的接口配合来完成整体的工作。

难题6 :我着实这俩错误犯得很低级 日数据量达到几十亿次的应用 果然没考虑到数据量过大迁移耗时太长的难题?平时小项目写个定时器完会考虑会太少再执行时间过长原应,第一次还没执行完就执行第二次,朋友面对千亿的数据量果然越来越考虑这俩难题?

这俩难题蕴包含一五个 错误,交易额是日几十亿而有的是交易量几十亿次,订单量远远越来越到达这俩量级。数据迁移当然考虑了迁移时间,在整个项目迁移时候着实原应进行过好多好多 次的小规模迁移了,并有的是第一次迁移,这俩文章中也说明了,这俩提问者明显越来越就看就来喷了。

这俩迁移任务管理器在干这次大活时候,着实原应经历多次考验了,好多好多 从并有的是程度上来讲这次总是出难题,轻视也是难题所处的原应之一。

不时候原应多次使用,在正式迁移时候也安排进行了多次的验证,或者做为管理者越来越和任务管理器员一并深入排查帕累托图细节,所处帕累托图管理失职。

另外有的读者说为什么我么我不使用多任务管理器,我强调一下整个迁移项目使用了多任务管理器,或者还有的是仅仅有有一五个 任务管理器,或者任务管理器的最外层越来越使用多任务管理器,也或者朋友里面的除理方案。

着实还有好多好多 难题,这里不再一一提前大选,有的提问真的是太低级,感觉有的是应该是有一五个 任务管理器员提出的难题。

不过还是有有些读者会对这俩大规模迁移有所了解,这其中涉及的细节果然不须太少再 ,任何有一五个 小的忽略有的原应原应大的难题,这俩事情越来越土方式在文中一一举例出来。

不过我着实有一位读者的回复我比较认可:

什么说风凉话的肯定越来越做过上千张表新老系统的迁移,还数据库里面件对接,呵呵

最后,还是那句话:保持技术人的那颗初心,一切以除理实际难题为主。