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

  • 时间:
  • 浏览:0

前一段时间写了一篇文章《三更三更半夜1点突发致命生产事故,人工多守护进程来破局!》,什么都 一篇生产事故的记实文章,没想到在圈内流传甚广,其带有 守护进程员对其中的细节特别疑惑,刚好国庆还才能和大伙再进一步探讨一下。

现在技术圈有3个 不太好的现象报告 ,总爱 看到前一天3个 现象报告 ,当总爱 出显稍微热门某些的文章的前一天,总会总爱 出显两级分化的现象报告 ,一拨人会反馈牛逼写得太好了,有随后 另一拨人总爱 反馈又结束了了了英文吹牛逼了,各种无脑质疑。

某些人认为3个 现象报告 真是 都有太客观,一篇文章的总爱 出显什么都 作者某些人对于技术的阐述,难免有自身的局限,同样既然能写文章必然什么都 会是瞎乱吹牛逼,那毕竟都有同事大伙都认识,上端时要在你什儿 行业混。

既然文章肯定具有它的局限性,不可能 写出来读者还才能给出某些更好的建议,前一天对于写文章的人也是有五种学习,我总爱 从读者的留言中学到了什么都 知识,这是有五种正反馈。

现在的现象报告 是什么都 技术人把抬杠当作了有五种本事,用以展示某些人的优越感,不可能 能说到点子上也还好,关键是有的留言你一看就还才能发现,技术涵养太低了明显是不懂行的状态。

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

现象报告 1:“几百万商户、几千个代理商”,“上千多张表,关系极为复杂化”,“在生产环境找十台服务器”共要也得是淘宝,京东你什儿 级别的电商网站才能有你什儿 规模了吧!

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

至于在生产环境找十台服务器,你什儿 操作应该是随随便便的3个 中型互联网公司都能学会英语的,前一天公司共要用了 30-30 太服务器,从中找个10台都有啥现象报告 。

现象报告 2 :吹那此牛逼,难道贵公司是淘宝,拼多多?淘宝也就几百万商户,还日均 40 亿的交易量,用 Spring Cloud 几百个微服务撑不起非要大的体量。

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

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

用 Spring Cloud 几百个微服务撑不起非要大的体量你什儿 现象报告 ,就明显是3个 外行得非要再外行的现象报告 了,我能 姑且不说有几块成功案例了,就你什儿 评估最好的依据什么都 低级的。

非要说哪个技术还才能支持几块体量不可能 非要支持几块体量,要评估你什儿 现象报告 ,时要看是那此样的团队在那此样的场景以那此样的最好的依据来使用次技术。技术有五种太多能决定能支撑多大体量,最重要的是看你为甚用它。

现象报告 3:我为甚看这是数据库工程师的工作,为那此时要写守护进程迁移呢?

你什儿 看什么都 技术小白了,从3个 非常老的系统迁移到3个 全版的新系统,这其中的业务变化、逻辑变化有几块?不可能 能让 DBA 直接迁移一段话,那你什儿 系统有多简单?

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

什么都 从读者提问有五种来讲,就能看出根本不明白你什儿 难点在哪里。

现象报告 4:为那此不建3个 生和熟产 1:1 的环境来模拟测试呢?

一般状态下研发会有3个环境来测试:

  • DEV 开发环境,研发人员开发完成自行测试环境。
  • SIT 集成测试环境,将某些人项目上传到 sit 一般就进入测试部测试阶段了,整体集成测试。
  • UAT 客户集成测试环境,一般还才能做内部内部结构媒体媒体合作商对接的准生产环境,要尽不可能 的生和熟产环境保持一致。
  • PRO 生产环境,你什儿 大伙都清楚,什么都 真正项目要运行的环境。

读者说的1:1 环境,应该什么都 时要 UAT 和 PRO 的环境尽不可能 的保持一致,这是3个 比较理想的状态,估计非要累积有钱的互联网公司还才能真正实现。

大伙做3个 中型的互联网公司,每年在 IDC 上端的花费共要在几千万,不可能 要全版 1:1 的模拟生产环境,每年的花费共要在30万以上,中型互联网公司没能说服老板去干这件事情。

现象报告 5 :更别提都啥时代了还 servlet,从描述的技术方案和处置流程来看,基本属于作坊式的阶段,3个 守护进程员写3个 接口就能做日均几十亿交易的系统迁移了,呵呵。

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

至于属不属于作坊式的阶段我不反驳,流程上肯定是有缺乏的你什儿 我认可,但并都有3个 守护进程员写3个 接口做几十亿的系统迁移,不可能 真的是前一天那还时要留 20 号的人在这里干嘛。

非要大级别的数据迁移肯定是3个 系统性的工程,并都有1、3个 守护进程员还才能负责的,有随后 迁移守护进程的发起入口用 1、2 守护进程员负责足以,上端时要调用 N 个系统的接口配合来完成整体的工作。

现象报告 6 :我真是 你什儿 错误犯得很低级 日数据量达到几十亿次的应用 居然没考虑到数据量过大迁移耗时太长的现象报告 ?平时小项目写个定时器前会考虑会前会执行时间过长原因,第一次还没执行完就执行第二次,大伙面对千亿的数据量居然非要考虑你什儿 现象报告 ?

你什儿 现象报告 带有 3个 错误,交易额是日几十亿而都有交易量几十亿次,订单量远远非要到达你什儿 量级。数据迁移当然考虑了迁移时间,在整个项目迁移前一天真是 不可能 进行过什么都 次的小规模迁移了,并都有第一次迁移,你什儿 文章中也说明了,你什儿 提问者明显非要看到就来喷了。

你什儿 迁移守护进程在干这次大活前一天,真是 不可能 经历多次考验了,什么都 从有五种程度上来讲这次出现象报告 ,轻视也是现象报告 居于的原因之一。

不但不可能 多次使用,在正式迁移前一天也安排进行了多次的验证,什么都 做为管理者非要和守护进程员一块儿深入排查累积细节,居于累积管理失职。

另外有的读者说为那此不使用多守护进程,我强调一下整个迁移项目使用了多守护进程,有随后 还都有仅仅3个 多守护进程,什么都 守护进程的最外层非要使用多守护进程,也什么都 大伙上端的处置方案。

真是 还有什么都 现象报告 ,这里不再一一宣布,有的提问真的是太低级,感觉都有应该是3个 守护进程员提出的现象报告 。

不过还是有某些读者会对你什儿 大规模迁移有所了解,这其中涉及的细节居然太多太多,任何3个 小的忽略都有不可能 原因大的现象报告 ,你什儿 事情非要最好的依据在文中一一举例出来。

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

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

最后,还是那句话:保持技术人的那颗初心,一切以处置实际现象报告 为主。