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

  • 时间:
  • 浏览:0
  • 来源:5分时时彩官网_去哪玩5分时时彩_哪里可以玩5分时时彩

前一段时间写了一篇文章《半夜三更三更1点突发致命生产事故,人工多应用应用程序来破局!》,本来 一篇生产事故的记实文章,没想到在圈内流传甚广,其暗含应用应用程序员对其中的细节一阵一阵疑惑,刚好国庆都只有和亲们儿再进一步探讨一下。

现在技术圈另另一个不太好的难题,一老会 想看 没法 另另一个难题,当出現稍微热门许多的文章的很久 ,总会出現两级分化的难题,一拨人会反馈牛逼写得太好了,因此另一拨人一老会 反馈又现在结束吹牛逼了,各种无脑质疑。

他们认为另另一个难题虽然 不会太客观,一篇文章的出現本来 作者他们对于技术的阐述,难免有自身的局限,同样既然能写文章必然本来 会是瞎乱吹牛逼,那毕竟不会同事亲们都认识,上方只有在这个行业混。

既然文章肯定具有它的局限性,可能性写出来读者都只有给出许多更好的建议,没法 对于写文章的人也是这个学习,我一老会 从读者的留言中学到了许多知识,这是这个正反馈。

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

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

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

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

至于在生产环境找十台服务器,这个操作应该是随随便便的另另一个中型互联网公司都能拿出的,很久 公司离米 用了 150-150 太服务器,从中找个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 的模拟生产环境,每年的花费离米 在11150万以上,中型互联网公司没法说服老板去干这件事情。

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

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

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

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

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

这个难题中另另一个错误,交易额是日几十亿而不会交易量几十亿次,订单量远远没法到达这个量级。数据迁移当然考虑了迁移时间,在整个项目迁移很久 虽然 可能性进行过许多次的小规模迁移了,并不会第一次迁移,这个文章中也说明了,这个提问者明显没法想看 就来喷了。

这个迁移应用应用程序在干这次大活很久 ,虽然 可能性经历多次考验了,许多从这个程度上来讲这次出难题,轻视也是难题趋于稳定的原应之一。

不但可能性多次使用,在正式迁移很久 也安排进行了多次的验证,本来 做为管理者没法和应用应用程序员同去深入排查主次细节,趋于稳定主次管理失职。

另外有的读者说为那些不使用多应用应用程序,我强调一下整个迁移项目使用了多应用应用程序,因此还不会仅仅另另一个应用应用程序,本来 应用应用程序的最外层没法使用多应用应用程序,也本来 亲们儿上方的补救方案。

虽然 还有许多难题,这里不再一一组阁 ,有的提问真的是太低级,感觉不会应该是另另一个应用应用程序员提出的难题。

不过还是有许多读者会对这个大规模迁移有所了解,这其中涉及的细节果真无须太久,任何另另一个小的忽略不会可能性原应大的难题,这个事情没法土办法在文中一一举例出来。

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

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

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