本文转载自微信公众号“HHFCodeRv”，作者haohongfan。转载本文请联系HHFCodeRv公众号。本文列举了一些在开发业务时遇到的陷阱。MicroserviceSilverBullet目前市场上有各种各样的微服务。DDD班收获了一波又一波的韭菜。有的同学听完课就迫不及待地想试试了。学习新知识的动力固然值得肯定，但具体落实需要根据公司实际情况而定。一个前同事问我架构相关的问题，和他交流后我彻底无语了。这是他们公司的JAVA架构师的方案（2个开发人员，其中一个还是架构师，好乱）。不管架构师的水平如何，当我看到2个后端开发人员拆掉17个服务时，我的建议是立即解雇这个人。当我们在一个公司的技术上有了一定的话语权后，当我们要把所学的技术落地时，就要根据实际情况去做，不能想当然地把服务横向拆分，纵向拆分。是否拆分微服务条件：公司业务是否达到一定规模，人员数量是否达到一定数量，服务治理能力是否完备，如：配置中心、服务注册发现、日志系统等。是否有一套完整的持续集成监控方案，持续集成部署能力是否完备？服务部署是虚拟机还是kubernetes？是否有足够的运维能力？……总之，对于业务规模小、开发人员少的公司，千万不要为了拆微服务而拆微服务。车身服务是完全足够的。某班走遍天下，用这个案例向一些php程序员吐槽。相信大部分同学都有一定的强迫症，比如：函数的参数个数，函数的行数，每行的最大长度等等。当然，这些判断完全可以借助lint工具来解决。对于函数参数的控制，一般正确的做法是抽取程序逻辑，尽可能控制函数逻辑。如果不行，可以利用struct或class的封装特性，向下传递参数。但是有些phper利用php的特性做了一些取巧的操作：把所有的参数或者返回值放在Class的一个全局静态变量中，这样函数之间就不需要传参了。一般形式如下：classCommonService{//存储接口的入参staticpublic$inputParams=null;staticpublic$output=[];staticpublic$objMap=[];//...}这种写法有如下特点：这个CommonService它基本上贯穿了整个业务逻辑。不同的位置可能会因此更改或读取某个字段：不相关的业务逻辑强行耦合某些位置刚刚修改的字段，并可能再次更改。意外的修改会淹没整个逻辑污染业务逻辑变得晦涩难懂。其实可以通过简单的封装来解决。这种代码不禁让人吐槽。MySQL充满了json。对于大多数互联网公司来说，MySQL一定是企业数据库的标准选择。毕竟运维成熟了。当我们设计数据库时，课本上告诉我们至少要遵守“第三范式”：但是，在实际业务开发中，在设计MySQL时，有时为了查询简单，将一些字段设计成json，这样就节省了一次Query对于关系表。这个设计其实还是蛮合理的。但更多情况下，很多人把数据库字段设置为json，这个名字是为了更好的扩展性。比如下面的设计：由于商品的属性字段非常多，不同商品的属性并不固定。为了扩展性，所有的商品属性字段都塞进了一个json，json里面还有一套逻辑：aflag和bflag会互相覆盖。这样设计的结果：产品的属性字段基本失控。不知道产品有哪些属性，产品有哪些属性。需要一系列复杂的分析计算才能知道json的字段是不确定的。golang/java很难解析。json字段用作可扩展性。这个扩展性我觉得是值得商榷的，因为大部分场景下可以扩展的字段基本上都是没有想清楚的业务逻辑。如果表中的某个字段是json类型的，而json中的字段可以增改删，json最终会变得不可控，迟早会走到数据库数据治理的地步。无脑GraphQL喜欢看博客或者公众号的同学对GraphQL都比较熟悉。看过GraphqQL的同学都会被它的特性所吸引。特点：请求你想要的数据不多也不少获取多种资源一次请求描述所有可能的类型系统API演化无需分版本是不是很有吸引力？看到这些特点，我想大部分同学都会忍不住试一试。本人有幸详细落地GraphQL，故在此吐槽一下。开发过程GraphQL有一个默认的schema，类似于Protobuf。如果Client和Server之间的Schema不对齐，Client将无法直接获取到任何数据。使用httpRESTFUL开发api接口时，流程几乎是一样的：但是使用GraphQL，Client/Server双方都需要坐下来仔细讨论每一个领域。了解过GraphQL的同学都知道，GraphQL可以访问任何类型，从一种类型到另一种类型。为了实现这一目标，双方商谈领域的进程慢得难以想象。可能距离排期已经过了一个星期，字段还不清楚。尽管该领域对开发结果的明确反馈是积极的，但客户端/服务器之间的通信过程确实很慢。网关GraphQL的最大问题是网关。客户端使用Graphql最大的问题是：客户端只能有一个Schema。所以当你有多个GraphqlServer，想对外提供服务时，就需要合并Schemas。目前流行的网关Nginx、APISIX、Kong都不支持Schema合并。所以你只能把所有的业务都耦合到同一个GraphQL上，实际上让GraphQL成为一个单一的服务。这个问题我调查了一下，发现只有JS提供了合并schema的功能，其他语言基本没有这个实现。复杂性GraphQL的另一个问题是查询复杂性的控制。GraphQL可以从任何类型查询到任何类型。如果没有控制，客户端可以一次请求拉取所有数据。当时遇到的一个问题：客户端拉取了所有的列表，然后通过一个请求请求列表中每条记录的所有详情，导致结果：服务器直接挂了。GraphQL提供了复杂度和深度控制的功能，但是这个复杂度和深度是很难计算的。总结：GraphQL不推荐用于项目。
