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

  • 时间:
  • 浏览:1
  • 来源:幸运快3_快3公式_幸运快3公式

前一段时间写了一篇文章《夜里1点突发致命生产事故,人工线程来破局!》,就是一篇生产事故的记实文章,没想到在圈内流传甚广,其富含线程员对其中的细节有点痛 疑惑,刚好国庆都太少再 和亲戚我们都都都我们都都都我们都都都我们都都都再进一步探讨一下。

现在技术圈有有另有两个不太好的大大问题,一个劲 看过另有另有两个有另有两个大大问题,当再次出现稍微热门你什儿 的文章的之后,总会再次出现两级分化的大大问题,一拨人会反馈牛逼写得太好了,就是另一拨人一个劲 反馈又刚现在开始吹牛逼了,各种无脑质疑。

自己认为有另有两个大大问题嘴笨 完全都是太客观,一篇文章的再次出现就是作者自己对于技术的阐述,难免有自身的局限,同样既然能写文章必然就是会是瞎乱吹牛逼,那毕竟完全都是同事亲戚我们都都都我们都都都我们都都都我们都都都我们都都都我们都都都认识,里面沒有在你什儿 行业混。

既然文章肯定具有它的局限性,就是写出来读者都太少再 给出你什儿 更好的建议,另有另有两个对于写文章的人也是有一种学习,我一个劲 从读者的留言中学到了你什儿 知识,这是有一种正反馈。

现在的大大问题是你什儿 技术人把抬杠当作了有一种本事,用以展示自己的优越感,就是能说到点子上也还好,关键是有的留言你一看就都太少再 发现,技术涵养太低了明显是不懂行的情况汇报。

这篇文章发出来后,公众号的用户反馈还都太少再 ,就是亲戚我们都都都我们都都都我们都都都我们都都都对我有个基本认识,在博客园和开源中国中,每段技术亲戚我们都都都我们都都都我们都都都我们都都都质疑比较多的地方给予解释一下:

大大问题 1:“几百万商户、几千个代理商”,“上千多张表,关系极为僵化 ”,“在生产环境找十台服务器”大概也得是淘宝,京东你什儿 级别的电商网站太少再 有你什儿 规模了吧!

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

至于在生产环境找十台服务器,你什儿 操作应该是随随便便的有另有两个中型互联网公司都能甩掉的,之后公司大概用了 150-150 太服务器,从中找个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 的模拟生产环境,每年的花费大概在11150万以上,中型互联网公司很难说服老板去干这件事情。

大大问题5 :更别提都啥时代了还 servlet,从描述的技术方案和处理流程来看,基本属于作坊式的阶段,有另有两个线程员写有另有两个接口就能做日均几十亿交易的系统迁移了,呵呵。

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

至于属不属于作坊式的阶段我不反驳,流程上肯定是有不足英文的你什儿 我认可,但并完全都是有另有两个线程员写有另有两个接口做几十亿的系统迁移,就是真的是另有另有两个那还沒有留 20 号的人在这里干嘛。

沒有大级别的数据迁移肯定是有另有两个系统性的工程,并完全都是1、有另有两个线程员都太少再 负责的,就是迁移线程的发起入口用 1、2 线程员负责足以,里面沒有调用 N 个系统的接口配合来完成整体的工作。

大大问题6 :我嘴笨 你什儿 错误犯得很低级 日数据量达到几十亿次的应用 你以为没考虑到数据量过大迁移耗时太长的大大问题?平时小项目写个定时器完全都是考虑会太少再执行时间过长原因,第一次还没执行完就执行第二次,亲戚我们都都都我们都都都我们都都都我们都都都面对千亿的数据量你以为沒有考虑你什儿 大大问题?

你什儿 大大问题暗富含另有两个错误,交易额是日几十亿而完全都是交易量几十亿次,订单量远远沒有到达你什儿 量级。数据迁移当然考虑了迁移时间,在整个项目迁移之后嘴笨 就是进行过你什儿 次的小规模迁移了,并完全都是第一次迁移,你什儿 文章中也说明了,你什儿 提问者明显沒有看过就来喷了。

你什儿 迁移线程在干这次大活之后,嘴笨 就是经历多次考验了,你什儿 从有一种程度上来讲这次出大大问题,轻视也是大大问题所处的原因之一。

不但就是多次使用,在正式迁移之后也安排进行了多次的验证,就是做为管理者沒有和线程员一同深入排查每段细节,所处每段管理失职。

另外有的读者说为那此不使用线程,我强调一下整个迁移项目使用了线程,就是还完全都是仅仅有有另有两个线程,就是线程的最外层沒有使用线程,也就是亲戚我们都都都我们都都都我们都都都我们都都都里面的处理方案。

嘴笨 还有你什儿 大大问题,这里不再一一宣布,有的提问真的是太低级,感觉完全都是应该是有另有两个线程员提出的大大问题。

不过还是有你什儿 读者会对你什儿 大规模迁移有所了解,这其中涉及的细节你以为并不沒有来太少,任何有另有两个小的忽略完全都是就原因大的大大问题,你什儿 事情沒有办法在文中一一举例出来。

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

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

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