无限合并

最近工作上接到一个需求模块:关于账号自动合并的问题。简化来讲,手机1和邮箱1是一个账号,手机1和邮箱2请求过来创建账号时,由于手机号相同,自动合并为一个账号。手机3和邮箱2再过来请求创建账号,由于邮箱相同,自动合并为一个账号。手机3和邮箱4过来请求创建账号时,又因为手机号相同,再次合并为一个账号……假如是个访问量很大并且又这么巧的时候,就类似于无限合并了。实际上可能仅会出现几笔,不会这样无限循环下去。但我是一个容易多想的人。账号合并,又关联着和账号相关的数据的迁移,从我个人的角度来说,这样没有边界防御的需求,我内心是拒绝的,但还没想好更好的办法,暂且如此了。

这个话题联想到微服务,微服务能解决这种问题么?很遗憾,微服务并不是想象中的那么强大。账号合并本质上可以做成一个微服务,但微服务并不能解决这种业务问题。

我认识的微服务是为了方便水平扩展,方便使用体验异构技术,方便快速试错,方便部署,能最终实现高可用高并发。你了解再多的微服务知识,也不是用于解决此类业务问题。

对于此类业务问题,一般方式是判断需求是否合理?不合理的需求可以适当拒绝掉。

再着看是谁提的?如果是普通客户,尽量用其他更简便容易维护的方式代替。如果是金主或上层领导派发需求,那就只能在总结风险的基础上,一步一步往前看吧。

第三看需求是否通用,通用化的解决方案一般是更易理解,更适合推广。定制化得需求是耗时耗力的。

第四判断影响范围,如果是个高风险,又耗时又要牵扯很多旧业务,你敢动么?谨慎谨慎再谨慎。

需求判断阶段完毕,下面说说规避风险

第一,清晰的标注需求影响边界,改动后要及时单元测试或人工测试。你改的任何一行代码都有可能引发一个隐藏的碧游鸡。

第二,不要盲目动刀,一定要分析需求。对需求茫然的情况下,盲目码砖,你会很累的。更有甚者,需求本身只是显示了冰山一角,还有广大的未知冰山底层埋藏。如果不能提前发现,你的时间会越来越短,要做的事反而越来越多。这是一种失控。有时候失控是可预知但必须迎难而上的。有时候又可以轻易靠几句话轻易甩锅的。这本来也是一种修炼。

第三,人员分配。对合作的项目成员要有必要的了解,擅长的人做擅长的事。

第四,会议纪要。有时候频繁地会议是少不了的,有营养的思路应该记录下来方便实践。有疑问应及时去讨论,不要想当然。想当然是最浪费时间的事情。

这些事情和微服务无关。但这些功能最终可以称为一个微服务。这可以理解为微服务开发过程如何识别需求,开发需求的思路。

微服务来源于生活高于生活。

首发简书:https://www.jianshu.com/p/ab4f11fb4e77

版权声明:本文为fancunwei原创文章,遵循 CC 4.0 BY-SA 版权协议,转载请附上原文出处链接和本声明。
本文链接:https://www.cnblogs.com/fancunwei/p/9521316.html