规整数据的重要性

对于后端而言,无论前端是否校验了表单(前端可能出于用户体验会做校验),后端都必须校验一次。并且在数据有问题时及时终止 处理。常见的请求处理如下:

请求 -> Web后端 -> 服务1
                <-
                -> 服务2
     <-         <-
            -> 异步任务
                -> 服务3
                <-

如果我们不在最开始就将数据处理成规整的、统一的结构,那么在异步任务处,还需要再次做各种校验,尤其是当异步任务大量使用 到web后端接收到的参数时。

因此,在web后端接受到参数时,就应当将数据处理好,拒绝不正常的请求和参数。为其后所有的处理提供一个规整的、统一的、干净 的参数。

于此同时,有另外一个让人忧心。当服务的数量多起来之后(微服务拆分可以将服务数量骤然提升,因业务本身数量增加也会导致服务数量 增加),服务与服务之间是否能够相互信任?他们是否需要校验对方的参数?是否需要:

  • 无条件的相信对方的参数?
  • 需要验签?

如果验签,那么务必保证大家的验签算法都一致、足够安全、足够简单。否则人手一套验签算法,只会耗费无数心力。更好的方式,仍然 是在整个流量进入的最开始,就处理好,其后将不同的服务划分成不同的服务群。服务群处在同一个VPC里,它们之间相互信任。服务群 之间可以选择进行一些校验。

另外服务多起来之后,还会面临一个与此话题无关的话题,随着函数请求变成了网络请求,请求的返回状态数量骤增,而状态判断则是 所有网络调用可能返回状态的组合。要在一群不可靠的服务间构建可靠的服务,很难。而如果信任这些服务,那么服务的质量则会受底层 服务质量所影响。

最后,就让我无脑的结束这个话题。提前规整数据,看起来多耗费了心力,但长远看来,省了很多心力。


微信公众号
关注公众号,获得及时更新

更多文章
  • 后端工程师学前端(四): CSS进阶(盒子模型)
  • 读《投资中最简单的事》
  • 后端工程师学前端(三): CSS进阶(特指度、单位和字体族)
  • 后端工程师学前端(二): CSS基础知识(规则与选择器)
  • Swift语法笔记
  • 后端工程师学前端(一): HTML
  • 读《管理的实践》
  • frp 源码阅读与分析(二):TCP内网穿透的实现
  • 五天不用微信 - 爽得很
  • frp 源码阅读与分析(一):流程和概念
  • 学习frp源码之简洁的在两个connection之间转发流量
  • 自己动手写一个反向代理
  • 读《债务危机》
  • 从XMonad迁移到i3
  • 服务器IP被ban学到的经验