我来悟微服务(3)-需求管理
无限合并
最近工作上接到一个需求模块：关于账号自动合并的问题。简化来讲，手机1和邮箱1是一个账号，手机1和邮箱2请求过来创建账号时，由于手机号相同，自动合并为一个账号。手机3和邮箱2再过来请求创建账号，由于邮箱相同，自动合并为一个账号。手机3和邮箱4过来请求创建账号时，又因为手机号相同，再次合并为一个账号……假如是个访问量很大并且又这么巧的时候，就类似于无限合并了。实际上可能仅会出现几笔，不会这样无限循环下去。但我是一个容易多想的人。账号合并，又关联着和账号相关的数据的迁移，从我个人的角度来说，这样没有边界防御的需求，我内心是拒绝的，但还没想好更好的办法，暂且如此了。
这个话题联想到微服务，微服务能解决这种问题么？很遗憾，微服务并不是想象中的那么强大。账号合并本质上可以做成一个微服务，但微服务并不能解决这种业务问题。
我认识的微服务是为了方便水平扩展，方便使用体验异构技术，方便快速试错，方便部署，能最终实现高可用高并发。你了解再多的微服务知识，也不是用于解决此类业务问题。
对于此类业务问题，一般方式是判断需求是否合理？不合理的需求可以适当拒绝掉。
再着看是谁提的？如果是普通客户，尽量用其他更简便容易维护的方式代替。如果是金主或上层领导派发需求，那就只能在总结风险的基础上，一步一步往前看吧。
第三看需求是否通用，通用化的解决方案一般是更易理解，更适合推广。定制化得需求是耗时耗力的。
第四判断影响范围，如果是个高风险，又耗时又要牵扯很多旧业务，你敢动么？谨慎谨慎再谨慎。
需求判断阶段完毕，下面说说规避风险
第一，清晰的标注需求影响边界，改动后要及时单元测试或人工测试。你改的任何一行代码都有可能引发一个隐藏的碧游鸡。
第二，不要盲目动刀，一定要分析需求。对需求茫然的情况下，盲目码砖，你会很累的。更有甚者，需求本身只是显示了冰山一角，还有广大的未知冰山底层埋藏。如果不能提前发现，你的时间会越来越短，要做的事反而越来越多。这是一种失控。有时候失控是可预知但必须迎难而上的。有时候又可以轻易靠几句话轻易甩锅的。这本来也是一种修炼。
第三，人员分配。对合作的项目成员要有必要的了解，擅长的人做擅长的事。
第四，会议纪要。有时候频繁地会议是少不了的，有营养的思路应该记录下来方便实践。有疑问应及时去讨论，不要想当然。想当然是最浪费时间的事情。
这些事情和微服务无关。但这些功能最终可以称为一个微服务。这可以理解为微服务开发过程如何识别需求，开发需求的思路。
微服务来源于生活高于生活。
