zoukankan      html  css  js  c++  java
  • 我来悟微服务(3)-需求管理

    无限合并

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  • 相关阅读:
    AddTransient、AddSingleton、AddScoped的区别
    ASP.NET Core Linux下为 dotnet 创建守护进程(必备知识)
    DotNetCore 结合 Nginx 将网站部署到阿里云
    centos7安装配置mysql8
    centos7安装nginx
    ASP.NET Core搭建多层网站架构【0-前言】
    .Net Core3.0 WebApi 二:API 文档神器 Swagger
    .Net Core3.0 WebApi 三:读取appsettings.json
    .Net Core3.0 WebApi 四:JWT权限验证
    vue动态配置参数,避免重复打包
  • 原文地址:https://www.cnblogs.com/fancunwei/p/9521316.html
Copyright © 2011-2022 走看看