• Zephyr 浏览»

    你这个例子其实正是我不返回错误的原因
    客户点了一份蛋炒饭,但是服务员写成了蛋壳炒饭,后厨接小票时,不是一看小票对服务员说,告诉客户这个不能点,而是跟服务员说,这个你写错了吧,然后去炒了蛋炒饭。下单写的菜是否正确,理论上应该服务员去做,后厨有兜底当然更好,没有的话只要服务员履行好责任也不会有问题

  • KylinShaw 浏览»

    D大说的对,再烂的参数也不能炸,客户走进酒吧点了一桶泡面,点了一份蛋炒饭,但是你的酒吧不能就这么炸了,你直接回复没有就好了,你不能说客户不能这么点单,这么点单不合符规矩。

  • Zephyr 浏览»

    受教了:pray:

  • 88250 浏览»

    从分布式系统、微服务来说各子系统处理自己的数据都要校验,不能只在端用户的业务流程入口处校验。因为有些情况就是上游系统(服务消费者)给的参数就有问题,不能按照明显错误的参数继续处理。另外,抛异常和返回业务错误码是完全不一样的,微服务 RPC 的时候尽量不要抛异常,影响性能不说,最重要的是没法保证语义,统一返回业务错误码是更好的选择。

  • ayoungman 浏览»

    对啊,直接在前端直接限制或者实现校验,就不会出现问题了。
    楼主也说了需要多个系统处理,这就更显现出在数据入口的前端验证更加简单。

  • Zephyr 浏览»

    对于这种上游来的数据,校验返回上游错误也好,抛异常也好,结果都是一样的
    其实我这里主要是想描述下如何将结论说的有理有据而不是就一句话

  • mainlove 浏览»

    肯定是后台要判定 像laket的ORM,建表的长度注解对应存储的数据的格式 是都有校验的
    现在都是分离的情况,不可能让所有系统按照某个标准来
    自己要管好自己的容错率

  • Zephyr 浏览»

    从数据的入口校验不就统一了?

  • 88250 浏览»

    系统大了以后要想稳定,就只能各种 if ,想在某个地方统一校验是不现实的,服务提供者理论上是要校验参数的,至少要保证再烂的参数本系统也不能炸。

  • wuhongxu 浏览»

    个人而言,go很吸引我,没有那么多繁琐的东西,上手就开始写,写command line超级爽,我把他作为我java的补充,以前用nodejs做command line。现在喜欢用Go。爽歪歪