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

  • 时间:
  • 浏览:4
  • 来源:大发快三_快三新平台_大发快三新平台

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

现在技术圈有俩个 不太好的你有些的现象,总是看多原本俩个 你有些的现象,当总是出显稍微热门有些的文章的原本,总会总是出显两级分化的你有些的现象,一拨人会反馈牛逼写得太好了,若果另一拨人总是反馈又开始英语 吹牛逼了,各种无脑质疑。

被委托人认为俩个 你有些的现象嘴笨 都还可以 太客观,一篇文章的总是出显也不作者被委托人对于技术的阐述,难免有自身的局限,同样既然能写文章必然也不必是瞎乱吹牛逼,那毕竟都还可以 同事大伙儿都认识,底下都还可以 在你有些行业混。

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

现在的你有些的现象是也不技术人把抬杠当作了有些本事,用以展示被委托人的优越感,可能性能说到点子上也还好,关键是有的留言你一看就都还可以 发现,技术涵养太低了明显是不懂行的情形。

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

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

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

至于在生产环境找十台服务器,你有些操作应该是随随便便的俩个 中型互联网公司都能拿下的,原本公司合适 用了 100-100 太服务器,从中找个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 的模拟生产环境,每年的花费合适 在100万以上,中型互联网公司真难说服老板去干这件事情。

你有些的现象5 :更别提都啥时代了还 servlet,从描述的技术方案和避免流程来看,基本属于作坊式的阶段,俩个 多多线程 员写俩个 接口就能做日均几十亿交易的系统迁移了,呵呵。

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

至于属不属于作坊式的阶段我不反驳,流程上肯定是有不够的你有些我认可,但不都还可以 俩个 多多线程 员写俩个 接口做几十亿的系统迁移,可能性真的是原本那还都还可以 留 20 号的人在这里干嘛。

越来越 大级别的数据迁移肯定是俩个 系统性的工程,不都还可以 1、俩个 多多线程 员都还可以 负责的,若果迁移多多线程 的发起入口用 1、2 多多线程 员负责足以,底下都还可以 调用 N 个系统的接口配合来完成整体的工作。

你有些的现象6 :我嘴笨 你有些错误犯得很低级 日数据量达到几十亿次的应用 甜得没考虑到数据量过大迁移耗时太长的你有些的现象?平时小项目写个定时器都还可以 考虑会不必执行时间过长是因为分析,第一次还没执行完就执行第二次,大伙儿面对千亿的数据量甜得越来越 考虑你有些你有些的现象?

你有些你有些的现象包含俩个 错误,交易额是日几十亿而都还可以 交易量几十亿次,订单量远远越来越 到达你有些量级。数据迁移当然考虑了迁移时间,在整个项目迁移原本嘴笨 可能性进行过也不次的小规模迁移了,不都还可以 第一次迁移,你有些文章中也说明了,你有些提问者明显越来越 看多就来喷了。

你有些迁移多多线程 在干这次大活原本,嘴笨 可能性经历多次考验了,也不从有些程度上来讲这次出你有些的现象,轻视也是你有些的现象存在的是因为分析之一。

不但可能性多次使用,在正式迁移原本也安排进行了多次的验证,也不做为管理者越来越 和多多线程 员一起去深入排查累积细节,存在累积管理失职。

另外有的读者说为你有些不使用多多多线程 ,我强调一下整个迁移项目使用了多多多线程 ,若果还都还可以 仅仅俩个 多多多线程 ,也太多多线程 的最外层越来越 使用多多多线程 ,也也不大伙儿底下的避免方案。

嘴笨 还有也不你有些的现象,这里不再一一否认,有的提问真的是太低级,感觉都还可以 应该是俩个 多多线程 员提出的你有些的现象。

不过还是有有些读者会对你有些大规模迁移有所了解,这其中涉及的细节甜得太多太多,任何俩个 小的忽略都还可以 可能性是因为分析大的你有些的现象,你有些事情越来越 土土办法在文中一一举例出来。

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

你有些说风凉话的肯定越来越 做过上千张表新老系统的迁移,还数据库底下件对接,呵呵

最后,还是那句话:保持技术人的那颗初心,一切以避免实际你有些的现象为主。