性能优化的另类思考

  软件工程，其实是一件工程性质的问题，但是在大众的眼里看来，这貌似是一件技术性工作的事情。
  在我写代码的感受中，写代码完全不像是件技术工作，更像是件建筑工人干的活一样，反倒在对于需求的梳理和整理成实际的设计方案才更像是件技术工作，甚至在设计的过程中，技术从来不是C位，更多是件辅助性的工具，真正起作用的是通过技术实现产品需求的工程思维才是最重要，直到我遇到一件性能优化的问题之后，更加加深我对这种想法的认同。
  在区块链技术中，用户的金额是寄存在链上的一个地址上的，因此要去获取用户钱包有多少钱是需要去通过网络去进行访问的，同时用户每个不同币种的地址都是不一样，也就是说一个用户如果有10个币种，就会10个地址，而最麻烦的一点就在于，区块链的转账操作不会通知服务器，因此检查用户钱包是否钱转进来，就不得不轮询用户的所有钱包地址。
  在项目的早期，用户的数量和币种的数量还是比较少的，问题也不大，但是在后续项目的开展中，用户的数量不断增加，当用户的数量到上万了，这时需要轮询的网络请求就达到了好几万，同时假设后续要进行引入币种和用户，这个数字还会不断地上涨，可想而知，这里的问题会不断地变大的，就像一个不断变大的不定时炸弹。。。仿佛可以看到研发的头稍稍有点亮。
  对应的解决方案，可以从物理层面去处理这个问题，最简单的就是继续增加区块链服务器进行分摊压力，但是这无疑增加设备成本，技术成本和管理难度，这只能治标不治本。那还能从其他角度入手这个烫手山芋呢？如果把角度上升到到工程的层面，可以发现不一样的视野。
  从工程的层面上看，会发现实际上，系统在轮询用户钱包的时候，绝大多数的请求都是在做“无用功”，因为绝大多数的地址都不会有充值操作的。系统其实只要关注那些有充值行为的地址就行，而这些地址在单位时间内其实也就那么几个而已，这样就可以将上万个请求缩减为几个请求了。
  那么，要怎么去确定都有谁去充值呢？回顾到整个产品的使用操作，会发现凡是要充值的人，都必定要打开app中二维码地址，那么，系统不就可以根据这个锚点去锁定目标人群了吗？将其加入热点充值人群去遍历用户的地址，就大大减少了轮询数量。同时，考虑到可能会出现漏掉的情况，在app终端上，加入一个类似“催账”功能的按钮，或是在运营后台增加相关入口，将相关用户的地址加入轮询队列，不就可以做到补漏。
  一个简单又高效的解决方案，甚至都不需要什么高超牛逼的技术，甚至我觉得这个解决方案让一个没有技术背景的产品都可以想出来。那能说这个产品技术很牛逼吗？显然这说法是有点问题的。
  归根究底，就是因为软件的问题，从来都不是一个纯粹的技术问题，而是一个实实在在的工程问题，当我们在遇到困难的时候，不要妄想有万能的技术去解决我们的问题，而是应当从工程的角度去看待问题，从产品、用户、客户不同的角度才能看清一个系统的问题，开阔了视野，才有更多的方法。