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

  • 时间:
  • 浏览:0
  • 来源:幸运快3_快3注册邀请码_幸运快3注册邀请码

前一段时间写了一篇文章《夜深 1点突发致命生产事故,人工程序池池来破局!》,全都一篇生产事故的记实文章,没想到在圈内流传甚广,其暗含程序池池员对其中的细节有点痛 疑惑,刚好国庆能否和其他同学歌词 再进一步探讨一下。

现在技术圈一个多多多多不太好的问提图片,一个劲看到从前一个多多多问提图片,当出先稍微热门日后 的文章的日后 ,总会出先两级分化的问提图片,一拨人会反馈牛逼写得太好了,全都另一拨人一个劲反馈又开始英语 吹牛逼了,各种无脑质疑。

每各人认为一个多多多问提图片我觉得都不 太客观,一篇文章的出先全都作者每各人对于技术的阐述,难免有自身的局限,同样既然能写文章必然全都会是瞎乱吹牛逼,那毕竟都不 同事其他同学歌词 歌词 认识,里面需要在这种行业混。

既然文章肯定具有它的局限性,原因 写出来读者能否给出日后 更好的建议,从前对于写文章的人也是有四种 学习,我一个劲从读者的留言中学到了全都知识,这是有四种 正反馈。

现在的问提图片是全都技术人把抬杠当作了有四种 本事,用以展示每各人的优越感,原因 能说到点子上也还好,关键是有的留言你一看就能否发现,技术涵养太低了明显是不懂行的情况报告。

这篇文章发出来后,公众号的用户反馈还能否,原因 其他同学歌词 对我有个基本认识,在博客园和开源中国中,次责技术其他同学歌词 质疑比较多的地方给予解释一下:

问提图片 1:“几百万商户、几千个代理商”,“上千多张表,关系极为冗杂”,“在生产环境找十台服务器”大概也得是淘宝,京东这种级别的电商网站也能有这种规模了吧!

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

至于在生产环境找十台服务器,这种操作应该是随随便便的一个多多多中型互联网公司都能甩掉的,日后 公司大概用了 3000-300 太服务器,从中找个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 的模拟生产环境,每年的花费大概在30000万以上,中型互联网公司真难说服老板去干这件事情。

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

使用 Servlet 日后 都不 过时,现在企业级开发90%的公司都使用的是 Spring MVC 吧,Spring MVC 全都 Servlet 包装出来了,很过时吗?

至于属不属于作坊式的阶段我不反驳,流程上肯定是有不够的这种我认可,但并都不 一个多多程序池池池员写一个多多多接口做几十亿的系统迁移,原因 真的是从前那还需要留 20 号的人在这里干嘛。

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

问提图片6 :我觉得这种错误犯得很低级 日数据量达到几十亿次的应用 觉得 没考虑到数据量过大迁移耗时太长的问提图片?平时小项目写个定时器都不 考虑会不不执行时间过长原因 ,第一次还没执行完就执行第二次,其他同学歌词 面对千亿的数据量觉得 越来越考虑这种问提图片?

这种问提图片中一个多多多多错误,交易额是日几十亿而都不 交易量几十亿次,订单量远远越来越到达这种量级。数据迁移当然考虑了迁移时间,在整个项目迁移日后 我觉得原因 进行过全都次的小规模迁移了,并都不 第一次迁移,这种文章中也说明了,这种提问者明显越来越看到就来喷了。

这种迁移程序池池在干这次大活日后 ,我觉得原因 经历多次考验了,全都从有四种 程度上来讲这次出问提图片,轻视也是问提图片发生的原因 之一。

不但原因 多次使用,在正式迁移日后 也安排进行了多次的验证,全都做为管理者越来越和程序池池员同時 深入排查次责细节,发生次责管理失职。

另外有的读者说为那些不使用程序池池,我强调一下整个迁移项目使用了程序池池,全都还都不 仅仅一个多多多程序池池,全都程序池池的最外层越来越使用程序池池,也全都其他同学歌词 里面的除理方案。

我觉得还有全都问提图片,这里不再一一宣布,有的提问真的是太低级,感觉都不 应该是一个多多程序池池池员提出的问提图片。

不过还是有日后 读者会对这种大规模迁移有所了解,这其中涉及的细节觉得 暂且太大,任何一个多多多小的忽略都不 原因 原因 大的问提图片,这种事情越来越方法 在文中一一举例出来。

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

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

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