聊一聊開發(fā)中的一些坑

作者： haohongfan 2021-06-30 07:19:35

當(dāng)前的市面上各種微服務(wù)，DDD的課收割了一波又一波的韭菜，有同學(xué)聽完了課就要迫不及待的嘗試一下。學(xué)習(xí)新知識(shí)的動(dòng)力當(dāng)然值得肯定，但是具體落地需要根據(jù)公司實(shí)際場(chǎng)景來。

本文轉(zhuǎn)載自微信公眾號(hào)「HHFCodeRv」，作者h(yuǎn)aohongfan 。轉(zhuǎn)載本文請(qǐng)聯(lián)系HHFCodeRv公眾號(hào)。

本篇文章羅列一些開發(fā)業(yè)務(wù)時(shí)遇到的那些坑。

微服務(wù)銀彈

某前同事找我咨詢架構(gòu)相關(guān)的事情，跟他一番交流讓我徹底無(wú)語(yǔ)了。

這是他們公司 JAVA 架構(gòu)師落地的方案(2個(gè)開發(fā)，其中一個(gè)還是架構(gòu)師，真是鬧)。姑且不論架構(gòu)師水平如何，當(dāng)我看到 2 個(gè)后端開發(fā)，拆出了 17 個(gè)服務(wù)時(shí)，我的建議是立即開除這個(gè)人。

我們?cè)谝粋€(gè)公司有一定的技術(shù)話語(yǔ)權(quán)時(shí)，想落地我們學(xué)到的技術(shù)時(shí)，一定要根據(jù)實(shí)際情況來，不能想當(dāng)然的去橫向、縱向拆分服務(wù)。

是否拆分微服務(wù)條件：

公司業(yè)務(wù)是否到了一定規(guī)模
人員數(shù)量是否到了一定數(shù)量
服務(wù)治理能力是否完備，比如：配置中心，服務(wù)注冊(cè)發(fā)現(xiàn)，日志系統(tǒng)等
是否有了一套完整的監(jiān)控方案
持續(xù)集成，持續(xù)部署能力是否完備
服務(wù)部署是虛擬機(jī)還是 kubernetes ? 是否有足夠能力運(yùn)維?
....

總之，對(duì)于業(yè)務(wù)規(guī)模較小的公司，開發(fā)人員較少時(shí)，一定不要為了拆微服務(wù)而去拆，單體服務(wù)完全夠用。

一個(gè) class 走天下

用這個(gè) case 吐槽下某些 php 程序員。

相信大部分同學(xué)都有一定的強(qiáng)迫癥，比如：函數(shù)的參數(shù)個(gè)數(shù)，函數(shù)的行數(shù)，每行的最大長(zhǎng)度等等。當(dāng)然這些判斷，借助 lint 工具都能完全解決。

對(duì)于函數(shù)參數(shù)的控制，一般正確的做法：抽離程序邏輯，盡量控制函數(shù)邏輯。實(shí)在不行的可以借助 struct 或者 class 的封裝特性，往下傳遞參數(shù)。

不過有些 phper 卻借助了 php 的特性，搞了一些騷操作：將所有的參數(shù)或者返回值全都放在一個(gè)全局的 Class 的 static 變量里面，這樣就不需要函數(shù)間傳遞參數(shù)了。大概形式如下：

class CommonService 
{ 
 
    //存儲(chǔ)接口的入?yún)?nbsp;
    static public $inputParams = null; 
    static public $output = []; 
    static public $objMap = []; 
     
    //.... 
}

這個(gè)寫法有以下這些特點(diǎn)：

這個(gè) Common Service 基本貫穿了整個(gè)業(yè)務(wù)邏輯
不同的位置都可能在更改或者讀取某個(gè)字段

造成的結(jié)果：

不相關(guān)的業(yè)務(wù)邏輯強(qiáng)行耦合
某些位置剛修改的字段，可能被再次更改
預(yù)期之外的修改將整個(gè)邏輯污染
業(yè)務(wù)邏輯變得晦澀難懂

其實(shí)完全簡(jiǎn)單的封裝就能解決的事情，搞出來的這種代碼，讓人實(shí)在忍不住吐槽。

MySQL 里面全是 json

大部分互聯(lián)網(wǎng)公司，MySQL 肯定是業(yè)務(wù)數(shù)據(jù)庫(kù)的標(biāo)配選擇，畢竟運(yùn)維成熟。

