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