开发中的一些坑

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

微服务银弹

当前的市面上各种微服务，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。

本文先罗列这些开发中的坑，后续再补充。