我們?cè)O(shè)計(jì)數(shù)據(jù)庫(kù)的時(shí)候，教科書是讓我們至少遵守“第三范式”：

不過真實(shí)業(yè)務(wù)開發(fā)中，設(shè)計(jì) MySQL 的時(shí)候，有的時(shí)候?yàn)榱瞬樵兒?jiǎn)單，會(huì)將某些字段設(shè)計(jì)成 json, 這樣就減少一張關(guān)聯(lián)表的查詢。這種設(shè)計(jì)其實(shí)還算是比較合理做法。

但是更多的情況下，很多人把數(shù)據(jù)庫(kù)字段設(shè)置成 json，美名是為了更好的擴(kuò)展性。

比如下面這種設(shè)計(jì)：

由于商品的屬性字段是特別多的，不同商品的屬性是不固定的。為了擴(kuò)展性，將商品屬性字段全都塞到一個(gè) json 里面，而且 json 也有一套邏輯在里面：aflag 與 bflag 會(huì)互相覆蓋。

這么設(shè)計(jì)造成的結(jié)果：

商品屬性字段基本處于無(wú)法控制的地步

哪些商品擁有哪些屬性是不知道的

一個(gè)商品擁有哪些屬性，需要通過一系列復(fù)雜的解析，計(jì)算才能知道

json 的字段是不確定的，golang/java 解析起來困難

json 字段作為擴(kuò)展性，這個(gè)擴(kuò)展性是我覺得是值得商榷的，因?yàn)榇蟛糠謭?chǎng)景下能做擴(kuò)展的字段，基本都是業(yè)務(wù)邏輯沒有想清楚。如果一個(gè)表的某個(gè)字段是 json 類型，而且 json 里的字段能新增、修改，刪除，最終就會(huì)造成這個(gè) json 最終變得不可控，早晚走上數(shù)據(jù)庫(kù)數(shù)據(jù)治理的地步。

無(wú)腦吹 GraphQL

喜歡看博客或者公眾號(hào)的同學(xué)，對(duì) GraphQL 都不會(huì)陌生。看過 GraphqQL 的同學(xué)上來就被其特性吸引了。

特性：

請(qǐng)求你所要的數(shù)據(jù)不多不少
獲取多個(gè)資源只用一個(gè)請(qǐng)求
描述所有的可能類型系統(tǒng)
API 演進(jìn)無(wú)需劃分版本

是不是很有吸引力?看到這些特性，我覺得大部分同學(xué)都會(huì)忍不住嘗試下。

我有幸具體落地過 GraphQL，這里就想吐槽一番。

開發(fā)流程

GraphQL 是有默認(rèn)的 Schema 的，這個(gè) Schema 類似于 Protobuf。如果 Client、Server 對(duì)不齊這個(gè) Schema 的話，Client 直接獲取不到任何數(shù)據(jù)了。

在使用 http RESTFUL 開發(fā) api 接口時(shí)，差不多是這個(gè)流程：

但是使用了 GraphQL，需要 Client/Server 雙方坐下來，將各個(gè)字段都仔細(xì)討論清楚了。了解過 GraphQL 的同學(xué)都知道，GraphQL 能從一個(gè)類型訪問到另外一個(gè)任意類型，為了這個(gè)實(shí)現(xiàn)這個(gè)目標(biāo)，雙方討論字段的過程簡(jiǎn)直慢的不可想象。可能排期都過去一星期了，字段都沒對(duì)清楚。

固然字段對(duì)清楚對(duì)開發(fā)結(jié)果的反饋是正向的，但是這個(gè) Client/Server 之間的溝通過程真的很慢。

網(wǎng)關(guān)

GraphQL 最大的問題就是網(wǎng)關(guān)。

客戶端使用 Graphql 的最大問題是：客戶端只能有一個(gè) Schema。所以當(dāng)你有多個(gè) Graphql Server 時(shí)想對(duì)外提供服務(wù)時(shí)，就需要合并 Schema。目前市面流行的網(wǎng)關(guān) Nginx, APISIX, Kong 都不支持將 Schema 合并。

于是你只能將所有的業(yè)務(wù)都耦合到同一個(gè) GraphQL 中，無(wú)形中將 GraphQL 做成了單體服務(wù)。

曾經(jīng)調(diào)研過這個(gè)問題，發(fā)現(xiàn)只有 JS 提供一個(gè)合并 schema 的功能，其他語(yǔ)言基本都沒有這個(gè)實(shí)現(xiàn)。