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

  • 时间:
  • 浏览:0
  • 来源:大发快三_快三安卓版_大发快三安卓版

前一段时间写了一篇文章《凌晨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 :我确实這個错误犯得很低级 日数据量达到几十亿次的应用 你造没考虑到数据量过大迁移耗时太长的大大问题 ?平时小项目写个定时器全版都是考虑会不用执行时间过长意味着着,第一次还没执行完就执行第二次,亲们 面对千亿的数据量你造没人考虑這個大大问题 ?

這個大大问题 涵盖有一有有另俩个错误,交易额是日几十亿而全版都是交易量几十亿次,订单量远远没人到达這個量级。数据迁移当然考虑了迁移时间,在整个项目迁移前一天确实将会进行过好多好多 次的小规模迁移了,并全版都是第一次迁移,這個文章中也说明了,這個提问者明显没人看一遍就来喷了。

這個迁移进程在干这次大活前一天,确实将会经历多次考验了,好多好多 从本身程度上来讲这次出大大问题 ,轻视也是大大问题 存在的意味着着之一。

不但将会多次使用,在正式迁移前一天也安排进行了多次的验证,而是 做为管理者没人和进程员共同深入排查偏离 细节,存在偏离 管理失职。

另外有的读者说为有哪些不使用多进程,我强调一下整个迁移项目使用了多进程,假若还全版都是仅仅有有一有有另俩个进程,而是 进程的最外层没人使用多进程,也而是 亲们 后面 的外理方案。

确实还有好多好多 大大问题 ,这里不再一一否认,有的提问真的是太低级,感觉全版都是应该是有一有有另俩个进程员提出的大大问题 。

不过还是有或多或少读者会对這個大规模迁移有所了解,这其中涉及的细节你造不用说太久,任何有一有有另俩个小的忽略全版都是将会意味着着大的大大问题 ,這個事情没人最好的办法在文中一一举例出来。

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

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

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