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

  • 时间:
  • 浏览:3

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

有一种问題含有另另两个错误,交易额是日几十亿而完整都会交易量几十亿次,订单量远远没人到达有一种量级。数据迁移当然考虑了迁移时间,在整个项目迁移以前真是可能进行过所以次的小规模迁移了,并完整都会第一次迁移,有一种文章中也说明了,有一种提问者明显没人看了就来喷了。

有一种迁移应用守护进程在干这次大活以前,真是可能经历多次考验了,所以从有一种程度上来讲这次出问題,轻视也是问題存在的意味着着之一。

不但可能多次使用,在正式迁移以前也安排进行了多次的验证,也不做为管理者没人和应用守护进程员同时深入排查累积细节,存在累积管理失职。

另外有的读者说为哪几种不使用多应用守护进程,我强调一下整个迁移项目使用了多应用守护进程,否则还完整都会仅仅另另另两个应用守护进程,也不应用守护进程的最外层没人使用多应用守护进程,也也不我们 里边的补救方案。

真是还有所以问題,这里不再一一否认,有的提问真的是太低级,感觉完整都会应该是另另两个应用守护进程员提出的问題。

不过还是有有一种读者会对有一种大规模迁移有所了解,这其中涉及的细节你造有一种太满,任何另另两个小的忽略完整都会可能意味着着大的问題,有一种事情没人办法 在文中一一举例出来。

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

哪几种说风凉话的肯定没人做过上千张表新老系统的迁移,还数据库里边件对接,呵呵

最后,还是那句话:保持技术人的那颗初心,一切以补救实际问題为主。