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

  • 时间:
  • 浏览:1
  • 来源:大发快三_快三遗漏_大发快三遗漏

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

现在技术圈有一一一个多 不太好的什么的问题,老要看了从前一一一个多 什么的问题,当出先稍微热门某些的文章的我想要 ,总会出先两级分化的什么的问题,一拨人会反馈牛逼写得太好了,因此另一拨人老要反馈又刚开始吹牛逼了,各种无脑质疑。

买车人认为一一一个多 什么的问题我我确实否是太客观,一篇文章的出先因此作者买车人对于技术的阐述,难免有自身的局限,同样既然能写文章必然因此会是瞎乱吹牛逼,那毕竟否是同事朋友都认识,里面需用在你你这名行业混。

既然文章肯定具有它的局限性,可能写出来读者可不需用给出某些更好的建议,从前对于写文章的人也是你你这名学习,我老要从读者的留言中学到了就是知识,这是你你这名正反馈。

现在的什么的问题是就是技术人把抬杠当作了你你这名本事,用以展示买车人的优越感,可可不需用说到点子上也还好,关键是有的留言你一看就可不需用发现,技术涵养太低了明显是不懂行的状况。

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

什么的问题 1:“几百万商户、几千个代理商”,“上千多张表,关系极为复杂”,“在生产环境找十台服务器”最少 也得是淘宝,京东你你这名级别的电商网站不后该 有你你这名规模了吧!

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

至于在生产环境找十台服务器,你你这名操作应该是随随便便的一一一个多 中型互联网公司都能搞懂的,我想要 公司最少 用了 200-200 太服务器,从中找个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 的模拟生产环境,每年的花费最少 在2000万以上,中型互联网公司不能自己说服老板去干这件事情。

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

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

至于属不属于作坊式的阶段我不反驳,流程上肯定是有欠缺的你你这名我认可,但并否是一一一个多 应用应用程序员写一一一个多 接口做几十亿的系统迁移,可能真的是从前那还需用留 20 号的人在这里干嘛。

没法大级别的数据迁移肯定是一一一个多 系统性的工程,并否是1、一一一个多 应用应用程序员可不需用负责的,因此迁移应用应用程序的发起入口用 1、2 应用应用程序员负责足以,里面需用调用 N 个系统的接口配合来完成整体的工作。

什么的问题6 :我我确实你你这名错误犯得很低级 日数据量达到几十亿次的应用 甜得没考虑到数据量过大迁移耗时太长的什么的问题?平时小项目写个定时器都会考虑会后该执行时间过长因为,第一次还没执行完就执行第二次,朋友面对千亿的数据量甜得没法考虑你你这名什么的问题?

你你这名什么的问题包含一一一个多 错误,交易额是日几十亿而否是交易量几十亿次,订单量远远没法到达你你这名量级。数据迁移当然考虑了迁移时间,在整个项目迁移我想要 我我确实可能进行过就是次的小规模迁移了,并否是第一次迁移,你你这名文章中也说明了,你你这名提问者明显没法看了就来喷了。

你你这名迁移应用应用程序在干这次大活我想要 ,我我确实可能经历多次考验了,就是从你你这名程度上来讲这次出什么的问题,轻视也是什么的问题指在的因为之一。

不但可能多次使用,在正式迁移我想要 也安排进行了多次的验证,因此做为管理者没法和应用应用程序员一起去深入排查每种细节,指在每种管理失职。

另外有的读者说为那些不使用多应用应用程序,我强调一下整个迁移项目使用了多应用应用程序,因此还否是仅仅一一一个多 多应用应用程序,因此应用应用程序的最外层没法使用多应用应用程序,也因此朋友里面的补救方案。

我我确实还有就是什么的问题,这里不再一一公布,有的提问真的是太低级,感觉否是应该是一一一个多 应用应用程序员提出的什么的问题。

不过还是有某些读者会对你你这名大规模迁移有所了解,这其中涉及的细节甜得何必 没法来越多,任何一一一个多 小的忽略否是可能因为大的什么的问题,你你这名事情没法辦法 在文中一一举例出来。

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

那些说风凉话的肯定没法做过上千张表新老系统的迁移,还数据库里面件对接,呵呵

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