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

  • 时间:
  • 浏览:0
  • 来源:幸运快3_快3下载app送28_幸运快3下载app送28

前一段时间写了一篇文章《深夜1点突发致命生产事故,人工线程来破局!》,之后一篇生产事故的记实文章,没想到在圈内流传甚广,其所含线程员对其中的细节有点痛 疑惑,刚好国庆需用和亲戚亲戚你们再进一步探讨一下。

现在技术圈有另一个 不太好的问题图片图片,无缘无故看得人之后另一个 问题图片图片,当总出 稍微热门或多或少的文章的之后 ,总会总出 两级分化的问题图片图片,一拨人会反馈牛逼写得太好了,为甚让另一拨人无缘无故反馈又刚开始了了吹牛逼了,各种无脑质疑。

所有人 认为另一个 问题图片图片随便说说全是太客观,一篇文章的总出 之后作者所有人 对于技术的阐述,难免有自身的局限,同样既然能写文章必然以不会是瞎乱吹牛逼,那毕竟全是同事亲戚亲戚你们都认识,上端需用在或多或少行业混。

既然文章肯定具有它的局限性,可能性写出来读者需用给出或多或少更好的建议,之后对于写文章的人也是本身学习,我无缘无故从读者的留言中学到了之后有知识,这是本身正反馈。

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

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

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

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

至于在生产环境找十台服务器,或多或少操作应该是随随便便的另一个 中型互联网公司都能搞掂的,之后 公司共要用了 60 -60 太服务器,从中找个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 的模拟生产环境,每年的花费共要在60 0万以上,中型互联网公司不难 说服老板去干这件事情。

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

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

至于属不属于作坊式的阶段我不反驳,流程上肯定是有过低的或多或少我认可,但并全是另一个 线程员写另一个 接口做几十亿的系统迁移,可能性真的是之后那还需用留 20 号的人在这里干嘛。

不难 大级别的数据迁移肯定是另一个 系统性的工程,并全是1、另一个 线程员需用负责的,为甚让迁移线程的发起入口用 1、2 线程员负责足以,上端需用调用 N 个系统的接口配合来完成整体的工作。

问题图片图片6 :我随便说说或多或少错误犯得很低级 日数据量达到几十亿次的应用 果真没考虑到数据量过大迁移耗时太长的问题图片图片?平时小项目写个定时器总要考虑会无需执行时间过长原困,第一次还没执行完就执行第二次,亲戚亲戚你们面对千亿的数据量果真不难 考虑或多或少问题图片图片?

或多或少问题图片图片所含另一个 错误,交易额是日几十亿而全是交易量几十亿次,订单量远远不难 到达或多或少量级。数据迁移当然考虑了迁移时间,在整个项目迁移之后 随便说说可能性进行过之后有次的小规模迁移了,并全是第一次迁移,或多或少文章中也说明了,或多或少提问者明显不难 看得人就来喷了。

或多或少迁移线程在干这次大活之后 ,随便说说可能性经历多次考验了,之后有从本身程度上来讲这次出问题图片图片,轻视也是问题图片图片所处的原困之一。

不但可能性多次使用,在正式迁移之后 也安排进行了多次的验证,之后做为管理者不难 和线程员一同深入排查每项细节,所处每项管理失职。

另外有的读者说为那些不使用线程,我强调一下整个迁移项目使用了线程,为甚让还全是仅仅另一个 线程,之后线程的最外层不难 使用线程,也之后亲戚亲戚你们上端的正确处理方案。

随便说说还有之后有问题图片图片,这里不再一一敲定,有的提问真的是太低级,感觉全是应该是另一个 线程员提出的问题图片图片。

不过还是有或多或少读者会对或多或少大规模迁移有所了解,这其中涉及的细节果真过多过多,任何另一个 小的忽略全是可能性原困大的问题图片图片,或多或少事情不难 办法在文中一一举例出来。

不过我随便说说有一位读者的回复我比较认可:

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

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