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

  • 时间:
  • 浏览:0
  • 来源:大发快三_快三预测_大发快三预测

前一段时间写了一篇文章《夜里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 :我我着实这俩错误犯得很低级 日数据量达到几十亿次的应用 岂全是没考虑到数据量过大迁移耗时太长的现象?平时小项目写个定时器全是考虑会无需执行时间过长意味着,第一次还没执行完就执行第二次,一群人面对千亿的数据量岂全是都没法 考虑这俩现象?

这俩现象蕴含 三个白 错误,交易额是日几十亿而全是交易量几十亿次,订单量远远都没法 到达这俩量级。数据迁移当然考虑了迁移时间,在整个项目迁移完后 我我着实意味着进行过所以次的小规模迁移了,并全是第一次迁移,这俩文章中也说明了,这俩提问者明显都没法 看多就来喷了。

这俩迁移程序运行在干这次大活完后 ,我我着实意味着经历多次考验了,所以从四种 程度上来讲这次出现象,轻视也是现象位于的意味着之一。

不但意味着多次使用,在正式迁移完后 也安排进行了多次的验证,不会 做为管理者都没法 和程序运行员一并深入排查主次细节,位于主次管理失职。

另外有的读者说为社 不使用程序运行,我强调一下整个迁移项目使用了程序运行,但会 还全是仅仅三个白 程序运行,不会 程序运行的最外层都没法 使用程序运行,只是会 一群人里面的解决方案。

我我着实还有所以现象,这里不再一一表态 ,有的提问真的是太低级,感觉全是应该是三个白 程序运行员提出的现象。

不过还是有或多或少读者会对这俩大规模迁移有所了解,这其中涉及的细节岂全是并不过多,任何三个白 小的忽略全意味着意味着大的现象,这俩事情都没法 法律法律依据在文中一一举例出来。

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

什么说风凉话的肯定都没法 做过上千张表新老系统的迁移,还数据库里面件对接,呵呵

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