开发中的那些坑

2021-06-30
5分钟阅读时长

本篇文章罗列一些开发业务时遇到的那些坑。

微服务银弹

当前的市面上各种微服务,DDD的课收割了一波又一波的韭菜,有同学听完了课就要迫不及待的尝试一下。学习新知识的动力当然值得肯定,但是具体落地需要根据公司实际场景来。

某前同事找我咨询架构相关的事情,跟他一番交流让我彻底无语了。

这是他们公司 JAVA 架构师落地的方案(2个开发,其中一个还是架构师,真是闹)。姑且不论架构师水平如何,当我看到 2 个后端开发,拆出了 17 个服务时,我的建议是立即开除这个人

我们在一个公司有一定的技术话语权时,想落地我们学到的技术时,一定要根据实际情况来,不能想当然的去横向、纵向拆分服务。

是否拆分微服务条件:

  1. 公司业务是否到了一定规模
  2. 人员数量是否到了一定数量
  3. 服务治理能力是否完备,比如:配置中心,服务注册发现,日志系统等
  4. 是否有了一套完整的监控方案
  5. 持续集成,持续部署能力是否完备
  6. 服务部署是虚拟机还是 kubernetes ? 是否有足够能力运维?
  7. ….

总之,对于业务规模较小的公司,开发人员较少时,一定不要为了拆微服务而去拆,单体服务完全够用。

一个 class 走天下

用这个 case 吐槽下某些 php 程序员。

相信大部分同学都有一定的强迫症,比如:函数的参数个数,函数的行数,每行的最大长度等等。当然这些判断,借助 lint 工具都能完全解决。

对于函数参数的控制,一般正确的做法:抽离程序逻辑,尽量控制函数逻辑。实在不行的可以借助 struct 或者 class 的封装特性,往下传递参数。

不过有些 phper 却借助了 php 的特性,搞了一些骚操作:将所有的参数或者返回值全都放在一个全局的 Class 的 static 变量里面,这样就不需要函数间传递参数了。大概形式如下:

class CommonService
{

    //存储接口的入参
    static public $inputParams = null;
    static public $output = [];
    static public $objMap = [];
    
    //....
}

这个写法有以下这些特点:

  1. 这个 Common Service 基本贯穿了整个业务逻辑
  2. 不同的位置都可能在更改或者读取某个字段

造成的结果:

  1. 不相关的业务逻辑强行耦合
  2. 某些位置刚修改的字段,可能被再次更改
  3. 预期之外的修改将整个逻辑污染
  4. 业务逻辑变得晦涩难懂

其实完全简单的封装就能解决的事情,搞出来的这种代码,让人实在忍不住吐槽。

MySQL 里面全是 json

大部分互联网公司,MySQL 肯定是业务数据库的标配选择,毕竟运维成熟。

我们设计数据库的时候,教科书是让我们至少遵守“第三范式”:

不过真实业务开发中,设计 MySQL 的时候,有的时候为了查询简单,会将某些字段设计成 json, 这样就减少一张关联表的查询。这种设计其实还算是比较合理做法。

但是更多的情况下,很多人把数据库字段设置成 json,美名是为了更好的扩展性。

比如下面这种设计:

由于商品的属性字段是特别多的,不同商品的属性是不固定的。为了扩展性,将商品属性字段全都塞到一个 json 里面,而且 json 也有一套逻辑在里面:aflag 与 bflag 会互相覆盖。

这么设计造成的结果:

  1. 商品属性字段基本处于无法控制的地步
  2. 哪些商品拥有哪些属性是不知道的
  3. 一个商品拥有哪些属性,需要通过一系列复杂的解析,计算才能知道
  4. json 的字段是不确定的,golang/java 解析起来困难

json 字段作为扩展性,这个扩展性是我觉得是值得商榷的,因为大部分场景下能做扩展的字段,基本都是业务逻辑没有想清楚。如果一个表的某个字段是 json 类型,而且 json 里的字段能新增、修改,删除,最终就会造成这个 json 最终变得不可控,早晚走上数据库数据治理的地步。

无脑吹 GraphQL

喜欢看博客或者公众号的同学,对 GraphQL 都不会陌生。看过 GraphqQL 的同学上来就被其特性吸引了。

特性:

  1. 请求你所要的数据不多不少
  2. 获取多个资源只用一个请求
  3. 描述所有的可能类型系统
  4. API 演进无需划分版本

是不是很有吸引力?看到这些特性,我觉得大部分同学都会忍不住尝试下。

我有幸具体落地过 GraphQL,这里就想吐槽一番。

开发流程

GraphQL 是有默认的 Schema 的,这个 Schema 类似于 Protobuf。如果 Client、Server 对不齐这个 Schema 的话,Client 直接获取不到任何数据了。

在使用 http RESTFUL 开发 api 接口时,差不多是这个流程:

但是使用了 GraphQL,需要 Client/Server 双方坐下来,将各个字段都仔细讨论清楚了。了解过 GraphQL 的同学都知道,GraphQL 能从一个类型访问到另外一个任意类型,为了这个实现这个目标,双方讨论字段的过程简直慢的不可想象。可能排期都过去一星期了,字段都没对清楚。

固然字段对清楚对开发结果的反馈是正向的,但是这个 Client/Server 之间的沟通过程真的很慢。

网关

GraphQL 最大的问题就是网关。

客户端使用 Graphql 的最大问题是:客户端只能有一个 Schema。所以当你有多个 Graphql Server 时想对外提供服务时,就需要合并 Schema。目前市面流行的网关 Nginx, APISIX, Kong 都不支持将 Schema 合并。

于是你只能将所有的业务都耦合到同一个 GraphQL 中,无形中将 GraphQL 做成了单体服务。

曾经调研过这个问题,发现只有 JS 提供一个合并 schema 的功能,其他语言基本都没有这个实现。

复杂度

GraphQL 另外一个问题就是对查询复杂度的控制。

GraphQL 可用从一个类型任意查询到任意一个类型。假如没有任何控制的话,客户端一次请求能将所有的数据全都拉取出来。

当时遇到过的一个问题:客户端拉取所有的列表,又将列表中每条记录的详情,通过一次请求全部请求,导致的结果:服务器直接就崩了。

GraphQL 提供了复杂度和深度的控制功能,但是这个复杂度和深度是很难计算的。

综上:不建议项目使用 GraphQL。

本文先罗列这些开发中的坑,后续再补充。 更多学习学习资料分享,关注公众号回复指令:

  • 回复 0,获取 《Go 面经》
  • 回复 1,获取 《Go 源码流程图》

Avatar
HHFCodeRv 欢迎关注我的公众号:HHFCodeRv, 了解我的最新状态。