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

  • 时间:
  • 浏览:0
  • 来源:大发快三_快三app安卓_大发快三app安卓

前一段时间写了一篇文章《午夜1点突发致命生产事故,人工多程序来破局!》,就是 一篇生产事故的记实文章,没想到在圈内流传甚广,其含有程序员对其中的细节一阵一阵疑惑,刚好国庆可不需用和亲戚亲戚朋友再进一步探讨一下。

现在技术圈一三个白不太好的间题报告 ,一个劲看一遍就是 一三个白间题报告 ,当老出稍微热门什么都有有的文章的之后,总会老出两级分化的间题报告 ,一拨人会反馈牛逼写得太好了,怎样让 另一拨人一个劲反馈又结束了了吹牛逼了,各种无脑质疑。

当时人认为一三个白间题报告 并非 完整总要太客观,一篇文章的老出就是 作者当时人对于技术的阐述,难免有自身的局限,同样既然能写文章必然就是 会是瞎乱吹牛逼,那毕竟完整总要同事亲戚亲戚朋友都认识,中间需用在這個行业混。

既然文章肯定具有它的局限性,意味着着写出来读者可不需用给出什么都有有更好的建议,就是 对于写文章的人也是這個学习,我一个劲从读者的留言中学到了什么都有知识,这是這個正反馈。

现在的间题报告 是什么都有技术人把抬杠当作了這個本事,用以展示当时人的优越感,意味着着能说到点子上也还好,关键是有的留言你一看就可不需用发现,技术涵养太低了明显是不懂行的请况。

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

间题报告 1:“几百万商户、几千个代理商”,“上千多张表,关系极为繁复”,“在生产环境找十台服务器”相当于也得是淘宝,京东這個级别的电商网站要能有這個规模了吧!

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

至于在生产环境找十台服务器,這個操作应该是随随便便的一三个白中型互联网公司都能读懂的,之后公司相当于用了 30-30 太服务器,从中找个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 的模拟生产环境,每年的花费相当于在30万以上,中型互联网公司没能说服老板去干这件事情。

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

使用 Servlet 什么都有有完整总要过时,现在企业级开发90%的公司都使用的是 Spring MVC 吧,Spring MVC 就是 Servlet 包装出来了,很过时吗?

至于属不属于作坊式的阶段我不反驳,流程上肯定是有匮乏的這個我认可,但并完整总要一三个白程序员写一三个白接口做几十亿的系统迁移,意味着着真的是就是 那还需用留 20 号的人在这里干嘛。

没人大级别的数据迁移肯定是一三个白系统性的工程,并完整总要1、一三个白程序员可不需用负责的,怎样让 迁移程序的发起入口用 1、2 程序员负责足以,中间需用调用 N 个系统的接口配合来完成整体的工作。

间题报告 6 :我并非 這個错误犯得很低级 日数据量达到几十亿次的应用 简直没考虑到数据量过大迁移耗时太长的间题报告 ?平时小项目写个定时器总要考虑会不想执行时间过长意味着,第一次还没执行完就执行第二次,亲戚亲戚朋友面对千亿的数据量简直没人考虑這個间题报告 ?

這個间题报告 中一三个白错误,交易额是日几十亿而完整总要交易量几十亿次,订单量远远没人到达這個量级。数据迁移当然考虑了迁移时间,在整个项目迁移之后并非 意味着着进行过什么都有次的小规模迁移了,并完整总要第一次迁移,這個文章中也说明了,這個提问者明显没人看一遍就来喷了。

這個迁移程序在干这次大活之后,并非 意味着着经历多次考验了,什么都有从這個程度上来讲这次出间题报告 ,轻视也是间题报告 处于的意味着之一。

不但意味着着多次使用,在正式迁移之后也安排进行了多次的验证,就是 做为管理者没人和程序员同时深入排查帕累托图细节,处于帕累托图管理失职。

另外有的读者说为那此不使用多程序,我强调一下整个迁移项目使用了多程序,怎样让 还完整总要仅仅一三个白程序,就是 程序的最外层没人使用多程序,也就是 亲戚亲戚朋友中间的补救方案。

并非 还有什么都有间题报告 ,这里不再一一宣告,有的提问真的是太低级,感觉完整总要应该是一三个白程序员提出的间题报告 。

不过还是有什么都有有读者会对這個大规模迁移有所了解,这其中涉及的细节简直暂且太满,任何一三个白小的忽略完整总要意味着着意味着大的间题报告 ,這個事情没人法律办法在文中一一举例出来。

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

那此说风凉话的肯定没人做过上千张表新老系统的迁移,还数据库中间件对接,呵呵

最后,还是那句话:保持技术人的那颗初心,一切以补救实际间题报告 为主。