上午有一个甲方技术大佬对我产品的技术架构提出了质疑： “你们这个产品还用的MySql？没有分库分表？ 单表数据超过1KW后怎么处理？ 也没有上微服务？”

这让我的思绪一下又回到了2020年。 当时有一个甲方客户，花了我这个产品10倍的价格，也就是120W的高薪，挖了一个大厂技术来做CTO。 上来就大刀阔斧地要将我这套产品的技术架构重构为微服务方案，并为此组织了一支5人的小团队，我这边也全程提供技术协助。

半年后， 微服务方案终于提马上线，并在甲方一款新游戏产品的删档测试中正式使用。 但当两个月的测试结束后，这套微服务方案就彻底被废弃，之后该游戏还是用回了和其他游戏产品一致的原始方案。（也就是我上面这套最初的方案）

目前稳定运行6年，高峰时日活300多W，3台4核8G的服务器完美胜任。 订单表单表数据超2亿，也仅加过一次历史未支付订单定时删除的脚本。

这10年先后做了四五个产品， 虽然每个产品的技术架构都有所迭代和演进， 但最核心的技术架构依然是Mysql+Redis+SpringBoot，外加集群部署，并配合Nginx或LBS服务做一下负载均衡。

当年开发第一款产品时，在技术架构方案的选择上纠结良久。 采用更复杂、承载量更高的方案，开发周期和后续客户方的运维成本都会高不少（因为我们做的是私有化交付）， 毕竟潜在客户大部分都是中小企业，所以还是尽可能简化了技术架构。

现在，虽然每年还会因为这个架构，多次被甲方客户技术团队所质疑， 但在服务过近千家客户近万款游戏产品之后， 早已没有了首次遇到这种质疑时的慌张和焦虑了。