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

  • 时间:
  • 浏览:1
  • 来源:极速快3_快3官网ios版_极速快3官网ios版

前一段时间写了一篇文章《夜半1点突发致命生产事故,人工多多系统进程 来破局!》,好多好多 一篇生产事故的记实文章,没想到在圈内流传甚广,其所含多多系统进程 员对其中的细节特别疑惑,刚好国庆可不必必 和让我们 都 儿再进一步探讨一下。

现在技术圈一1个多不太好的大问题,无缘无故看多一1个多 一1个多大问题,当出現稍微热门好多好多 的文章的前一天,总会出現两级分化的大问题,一拨人会反馈牛逼写得太好了,假如 另一拨人无缘无故反馈又现在开始了了吹牛逼了,各种无脑质疑。

另一方认为一1个多大问题虽然也有太客观,一篇文章的出現好多好多 作者另一方对于技术的阐述,难免有自身的局限,同样既然能写文章必然好多好多 会是瞎乱吹牛逼,那毕竟也有同事让我们 都 都认识,上边需要在什儿 行业混。

既然文章肯定具有它的局限性,假如 写出来读者可不必必 给出好多好多 更好的建议,一1个多 对于写文章的人也是五种生活学习,我无缘无故从读者的留言中学到了好多好多 知识,这是五种生活正反馈。

现在的大问题是好多好多 技术人把抬杠当作了五种生活本事,用以展示另一方的优越感,假如 能说到点子上也还好,关键是有的留言你一看就可不必必 发现,技术涵养太低了明显是不懂行的情况报告。

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

大问题 1:“几百万商户、几千个代理商”,“上千多张表,关系极为僵化 ”,“在生产环境找十台服务器”至少也得是淘宝,京东什儿 级别的电商网站不必 有什儿 规模了吧!

回复:淘宝、京东到底有有十几个 商户我还真不太清楚,好多好多 不敢妄言,但请五种生活轻易低估一家排名靠前的第三方支付公司的数据量,假如 历史堆积、外放通道等各种由于,这点数据还是有的。

至于在生产环境找十台服务器,什儿 操作应该是随随便便的一1个多中型互联网公司都能学会英语的,前一天公司至少用了 500-500 太服务器,从中找个10台也有啥大问题。

大问题2 :吹哪此牛逼,难道贵公司是淘宝,拼多多?淘宝也就几百万商户,还日均 40 亿的交易量,用 Spring Cloud 几百个微服务撑不起都没人大的体量。

回复:淘宝也就几百万商户什儿 数据准确吗?所含个体小微商户?

日均 40 亿的交易额在线下收单什儿 行业这不算高,下面这张是网传收单机构2019年7月交易量排名截图,排名第 10 就假如 不止什儿 交易量了。

用 Spring Cloud 几百个微服务撑不起都没人大的体量什儿 大问题,就明显是一1个多外行得都没人再外行的大问题了,让我姑且不说有有十几个 成功案例了,就什儿 评估方式好多好多 低级的。

都没人说哪个技术可不必必 支持有十几个 体量假如 都没人支持有十几个 体量,要评估什儿 大问题,需要看是哪此样的团队在哪此样的场景以哪此样的方式来使用次技术。技术五种生活五种生活能决定能支撑多大体量,最重要的是看你缘何用它。

大问题3:我缘何看这是数据库工程师的工作,为哪此需要写多多系统进程 迁移呢?

什儿 看好多好多 技术小白了,从一1个多非常老的系统迁移到一1个多全部的新系统,这其中的业务变化、逻辑变化有有十几个 ?假如 能让 DBA 直接迁移得话,那什儿 系统有多简单?

且不说什儿 系统涉及尽千张表,前一天老系统的架构和新系统的架构差别有多大, 最重要的是什儿 新系统上边还跟了一1个多大数据平台,大数据平台需要根据新系统的 Binlog 日志,做相关数据的逻辑操作。

好多好多 从读者提问五种生活来讲,就能看出根本不明白什儿 难点在哪里。

大问题4:为哪此不建一1个多和益产 1:1 的环境来模拟测试呢?

一般情况报告下研发会有1个环境来测试:

  • DEV 开发环境,研发人员开发完成自行测试环境。
  • SIT 集成测试环境,将另一方项目上传到 sit 一般就进入测试部测试阶段了,整体集成测试。
  • UAT 客户集成测试环境,一般可不必必 做内控 相互战略合作商对接的准生产环境,要尽假如 的和益产环境保持一致。
  • PRO 生产环境,什儿 让我们 都 儿都清楚,好多好多 真正项目要运行的环境。

读者说的1:1 环境,应该好多好多 需要 UAT 和 PRO 的环境尽假如 的保持一致,这是一1个多比较理想的情况报告,估计都没人要素有钱的互联网公司可不必必 真正实现。

让我们 都 儿做一1个多中型的互联网公司,每年在 IDC 上边的花费至少在几千万,假如 要全部 1:1 的模拟生产环境,每年的花费至少在50000万以上,中型互联网公司都没人说服老板去干这件事情。

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

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

至于属不属于作坊式的阶段我不反驳,流程上肯定是有过低的什儿 我认可,但并也有一1个多多多系统进程 员写一1个多接口做几十亿的系统迁移,如居然的是一1个多 那还需要留 20 号的人在这里干嘛。

都没人大级别的数据迁移肯定是一1个多系统性的工程,并也有1、一1个多多多系统进程 员可不必必 负责的,假如 迁移多多系统进程 的发起入口用 1、2 多多系统进程 员负责足以,上边需要调用 N 个系统的接口配合来完成整体的工作。

大问题6 :我虽然什儿 错误犯得很低级 日数据量达到几十亿次的应用 居然没考虑到数据量过大迁移耗时太长的大问题?平时小项目写个定时器也有考虑会不必执行时间过长由于,第一次还没执行完就执行第二次,让我们 都 面对千亿的数据量居然都没人考虑什儿 大问题?

什儿 大问题中一1个多错误,交易额是日几十亿而也有交易量几十亿次,订单量远远都没人到达什儿 量级。数据迁移当然考虑了迁移时间,在整个项目迁移前一天虽然假如 进行过好多好多 次的小规模迁移了,并也有第一次迁移,什儿 文章中也说明了,什儿 提问者明显都没人看多就来喷了。

什儿 迁移多多系统进程 在干这次大活前一天,虽然假如 经历多次考验了,好多好多 从五种生活程度上来讲这次出大问题,轻视也是大问题位于的由于之一。

不但假如 多次使用,在正式迁移前一天也安排进行了多次的验证,好多好多 做为管理者都没人和多多系统进程 员一起去深入排查要素细节,位于要素管理失职。

另外有的读者说为哪此不使用多多系统进程 ,我强调一下整个迁移项目使用了多多系统进程 ,假如 还也有仅仅一1个多多系统进程 ,好多好多 多多系统进程 的最外层都没人使用多多系统进程 ,也好多好多 让我们 都 儿上边的处理方案。

虽然还有好多好多 大问题,这里不再一一否认,有的提问真的是太低级,感觉也有应该是一1个多多多系统进程 员提出的大问题。

不过还是有好多好多 读者会对什儿 大规模迁移有所了解,这其中涉及的细节居然五种生活过多,任何一1个多小的忽略也有假如 由于大的大问题,什儿 事情都没人方式在文中一一举例出来。

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

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

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