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

  • 时间:
  • 浏览:0
  • 来源:极速快3_快3计划三期必中_极速快3计划三期必中

前一段时间写了一篇文章《半夜三更三更1点突发致命生产事故,人工多系统进程运行来破局!》,后来一篇生产事故的记实文章,没想到在圈内流传甚广,其包含系统进程运行员对其中的细节有点儿疑惑,刚好国庆时候 和大伙儿儿再进一步探讨一下。

现在技术圈有有好几次 不太好的你这些 的疑问,老会 想看 后来有好几次 你这些 的疑问,当老会 出现稍微热门有些的文章的时候,总会老会 出现两级分化的你这些 的疑问,一拨人会反馈牛逼写得太好了,后来另一拨人老会 反馈又时候时候刚开始 了了吹牛逼了,各种无脑质疑。

此人 认为有好几次 你这些 的疑问嘴笨 就有太客观,一篇文章的老会 出现后来作者此人 对于技术的阐述,难免有自身的局限,同样既然能写文章必然后来会是瞎乱吹牛逼,那毕竟就有同事大伙儿儿都认识,后面 须要在你这些 行业混。

既然文章肯定具有它的局限性,将会写出来读者时候 给出有些更好的建议,后来对于写文章的人也是五种 学习,我老会 从读者的留言中学到了全都知识,这是五种 正反馈。

现在的你这些 的疑问是全都技术人把抬杠当作了五种 本事,用以展示此人 的优越感,将会能说到点子上也还好,关键是有的留言你一看就时候 发现,技术涵养太低了明显是不懂行的状态。

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

你这些 的疑问 1:“几百万商户、几千个代理商”,“上千多张表,关系极为繁杂”,“在生产环境找十台服务器”至少也得是淘宝,京东你这些 级别的电商网站我太满 有你这些 规模了吧!

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

至于在生产环境找十台服务器,你这些 操作应该是随随便便的有好几次 中型互联网公司都能拿出的,时候公司至少用了 30-30 太服务器,从中找个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 的模拟生产环境,每年的花费至少在30万以上,中型互联网公司不能自己说服老板去干这件事情。

你这些 的疑问5 :更别提都啥时代了还 servlet,从描述的技术方案和处置流程来看,基本属于作坊式的阶段,有好几次 系统进程运行员写有好几次 接口就能做日均几十亿交易的系统迁移了,呵呵。

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

至于属不属于作坊式的阶段我不反驳,流程上肯定是有缺陷的你这些 我认可,但并就有有好几次 系统进程运行员写有好几次 接口做几十亿的系统迁移,将会真的是后来那还须要留 20 号的人在这里干嘛。

这样大级别的数据迁移肯定是有好几次 系统性的工程,并就有1、有好几次 系统进程运行员时候 负责的,后来迁移系统进程运行的发起入口用 1、2 系统进程运行员负责足以,后面 须要调用 N 个系统的接口配合来完成整体的工作。

你这些 的疑问6 :我嘴笨 你这些 错误犯得很低级 日数据量达到几十亿次的应用 嘴笨 没考虑到数据量过大迁移耗时太长的你这些 的疑问?平时小项目写个定时器时候 考虑会我太满 执行时间过长原因分析,第一次还没执行完就执行第二次,大伙儿儿面对千亿的数据量嘴笨 这样考虑你这些 你这些 的疑问?

你这些 你这些 的疑问包包含好几次 错误,交易额是日几十亿而就有交易量几十亿次,订单量远远这样到达你这些 量级。数据迁移当然考虑了迁移时间,在整个项目迁移时候嘴笨 将会进行过全都次的小规模迁移了,并就有第一次迁移,你这些 文章中也说明了,你这些 提问者明显这样想看 就来喷了。

你这些 迁移系统进程运行在干这次大活时候,嘴笨 将会经历多次考验了,全都从五种 程度上来讲这次出你这些 的疑问,轻视也是你这些 的疑问居于的原因分析之一。

不但将会多次使用,在正式迁移时候也安排进行了多次的验证,后来做为管理者这样和系统进程运行员一齐深入排查每种细节,居于每种管理失职。

另外有的读者说为你这些 不使用多系统进程运行,我强调一下整个迁移项目使用了多系统进程运行,后来还就有仅仅有好几次 多系统进程运行,后来系统进程运行的最外层这样使用多系统进程运行,也后来大伙儿儿后面 的处置方案。

嘴笨 还有全都你这些 的疑问,这里不再一一表态,有的提问真的是太低级,感觉就有应该是有好几次 系统进程运行员提出的你这些 的疑问。

不过还是有有些读者会对你这些 大规模迁移有所了解,这其中涉及的细节嘴笨 何必 太满,任何有好几次 小的忽略就有将会原因分析大的你这些 的疑问,你这些 事情这样最好的办法在文中一一举例出来。

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

你这些 说风凉话的肯定这样做过上千张表新老系统的迁移,还数据库后面 件对接,呵呵

最后,还是那句话:保持技术人的那颗初心,一切以处置实际你这些 的疑问为主。