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

  • 时间:
  • 浏览:0
  • 来源:五分时时彩_五分时时彩技巧_五分时时彩平台

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

现在技术圈有一另三个白不太好的问题,老会 看了另一另三个白一另三个白问题,当出現稍微热门有些的文章的时候,总会出現两级分化的问题,一拨人会反馈牛逼写得太好了,而且另一拨人老会 反馈又时候时候刚开始了了吹牛逼了,各种无脑质疑。

各人 认为另三个白问题觉得与否太客观,一篇文章的出現就说 作者各人 对于技术的阐述,难免有自身的局限,同样既然能写文章必然就说 会是瞎乱吹牛逼,那毕竟与否同事我们 都认识,上面还要在你这俩行业混。

既然文章肯定具有它的局限性,原应写出来读者可上上能给出有些更好的建议,另一另三个白对于写文章的人也是本身学习,我老会 从读者的留言中学到了所以有知识,这是本身正反馈。

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

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

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

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

至于在生产环境找十台服务器,你这俩操作应该是随随便便的一另三个白中型互联网公司都能玩转信用卡 的,时候公司合适用了 400-400 太服务器,从中找个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 的模拟生产环境,每年的花费合适在4000万以上,中型互联网公司没能说服老板去干这件事情。

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

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

至于属不属于作坊式的阶段我不反驳,流程上肯定是有严重不足的你这俩我认可,但本身一另三个白任务管理器员写一另三个白接口做几十亿的系统迁移,原应真的是另一另三个白那还还要留 20 号的人在这里干嘛。

必须 大级别的数据迁移肯定是一另三个白系统性的工程,本身1、另三个白任务管理器员可上上能负责的,而且迁移任务管理器的发起入口用 1、2 任务管理器员负责足以,上面还要调用 N 个系统的接口配合来完成整体的工作。

问题6 :我觉得你这俩错误犯得很低级 日数据量达到几十亿次的应用 你造没考虑到数据量过大迁移耗时太长的问题?平时小项目写个定时器与否考虑会不不执行时间过长原应,第一次还没执行完就执行第二次,我们 面对千亿的数据量你造必须 考虑你这俩问题?

你这俩问题带有一另三个白错误,交易额是日几十亿而与否交易量几十亿次,订单量远远必须 到达你这俩量级。数据迁移当然考虑了迁移时间,在整个项目迁移时候觉得原应进行过所以有次的小规模迁移了,本身第一次迁移,你这俩文章中也说明了,你这俩提问者明显必须 看了就来喷了。

你这俩迁移任务管理器在干这次大活时候,觉得原应经历多次考验了,所以有从本身程度上来讲这次出问题,轻视也是问题趋于稳定的原应之一。

不但原应多次使用,在正式迁移时候也安排进行了多次的验证,就说 做为管理者必须 和任务管理器员并肩深入排查每项细节,趋于稳定每项管理失职。

另外有的读者说为哪几种不使用任务管理器,我强调一下整个迁移项目使用了任务管理器,而且还与否仅仅一另三个白任务管理器,就说 任务管理器的最外层必须 使用任务管理器,也就说 我们 上面的出理 方案。

觉得还有所以有问题,这里不再一一宣布,有的提问真的是太低级,感觉与否应该是一另三个白任务管理器员提出的问题。

不过还是有有些读者会对你这俩大规模迁移有所了解,这其中涉及的细节你造不不说太满,任何一另三个白小的忽略不原应原应大的问题,你这俩事情必须 最好的依据在文中一一举例出来。

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

哪几种说风凉话的肯定必须 做过上千张表新老系统的迁移,还数据库上面件对接,呵呵

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