建站
咨詢
售后
建站咨詢
新聞中心
本文轉(zhuǎn)載自微信公眾號(hào)「HHFCodeRv」，作者h(yuǎn)aohongfan 。轉(zhuǎn)載本文請(qǐng)聯(lián)系HHFCodeRv公眾號(hào)。
讓客戶滿意是我們工作的目標(biāo)，不斷超越客戶的期望值來(lái)自于我們對(duì)這個(gè)行業(yè)的熱愛(ài)。我們立志把好的技術(shù)通過(guò)有效、簡(jiǎn)單的方式提供給客戶，將通過(guò)不懈努力成為客戶在信息化領(lǐng)域值得信任、有價(jià)值的長(zhǎng)期合作伙伴，公司提供的服務(wù)項(xiàng)目有：國(guó)際域名空間、網(wǎng)站空間、營(yíng)銷(xiāo)軟件、網(wǎng)站建設(shè)、麗江網(wǎng)站維護(hù)、網(wǎng)站推廣。
本篇文章羅列一些開(kāi)發(fā)業(yè)務(wù)時(shí)遇到的那些坑。
微服務(wù)銀彈
當(dāng)前的市面上各種微服務(wù)，DDD的課收割了一波又一波的韭菜，有同學(xué)聽(tīng)完了課就要迫不及待的嘗試一下。學(xué)習(xí)新知識(shí)的動(dòng)力當(dāng)然值得肯定，但是具體落地需要根據(jù)公司實(shí)際場(chǎng)景來(lái)。
某前同事找我咨詢架構(gòu)相關(guān)的事情，跟他一番交流讓我徹底無(wú)語(yǔ)了。
這是他們公司 JAVA 架構(gòu)師落地的方案(2個(gè)開(kāi)發(fā)，其中一個(gè)還是架構(gòu)師，真是鬧)。姑且不論架構(gòu)師水平如何，當(dāng)我看到 2 個(gè)后端開(kāi)發(fā)，拆出了 17 個(gè)服務(wù)時(shí)，我的建議是立即開(kāi)除這個(gè)人。
我們?cè)谝粋€(gè)公司有一定的技術(shù)話語(yǔ)權(quán)時(shí)，想落地我們學(xué)到的技術(shù)時(shí)，一定要根據(jù)實(shí)際情況來(lái)，不能想當(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ī)模較小的公司，開(kāi)發(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ù)。
不過(guò)有些 phper 卻借助了 php 的特性，搞了一些騷操作：將所有的參數(shù)或者返回值全都放在一個(gè)全局的 Class 的 static 變量里面，這樣就不需要函數(shù)間傳遞參數(shù)了。大概形式如下：
- class CommonService
- {
- //存儲(chǔ)接口的入?yún)?/li>
- static public $inputParams = null;
- static public $output = [];
- static public $objMap = [];
- //....
- }
這個(gè)寫(xiě)法有以下這些特點(diǎn)：
- 這個(gè) Common Service 基本貫穿了整個(gè)業(yè)務(wù)邏輯
- 不同的位置都可能在更改或者讀取某個(gè)字段
造成的結(jié)果：
- 不相關(guān)的業(yè)務(wù)邏輯強(qiáng)行耦合
- 某些位置剛修改的字段，可能被再次更改
- 預(yù)期之外的修改將整個(gè)邏輯污染
- 業(yè)務(wù)邏輯變得晦澀難懂
其實(shí)完全簡(jiǎn)單的封裝就能解決的事情，搞出來(lái)的這種代碼，讓人實(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ū)是讓我們至少遵守“第三范式”：
不過(guò)真實(shí)業(yè)務(wù)開(kāi)發(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è)商品擁有哪些屬性，需要通過(guò)一系列復(fù)雜的解析，計(jì)算才能知道
json 的字段是不確定的，golang/java 解析起來(lái)困難
json 字段作為擴(kuò)展性，這個(gè)擴(kuò)展性是我覺(jué)得是值得商榷的，因?yàn)榇蟛糠謭?chǎng)景下能做擴(kuò)展的字段，基本都是業(yè)務(wù)邏輯沒(méi)有想清楚。如果一個(gè)表的某個(gè)字段是 json 類(lèi)型，而且 json 里的字段能新增、修改，刪除，最終就會(huì)造成這個(gè) json 最終變得不可控，早晚走上數(shù)據(jù)庫(kù)數(shù)據(jù)治理的地步。
無(wú)腦吹 GraphQL
喜歡看博客或者公眾號(hào)的同學(xué)，對(duì) GraphQL 都不會(huì)陌生。看過(guò) GraphqQL 的同學(xué)上來(lái)就被其特性吸引了。
特性：
- 請(qǐng)求你所要的數(shù)據(jù)不多不少
- 獲取多個(gè)資源只用一個(gè)請(qǐng)求
- 描述所有的可能類(lèi)型系統(tǒng)
- API 演進(jìn)無(wú)需劃分版本
是不是很有吸引力?看到這些特性，我覺(jué)得大部分同學(xué)都會(huì)忍不住嘗試下。
我有幸具體落地過(guò) GraphQL，這里就想吐槽一番。
開(kāi)發(fā)流程
GraphQL 是有默認(rèn)的 Schema 的，這個(gè) Schema 類(lèi)似于 Protobuf。如果 Client、Server 對(duì)不齊這個(gè) Schema 的話，Client 直接獲取不到任何數(shù)據(jù)了。
在使用 http RESTFUL 開(kāi)發(fā) api 接口時(shí)，差不多是這個(gè)流程：
但是使用了 GraphQL，需要 Client/Server 雙方坐下來(lái)，將各個(gè)字段都仔細(xì)討論清楚了。了解過(guò) GraphQL 的同學(xué)都知道，GraphQL 能從一個(gè)類(lèi)型訪問(wèn)到另外一個(gè)任意類(lèi)型，為了這個(gè)實(shí)現(xiàn)這個(gè)目標(biāo)，雙方討論字段的過(guò)程簡(jiǎn)直慢的不可想象?？赡芘牌诙歼^(guò)去一星期了，字段都沒(méi)對(duì)清楚。
固然字段對(duì)清楚對(duì)開(kāi)發(fā)結(jié)果的反饋是正向的，但是這個(gè) Client/Server 之間的溝通過(guò)程真的很慢。
網(wǎng)關(guān)
GraphQL 最大的問(wèn)題就是網(wǎng)關(guān)。
客戶端使用 Graphql 的最大問(wèn)題是：客戶端只能有一個(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)研過(guò)這個(gè)問(wèn)題，發(fā)現(xiàn)只有 JS 提供一個(gè)合并 schema 的功能，其他語(yǔ)言基本都沒(méi)有這個(gè)實(shí)現(xiàn)。
復(fù)雜度
GraphQL 另外一個(gè)問(wèn)題就是對(duì)查詢復(fù)雜度的控制。
GraphQL 可用從一個(gè)類(lèi)型任意查詢到任意一個(gè)類(lèi)型。假如沒(méi)有任何控制的話，客戶端一次請(qǐng)求能將所有的數(shù)據(jù)全都拉取出來(lái)。
當(dāng)時(shí)遇到過(guò)的一個(gè)問(wèn)題：客戶端拉取所有的列表，又將列表中每條記錄的詳情，通過(guò)一次請(qǐng)求全部請(qǐng)求，導(dǎo)致的結(jié)果：服務(wù)器直接就崩了。
GraphQL 提供了復(fù)雜度和深度的控制功能，但是這個(gè)復(fù)雜度和深度是很難計(jì)算的。
綜上：不建議項(xiàng)目使用 GraphQL。
網(wǎng)站題目：聊一聊開(kāi)發(fā)中的一些坑
URL分享：http://www.dlmjj.cn/article/ccsicdo.html
