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

前一段时间写了一篇文章《凌晨1点突发致命生产事故，人工多线程来破局！》，只是一篇生产事故的记实文章，没想到在圈内流传甚广，其中有程序员对其中的细节有点疑惑，恰好国庆能够和你们再进一步探讨一下。

如今技术圈有一个不太好的现象，常常看到这样一个现象，当出现稍微热门一点的文章的时候，总会出现两级分化的现象，一拨人会反馈牛逼写得太好了，而后另外一拨人老是反馈又开始吹牛逼了，各类无脑质疑。

我的认为两个现象其实都不太客观，一篇文章的出现只是做者本人对于技术的阐述，不免有自身的局限，一样既然能写文章必然也不会是瞎乱吹牛逼，那毕竟也有同事朋友都认识，后面还要在这个行业混。

既然文章确定具备它的局限性，若是写出来读者能够给出一些更好的建议，这样对于写文章的人也是一种学习，我常常从读者的留言中学到了不少知识，这是一种正反馈。

如今的问题是不少技术人把抬杠看成了一种本事，用以展现本身的优越感，若是能说到点子上也还好，关键是有的留言你一看就能够发现，技术涵养过低了明显是不懂行的状况。

这篇文章发出来后，公众号的用户反馈还能够，由于你们对我有个基本认识，在博客园和开源中国中，部分技术朋友质疑比较多的地方给予解释一下：

问题 1：“几百万商户、几千个代理商”，“上千多张表，关系极为复杂”，“在生产环境找十台服务器”至少也得是淘宝，京东这个级别的电商网站才能有这个规模了吧！

回复：淘宝、京东到底有多少商户我还真不太清楚，因此不敢妄言，但请不要轻易低估一家排名靠前的第三方支付公司的数据量，因为历史堆积、外放通道等各类缘由，这点数据仍是有的。

至于在生产环境找十台服务器，这种操做应该是随随便便的一个中型互联网公司都能搞定的，以前公司至少用了 300-400 太服务器，从中找个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 的模拟生产环境，每一年的花费大概在1000万以上，中型互联网公司很难说服老板去干这件事情。

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

使用 Servlet 一点都不过期，如今企业级开发90%的公司都使用的是 Spring MVC 吧，Spring MVC 就是 Servlet 包装出来了，很过期吗？

至于属不属于做坊式的阶段我不反驳，流程上确定是有缺陷的这个我承认，但并非一个程序员写一个接口作几十亿的系统迁移，若是真的是这样那还须要留 20 号的人在这里干吗。

这么大级别的数据迁移确定是一个系统性的工程，并非一、2个程序员能够负责的，可是迁移程序的发起入口用 一、2 程序员负责足以，中间须要调用 N 个系统的接口配合来完成总体的工做。

问题6 ：我以为这个错误犯得很低级 日数据量达到几十亿次的应用 竟然没考虑到数据量过大迁移耗时太长的问题？平时小项目写个定时器都会考虑会不会执行时间过长致使，第一次还没执行完就执行第二次，大家面对千亿的数据量竟然没有考虑这个问题？

这个问题中有一个错误，交易额是日几十亿而不是交易量几十亿次，订单量远远没有到达这个量级。数据迁移固然考虑了迁移时间，在整个项目迁移以前其实已经进行过不少次的小规模迁移了，并非第一次迁移，这个文章中也说明了，这个提问者明显没有看完就来喷了。

这个迁移程序在干此次大活以前，其实已经经历屡次考验了，因此从某种程度上来说此次出问题，轻视也是问题发生的缘由之一。

不但已经屡次使用，在正式迁移以前也安排进行了屡次的验证，只是作为管理者没有和程序员一块儿深刻排查部分细节，存在部分管理失职。

另外有的读者说为何不使用多线程，我强调一下整个迁移项目使用了多线程，而且还不是仅仅一个多线程，只是程序的最外层没有使用多线程，也就是咱们后面的补救方案。

其实还有不少问题，这里再也不一一回应，有的提问真的是过低级，感受都不该该是一个程序员提出的问题。

不过仍是有一些读者会对这种大规模迁移有所了解，这其中涉及的细节简直不要太多，任何一个小的忽略都有可能致使大的问题，这种事情没有办法在文中一一举例出来。

不过我以为有一位读者的回复我比较承认：

那些说风凉话的确定没有作过上千张表新老系统的迁移，还数据库中间件对接，呵呵

最后，仍是那句话：保持技术人的那颗初心，一切以解决实际问题为主。