后端思想篇：設(shè)計(jì)好接口的36個(gè)錦囊！
前言
大家好，我是撿田螺的小男孩。作為后端開發(fā)，不管是什么語言，Java、Go還是C++，其背后的后端思想都是類似的。后面打算出一個(gè)后端思想的技術(shù)專欄，主要包括后端的一些設(shè)計(jì)、或者后端規(guī)范相關(guān)的，希望對(duì)大家日常工作有幫助哈。
我們做后端開發(fā)工程師，主要工作就是：如何把一個(gè)接口設(shè)計(jì)好。所以，今天就給大家介紹，設(shè)計(jì)好接口的36個(gè)錦囊。本文就是后端思想專欄的第一篇哈。
1. 接口參數(shù)校驗(yàn)
入?yún)⒊鰠⑿ｒ?yàn)是每個(gè)程序員必備的基本素養(yǎng)。你設(shè)計(jì)的接口，必須先校驗(yàn)參數(shù)。比如入?yún)⑹欠裨试S為空，入?yún)㈤L(zhǎng)度是否符合你的預(yù)期長(zhǎng)度。這個(gè)要養(yǎng)成習(xí)慣哈，日常開發(fā)中，很多低級(jí)bug都是不校驗(yàn)參數(shù)導(dǎo)致的。
比如你的數(shù)據(jù)庫表字段設(shè)置為
varchar(16),對(duì)方傳了一個(gè)32位的字符串過來，如果你不校驗(yàn)參數(shù)，插入數(shù)據(jù)庫直接異常了。
出參也是，比如你定義的接口報(bào)文，參數(shù)是不為空的，但是你的接口返回參數(shù)，沒有做校驗(yàn)，因?yàn)槌绦蚰承┰?，直返回別人一個(gè)null值。。。
2. 修改老接口時(shí)，注意接口的兼容性
很多bug都是因?yàn)樾薷牧藢?duì)外舊接口，但是卻不做兼容導(dǎo)致的。關(guān)鍵這個(gè)問題多數(shù)是比較嚴(yán)重的，可能直接導(dǎo)致系統(tǒng)發(fā)版失敗的。新手程序員很容易犯這個(gè)錯(cuò)誤哦~
所以，如果你的需求是在原來接口上修改，尤其這個(gè)接口是對(duì)外提供服務(wù)的話，一定要考慮接口兼容。舉個(gè)例子吧，比如dubbo接口，原本是只接收A，B參數(shù)，現(xiàn)在你加了一個(gè)參數(shù)C，就可以考慮這樣處理：
//老接口
void?oldService(A,B){
??//兼容新接口，傳個(gè)null代替C
??newService(A,B,null);
}
//新接口，暫時(shí)不能刪掉老接口，需要做兼容。
void?newService(A,B,C){
??...
}
3. ?設(shè)計(jì)接口時(shí)，充分考慮接口的可擴(kuò)展性
要根據(jù)實(shí)際業(yè)務(wù)場(chǎng)景設(shè)計(jì)接口，充分考慮接口的可擴(kuò)展性。
比如你接到一個(gè)需求：是用戶添加或者修改員工時(shí)，需要刷臉。那你是反手提供一個(gè)員工管理的提交刷臉信息接口？還是先思考：提交刷臉是不是通用流程呢？比如轉(zhuǎn)賬或者一鍵貼現(xiàn)需要接入刷臉的話，你是否需要重新實(shí)現(xiàn)一個(gè)接口呢？還是當(dāng)前按業(yè)務(wù)類型劃分模塊，復(fù)用這個(gè)接口就好，保留接口的可擴(kuò)展性。
如果按模塊劃分的話，未來如果其他場(chǎng)景比如一鍵貼現(xiàn)接入刷臉的話，不用再搞一套新的接口，只需要新增枚舉，然后復(fù)用刷臉通過流程接口，實(shí)現(xiàn)一鍵貼現(xiàn)刷臉的差異化即可。
4.接口考慮是否需要防重處理
如果前端重復(fù)請(qǐng)求，你的邏輯如何處理？是不是考慮接口去重處理。
當(dāng)然，如果是查詢類的請(qǐng)求，其實(shí)不用防重。如果是更新修改類的話，尤其金融轉(zhuǎn)賬類的，就要過濾重復(fù)請(qǐng)求了。簡(jiǎn)單點(diǎn)，你可以使用Redis防重復(fù)請(qǐng)求，同樣的請(qǐng)求方，一定時(shí)間間隔內(nèi)的相同請(qǐng)求，考慮是否過濾。當(dāng)然，轉(zhuǎn)賬類接口，并發(fā)不高的話，推薦使用數(shù)據(jù)庫防重表，以唯一流水號(hào)作為主鍵或者唯一索引。
5. 重點(diǎn)接口，考慮線程池隔離。
一些登陸、轉(zhuǎn)賬交易、下單等重要接口，考慮線程池隔離哈。如果你所有業(yè)務(wù)都共用一個(gè)線程池，有些業(yè)務(wù)出bug導(dǎo)致線程池阻塞打滿的話，那就杯具了，所有業(yè)務(wù)都影響了。因此進(jìn)行線程池隔離，重要業(yè)務(wù)分配多一點(diǎn)的核心線程，就更好保護(hù)重要業(yè)務(wù)。
6. 調(diào)用第三方接口要考慮異常和超時(shí)處理
如果你調(diào)用第三方接口，或者分布式遠(yuǎn)程服務(wù)的的話，需要考慮：
異常處理
比如，你調(diào)別人的接口，如果異常了，怎么處理，是重試還是當(dāng)做失敗還是告警處理。
接口超時(shí)
沒法預(yù)估對(duì)方接口一般多久返回，一般設(shè)置個(gè)超時(shí)斷開時(shí)間，以保護(hù)你的接口。之前見過一個(gè)生產(chǎn)問題，就是http調(diào)用不設(shè)置超時(shí)時(shí)間，最后響應(yīng)方進(jìn)程假死，請(qǐng)求一直占著線程不釋放，拖垮線程池。
重試次數(shù)
你的接口調(diào)失敗，需不需要重試？重試幾次？需要站在業(yè)務(wù)上角度思考這個(gè)問題
7. 接口實(shí)現(xiàn)考慮熔斷和降級(jí)
當(dāng)前互聯(lián)網(wǎng)系統(tǒng)一般都是分布式部署的。而分布式系統(tǒng)中經(jīng)常會(huì)出現(xiàn)某個(gè)基礎(chǔ)服務(wù)不可用，最終導(dǎo)致整個(gè)系統(tǒng)不可用的情況, 這種現(xiàn)象被稱為服務(wù)雪崩效應(yīng)。
比如分布式調(diào)用鏈路A->B->C....，下圖所示：
如果服務(wù)C出現(xiàn)問題，比如是因?yàn)槁齋QL導(dǎo)致調(diào)用緩慢，那將導(dǎo)致B也會(huì)延遲，從而A也會(huì)延遲。堵住的A請(qǐng)求會(huì)消耗占用系統(tǒng)的線程、IO等資源。當(dāng)請(qǐng)求A的服務(wù)越來越多，占用計(jì)算機(jī)的資源也越來越多，最終會(huì)導(dǎo)致系統(tǒng)瓶頸出現(xiàn)，造成其他的請(qǐng)求同樣不可用，最后導(dǎo)致業(yè)務(wù)系統(tǒng)崩潰。
為了應(yīng)對(duì)服務(wù)雪崩, 常見的做法是熔斷和降級(jí)。最簡(jiǎn)單是加開關(guān)控制，當(dāng)下游系統(tǒng)出問題時(shí)，開關(guān)降級(jí)，不再調(diào)用下游系統(tǒng)。還可以選用開源組件Hystrix。
8. 日志打印好，接口的關(guān)鍵代碼，要有日志保駕護(hù)航。
關(guān)鍵業(yè)務(wù)代碼無論身處何地，都應(yīng)該有足夠的日志保駕護(hù)航。比如：你實(shí)現(xiàn)轉(zhuǎn)賬業(yè)務(wù)，轉(zhuǎn)個(gè)幾百萬，然后轉(zhuǎn)失敗了，接著客戶投訴，然后你還沒有打印到日志，想想那種水深火熱的困境下，你卻毫無辦法。。。
那么，你的轉(zhuǎn)賬業(yè)務(wù)都需要哪些日志信息呢？至少，方法調(diào)用前，入?yún)⑿枰蛴⌒枰?，接口調(diào)用后，需要捕獲一下異常吧，同時(shí)打印異常相關(guān)日志吧，如下：
public?void?transfer(TransferDTO?transferDTO){
????log.info("invoke?tranfer?begin");
????//打印入?yún)?br>????log.info("invoke?tranfer,paramters:{}",transferDTO);
????try?{
??????res=??transferService.transfer(transferDTO);
????}catch(Exception?e){
?????log.error("transfer fail,account：{}",
?????transferDTO.getAccount（）)
?????log.error("transfer?fail,exception:{}",e);
????}
????log.info("invoke?tranfer?end");
????}
之前寫過一篇打印日志的15個(gè)建議，大家可以看看哈：工作總結(jié)！日志打印的15個(gè)建議
9. 接口的功能定義要具備單一性
單一性是指接口做的事情比較單一、專一。比如一個(gè)登陸接口，它做的事情就只是校驗(yàn)賬戶名密碼，然后返回登陸成功以及userId即可。但是如果你為了減少接口交互，把一些注冊(cè)、一些配置查詢等全放到登陸接口，就不太妥。
其實(shí)這也是微服務(wù)一些思想，接口的功能單一、明確。比如訂單服務(wù)、積分、商品信息相關(guān)的接口都是劃分開的。將來拆分微服務(wù)的話，是不是就比較簡(jiǎn)便啦。
10.接口有些場(chǎng)景，使用異步更合理
舉個(gè)簡(jiǎn)單的例子，比如你實(shí)現(xiàn)一個(gè)用戶注冊(cè)的接口。用戶注冊(cè)成功時(shí)，發(fā)個(gè)郵件或者短信去通知用戶。這個(gè)郵件或者發(fā)短信，就更適合異步處理。因?yàn)榭偛荒芤粋€(gè)通知類的失敗，導(dǎo)致注冊(cè)失敗吧。
至于做異步的方式，簡(jiǎn)單的就是用線程池。還可以使用消息隊(duì)列，就是用戶注冊(cè)成功后，生產(chǎn)者產(chǎn)生一個(gè)注冊(cè)成功的消息，消費(fèi)者拉到注冊(cè)成功的消息，就發(fā)送通知。
不是所有的接口都適合設(shè)計(jì)為同步接口。比如你要做一個(gè)轉(zhuǎn)賬的功能，如果你是單筆的轉(zhuǎn)賬，你是可以把接口設(shè)計(jì)同步。用戶發(fā)起轉(zhuǎn)賬時(shí)，客戶端在靜靜等待轉(zhuǎn)賬結(jié)果就好。如果你是批量轉(zhuǎn)賬，一個(gè)批次一千筆，甚至一萬筆的，你則可以把接口設(shè)計(jì)為異步。就是用戶發(fā)起批量轉(zhuǎn)賬時(shí)，持久化成功就先返回受理成功。然后用戶隔十分鐘或者十五分鐘等再來查轉(zhuǎn)賬結(jié)果就好。又或者，批量轉(zhuǎn)賬成功后，再回調(diào)上游系統(tǒng)。
11. 優(yōu)化接口耗時(shí)，遠(yuǎn)程串行考慮改并行調(diào)用
假設(shè)我們?cè)O(shè)計(jì)一個(gè)APP首頁的接口，它需要查用戶信息、需要查banner信息、需要查彈窗信息等等。那你是一個(gè)一個(gè)接口串行調(diào)，還是并行調(diào)用呢？
如果是串行一個(gè)一個(gè)查，比如查用戶信息200ms，查banner信息100ms、查彈窗信息50ms，那一共就耗時(shí)350ms了，如果還查其他信息，那耗時(shí)就更大了。這種場(chǎng)景是可以改為并行調(diào)用的。也就是說查用戶信息、查banner信息、查彈窗信息，可以同時(shí)發(fā)起。
在Java中有個(gè)異步編程利器：CompletableFuture，就可以很好實(shí)現(xiàn)這個(gè)功能。有興趣的小伙伴可以看我之前這個(gè)文章哈：CompletableFuture詳解
12. 接口合并或者說考慮批量處理思想
數(shù)據(jù)庫操作或或者是遠(yuǎn)程調(diào)用時(shí)，能批量操作就不要for循環(huán)調(diào)用。
一個(gè)簡(jiǎn)單例子，我們平時(shí)一個(gè)列表明細(xì)數(shù)據(jù)插入數(shù)據(jù)庫時(shí)，不要在for循環(huán)一條一條插入，建議一個(gè)批次幾百條，進(jìn)行批量插入。同理遠(yuǎn)程調(diào)用也類似想法，比如你查詢營(yíng)銷標(biāo)簽是否命中，可以一個(gè)標(biāo)簽一個(gè)標(biāo)簽去查，也可以批量標(biāo)簽去查，那批量進(jìn)行，效率就更高嘛。
//反例
for(int?i=0;i??remoteSingleQuery(param)
}
//正例
remoteBatchQuery(param);
小伙伴們是否了解過kafka為什么這么快呢？其實(shí)其中一點(diǎn)原因，就是kafka使用批量消息提升服務(wù)端處理能力。
13. 接口實(shí)現(xiàn)過程中，恰當(dāng)使用緩存
哪些場(chǎng)景適合使用緩存？讀多寫少且數(shù)據(jù)時(shí)效要求越低的場(chǎng)景。
緩存用得好，可以承載更多的請(qǐng)求，提升查詢效率，減少數(shù)據(jù)庫的壓力。
比如一些平時(shí)變動(dòng)很小或者說幾乎不會(huì)變的商品信息，可以放到緩存，請(qǐng)求過來時(shí)，先查詢緩存，如果沒有再查數(shù)據(jù)庫，并且把數(shù)據(jù)庫的數(shù)據(jù)更新到緩存。但是，使用緩存增加了需要考慮這些點(diǎn)：緩存和數(shù)據(jù)庫一致性如何保證、集群、緩存擊穿、緩存雪崩、緩存穿透等問題。
保證數(shù)據(jù)庫和緩存一致性：緩存延時(shí)雙刪、刪除緩存重試機(jī)制、讀取biglog異步刪除緩存 緩存擊穿：設(shè)置數(shù)據(jù)永不過期 緩存雪崩：Redis集群高可用、均勻設(shè)置過期時(shí)間 緩存穿透：接口層校驗(yàn)、查詢?yōu)榭赵O(shè)置個(gè)默認(rèn)空值標(biāo)記、布隆過濾器。
一般用Redis分布式緩存，當(dāng)然有些時(shí)候也可以考慮使用本地緩存，如Guava Cache、Caffeine等。使用本地緩存有些缺點(diǎn)，就是無法進(jìn)行大數(shù)據(jù)存儲(chǔ)，并且應(yīng)用進(jìn)程的重啟，緩存會(huì)失效。
14. 接口考慮熱點(diǎn)數(shù)據(jù)隔離性
瞬時(shí)間的高并發(fā)，可能會(huì)打垮你的系統(tǒng)?？梢宰鲆恍狳c(diǎn)數(shù)據(jù)的隔離。比如業(yè)務(wù)隔離、系統(tǒng)隔離、用戶隔離、數(shù)據(jù)隔離等。
業(yè)務(wù)隔離性，比如12306的分時(shí)段售票，將熱點(diǎn)數(shù)據(jù)分散處理，降低系統(tǒng)負(fù)載壓力。 系統(tǒng)隔離：比如把系統(tǒng)分成了用戶、商品、社區(qū)三個(gè)板塊。這三個(gè)塊分別使用不同的域名、服務(wù)器和數(shù)據(jù)庫，做到從接入層到應(yīng)用層再到數(shù)據(jù)層三層完全隔離。 用戶隔離：重點(diǎn)用戶請(qǐng)求到配置更好的機(jī)器。 數(shù)據(jù)隔離：使用單獨(dú)的緩存集群或者數(shù)據(jù)庫服務(wù)熱點(diǎn)數(shù)據(jù)。
15. 可變參數(shù)配置化，比如紅包皮膚切換等
假如產(chǎn)品經(jīng)理提了個(gè)紅包需求，圣誕節(jié)的時(shí)候，紅包皮膚為圣誕節(jié)相關(guān)的，春節(jié)的時(shí)候，為春節(jié)紅包皮膚等。
如果在代碼寫死控制，可有類似以下代碼：
if(duringChristmas){
???img?=?redPacketChristmasSkin;
}else?if(duringSpringFestival){
???img?=??redSpringFestivalSkin;
}
如果到了元宵節(jié)的時(shí)候，運(yùn)營(yíng)小姐姐突然又有想法，紅包皮膚換成燈籠相關(guān)的，這時(shí)候，是不是要去修改代碼了，重新發(fā)布了？
從一開始接口設(shè)計(jì)時(shí)，可以實(shí)現(xiàn)一張紅包皮膚的配置表，將紅包皮膚做成配置化呢？更換紅包皮膚，只需修改一下表數(shù)據(jù)就好了。
當(dāng)然，還有一些場(chǎng)景適合一些配置化的參數(shù)：一個(gè)分頁多少數(shù)量控制、某個(gè)搶紅包多久時(shí)間過期這些，都可以搞到參數(shù)配置化表里面。這也是擴(kuò)展性思想的一種體現(xiàn)。
16.接口考慮冪等性
接口是需要考慮冪等性的，尤其搶紅包、轉(zhuǎn)賬這些重要接口。最直觀的業(yè)務(wù)場(chǎng)景，就是用戶連著點(diǎn)擊兩次，你的接口有沒有hold住。或者消息隊(duì)列出現(xiàn)重復(fù)消費(fèi)的情況，你的業(yè)務(wù)邏輯怎么控制？
回憶下，什么是冪等？
計(jì)算機(jī)科學(xué)中，冪等表示一次和多次請(qǐng)求某一個(gè)資源應(yīng)該具有同樣的副作用，或者說，多次請(qǐng)求所產(chǎn)生的影響與一次請(qǐng)求執(zhí)行的影響效果相同。
大家別搞混哈，防重和冪等設(shè)計(jì)其實(shí)是有區(qū)別的。防重主要為了避免產(chǎn)生重復(fù)數(shù)據(jù)，把重復(fù)請(qǐng)求攔截下來即可。而冪等設(shè)計(jì)除了攔截已經(jīng)處理的請(qǐng)求，還要求每次相同的請(qǐng)求都返回一樣的效果。不過呢，很多時(shí)候，它們的處理流程、方案是類似的哈。
接口冪等實(shí)現(xiàn)方案主要有8種：
select+insert+主鍵/唯一索引沖突 直接insert + 主鍵/唯一索引沖突 狀態(tài)機(jī)冪等 抽取防重表 token令牌 悲觀鎖 樂觀鎖 分布式鎖
大家可以看我這篇文章哈：聊聊冪等設(shè)計(jì)
17. 讀寫分離，優(yōu)先考慮讀從庫，注意主從延遲問題
我們的數(shù)據(jù)庫都是集群部署的，有主庫也有從庫，當(dāng)前一般都是讀寫分離的。比如你寫入數(shù)據(jù)，肯定是寫入主庫，但是對(duì)于讀取實(shí)時(shí)性要求不高的數(shù)據(jù)，則優(yōu)先考慮讀從庫，因?yàn)榭梢苑謸?dān)主庫的壓力。
如果讀取從庫的話，需要考慮主從延遲的問題。
18.接口注意返回的數(shù)據(jù)量，如果數(shù)據(jù)量大需要分頁
一個(gè)接口返回報(bào)文，不應(yīng)該包含過多的數(shù)據(jù)量。過多的數(shù)據(jù)量不僅處理復(fù)雜，并且數(shù)據(jù)量傳輸?shù)膲毫σ卜浅４?。因此?shù)量實(shí)在是比較大，可以分頁返回，如果是功能不相關(guān)的報(bào)文，那應(yīng)該考慮接口拆分。
19. 好的接口實(shí)現(xiàn)，離不開SQL優(yōu)化
我們做后端的，寫好一個(gè)接口，離不開SQL優(yōu)化。
SQL優(yōu)化從這幾個(gè)維度思考：
explain 分析SQL查詢計(jì)劃（重點(diǎn)關(guān)注type、extra、filtered字段） show profile分析，了解SQL執(zhí)行的線程的狀態(tài)以及消耗的時(shí)間 索引優(yōu)化 （覆蓋索引、最左前綴原則、隱式轉(zhuǎn)換、order by以及group by的優(yōu)化、join優(yōu)化） 大分頁問題優(yōu)化（延遲關(guān)聯(lián)、記錄上一頁最大ID） 數(shù)據(jù)量太大（分庫分表、同步到es，用es查詢）
20.代碼鎖的粒度控制好
什么是加鎖粒度呢？
其實(shí)就是就是你要鎖住的范圍是多大。比如你在家上衛(wèi)生間，你只要鎖住衛(wèi)生間就可以了吧，不需要將整個(gè)家都鎖起來不讓家人進(jìn)門吧，衛(wèi)生間就是你的加鎖粒度。
我們寫代碼時(shí)，如果不涉及到共享資源，就沒有必要鎖住的。這就好像你上衛(wèi)生間，不用把整個(gè)家都鎖住，鎖住衛(wèi)生間門就可以了。
比如，在業(yè)務(wù)代碼中，有一個(gè)ArrayList因?yàn)樯婕暗蕉嗑€程操作，所以需要加鎖操作，假設(shè)剛好又有一段比較耗時(shí)的操作（代碼中的slowNotShare方法）不涉及線程安全問題，你會(huì)如何加鎖呢？
反例：
//不涉及共享資源的慢方法
private?void?slowNotShare()?{
????try?{
????????TimeUnit.MILLISECONDS.sleep(100);
????}?catch?(InterruptedException?e)?{
????}
}
//錯(cuò)誤的加鎖方法
public?int?wrong()?{
????long?beginTime?=?System.currentTimeMillis();
????IntStream.rangeClosed(1,?10000).parallel().forEach(i?->?{
????????//加鎖粒度太粗了，slowNotShare其實(shí)不涉及共享資源
????????synchronized?(this)?{
????????????slowNotShare();
????????????data.add(i);
????????}
????});
????log.info("cosume?time:{}",?System.currentTimeMillis()?-?beginTime);
????return?data.size();
}
正例：
public?int?right()?{
????long?beginTime?=?System.currentTimeMillis();
????IntStream.rangeClosed(1,?10000).parallel().forEach(i?->?{
????????slowNotShare();//可以不加鎖
????????//只對(duì)List這部分加鎖
????????synchronized?(data)?{
????????????data.add(i);
????????}
????});
????log.info("cosume?time:{}",?System.currentTimeMillis()?-?beginTime);
????return?data.size();
}
21.接口狀態(tài)和錯(cuò)誤需要統(tǒng)一明確
提供必要的接口調(diào)用狀態(tài)信息。比如你的一個(gè)轉(zhuǎn)賬接口調(diào)用是成功、失敗、處理中還是受理成功等，需要明確告訴客戶端。如果接口失敗，那么具體失敗的原因是什么。這些必要的信息都必須要告訴給客戶端，因此需要定義明確的錯(cuò)誤碼和對(duì)應(yīng)的描述。同時(shí)，盡量對(duì)報(bào)錯(cuò)信息封裝一下，不要把后端的異常信息完全拋出到客戶端。
22.接口要考慮異常處理
實(shí)現(xiàn)一個(gè)好的接口，離不開優(yōu)雅的異常處理。對(duì)于異常處理，提十個(gè)小建議吧：
盡量不要使用 e.printStackTrace(),而是使用log打印。因?yàn)?code style="font-size: 14px;padding: 2px 4px;border-radius: 4px;margin-right: 2px;margin-left: 2px;background-color: rgba(27, 31, 35, 0.05);font-family: "Operator Mono", Consolas, Monaco, Menlo, monospace;word-break: break-all;color: rgb(239, 112, 96);">e.printStackTrace()語句可能會(huì)導(dǎo)致內(nèi)存占滿。catch住異常時(shí)，建議打印出具體的exception，利于更好定位問題不要用一個(gè) Exception捕捉所有可能的異常記得使用 finally關(guān)閉流資源或者直接使用try-with-resource捕獲異常與拋出異常必須是完全匹配，或者捕獲異常是拋異常的父類 捕獲到的異常，不能忽略它，至少打點(diǎn)日志吧 注意異常對(duì)你的代碼層次結(jié)構(gòu)的侵染 自定義封裝異常，不要丟棄原始異常的信息 Throwable cause運(yùn)行時(shí)異常 RuntimeException，不應(yīng)該通過catch的方式來處理，而是先預(yù)檢查，比如：NullPointerException處理注意異常匹配的順序，優(yōu)先捕獲具體的異常
小伙伴們有興趣可以看下我之前寫的這篇文章哈：Java 異常處理的十個(gè)建議
23. 優(yōu)化程序邏輯
優(yōu)化程序邏輯這塊還是挺重要的，也就是說，你實(shí)現(xiàn)的業(yè)務(wù)代碼，如果是比較復(fù)雜的話，建議把注釋寫清楚。還有，代碼邏輯盡量清晰，代碼盡量高效。
比如，你要使用用戶信息的屬性，你根據(jù)session已經(jīng)獲取到
userId了，然后就把用戶信息從數(shù)據(jù)庫查詢出來，使用完后，后面可能又要用到用戶信息的屬性，有些小伙伴沒想太多，反手就把userId再傳進(jìn)去，再查一次數(shù)據(jù)庫。。。我在項(xiàng)目中，見過這種代碼。。。直接把用戶對(duì)象傳下來不好嘛。。
反例偽代碼：
public?Response?test(Session?session){
????UserInfo?user?=?UserDao.queryByUserId(session.getUserId());
????
????if(user==null){
???????reutrn?new?Response();
????}
????
????return?do(session.getUserId());
}
public?Response?do(String?UserId){
??//多查了一次數(shù)據(jù)庫
??UserInfo?user?=?UserDao.queryByUserId(session.getUserId());
??......
??return?new?Response();?
}
正例：
public?Response?test(Session?session){
????UserInfo?user?=?UserDao.queryByUserId(session.getUserId());
????
????if(user==null){
???????reutrn?new?Response();
????}
????
????return?do(session.getUserId());
}
//直接傳UserInfo對(duì)象過來即可，不用再多查一次數(shù)據(jù)庫
public?Response?do(UserInfo?user){
??......
??return?new?Response();?
}
當(dāng)然，這只是一些很小的一個(gè)例子，還有很多類似的例子，需要大家開發(fā)過程中，多點(diǎn)思考的哈。
24. 接口實(shí)現(xiàn)過程中，注意大文件、大事務(wù)、大對(duì)象
讀取大文件時(shí)，不要 Files.readAllBytes直接讀取到內(nèi)存，這樣會(huì)OOM的，建議使用BufferedReader一行一行來。大事務(wù)可能導(dǎo)致死鎖、回滾時(shí)間長(zhǎng)、主從延遲等問題，開發(fā)中盡量避免大事務(wù)。 注意一些大對(duì)象的使用，因?yàn)榇髮?duì)象是直接進(jìn)入老年代的，可能會(huì)觸發(fā)fullGC
25. 你的接口，需要考慮限流
如果你的系統(tǒng)每秒扛住的請(qǐng)求是1000，如果一秒鐘來了十萬請(qǐng)求呢？換個(gè)角度就是說，高并發(fā)的時(shí)候，流量洪峰來了，超過系統(tǒng)的承載能力，怎么辦呢？
如果不采取措施，所有的請(qǐng)求打過來，系統(tǒng)CPU、內(nèi)存、Load負(fù)載飚的很高，最后請(qǐng)求處理不過來，所有的請(qǐng)求無法正常響應(yīng)。
針對(duì)這種場(chǎng)景，我們可以采用限流方案。就是為了保護(hù)系統(tǒng)，多余的請(qǐng)求，直接丟棄。
限流定義：
在計(jì)算機(jī)網(wǎng)絡(luò)中，限流就是控制網(wǎng)絡(luò)接口發(fā)送或接收請(qǐng)求的速率，它可防止DoS攻擊和限制Web爬蟲。限流，也稱流量控制。是指系統(tǒng)在面臨高并發(fā)，或者大流量請(qǐng)求的情況下，限制新的請(qǐng)求對(duì)系統(tǒng)的訪問，從而保證系統(tǒng)的穩(wěn)定性。
可以使用Guava的RateLimiter單機(jī)版限流，也可以使用Redis分布式限流，還可以使用阿里開源組件sentinel限流
大家可以看下我之前這篇文章哈：4種經(jīng)典限流算法講解
26.代碼實(shí)現(xiàn)時(shí)，注意運(yùn)行時(shí)異常（比如空指針、下標(biāo)越界等）
日常開發(fā)中，我們需要采取措施規(guī)避數(shù)組邊界溢出，被零整除，空指針等運(yùn)行時(shí)錯(cuò)誤。類似代碼比較常見：
String?name?=?list.get(1).getName();?//list可能越界，因?yàn)椴灰欢ㄓ?個(gè)元素哈
應(yīng)該采取措施，預(yù)防一下數(shù)組邊界溢出。正例如下：
if(CollectionsUtil.isNotEmpty(list)&&?list.size()>1){
??String?name?=?list.get(1).getName();?
}
27.保證接口安全性
如果你的API接口是對(duì)外提供的，需要保證接口的安全性。保證接口的安全性有token機(jī)制和接口簽名。
token機(jī)制身份驗(yàn)證方案還比較簡(jiǎn)單的，就是
客戶端發(fā)起請(qǐng)求，申請(qǐng)獲取token。 服務(wù)端生成全局唯一的token，保存到redis中（一般會(huì)設(shè)置一個(gè)過期時(shí)間），然后返回給客戶端。 客戶端帶著token，發(fā)起請(qǐng)求。 服務(wù)端去redis確認(rèn)token是否存在，一般用 redis.del(token)的方式，如果存在會(huì)刪除成功，即處理業(yè)務(wù)邏輯，如果刪除失敗不處理業(yè)務(wù)邏輯，直接返回結(jié)果。
接口簽名的方式，就是把接口請(qǐng)求相關(guān)信息（請(qǐng)求報(bào)文，包括請(qǐng)求時(shí)間戳、版本號(hào)、appid等），客戶端私鑰加簽，然后服務(wù)端用公鑰驗(yàn)簽，驗(yàn)證通過才認(rèn)為是合法的、沒有被篡改過的請(qǐng)求。
有關(guān)于加簽驗(yàn)簽的，大家可以看下我這篇文章哈：程序員必備基礎(chǔ)：加簽驗(yàn)簽
除了加簽驗(yàn)簽和token機(jī)制，接口報(bào)文一般是要加密的。當(dāng)然，用https協(xié)議是會(huì)對(duì)報(bào)文加密的。如果是我們服務(wù)層的話，如何加解密呢？
可以參考HTTPS的原理，就是服務(wù)端把公鑰給客戶端，然后客戶端生成對(duì)稱密鑰，接著客戶端用服務(wù)端的公鑰加密對(duì)稱密鑰，再發(fā)到服務(wù)端，服務(wù)端用自己的私鑰解密，得到客戶端的對(duì)稱密鑰。這時(shí)候就可以愉快傳輸報(bào)文啦，客戶端用對(duì)稱密鑰加密請(qǐng)求報(bào)文，服務(wù)端用對(duì)應(yīng)的對(duì)稱密鑰解密報(bào)文。
有時(shí)候，接口的安全性，還包括手機(jī)號(hào)、身份證等信息的脫敏。就是說，用戶的隱私數(shù)據(jù)，不能隨便暴露。
28.分布式事務(wù)，如何保證
分布式事務(wù)：就是指事務(wù)的參與者、支持事務(wù)的服務(wù)器、資源服務(wù)器以及事務(wù)管理器分別位于不同的分布式系統(tǒng)的不同節(jié)點(diǎn)之上。簡(jiǎn)單來說，分布式事務(wù)指的就是分布式系統(tǒng)中的事務(wù)，它的存在就是為了保證不同數(shù)據(jù)庫節(jié)點(diǎn)的數(shù)據(jù)一致性。
分布式事務(wù)的幾種解決方案：
2PC(二階段提交)方案、3PC TCC（Try、Confirm、Cancel） 本地消息表 最大努力通知 seata
大家可以看下這篇文章哈：看一遍就理解：分布式事務(wù)詳解
29. 事務(wù)失效的一些經(jīng)典場(chǎng)景
我們的接口開發(fā)過程中，經(jīng)常需要使用到事務(wù)。所以需要避開事務(wù)失效的一些經(jīng)典場(chǎng)景。
方法的訪問權(quán)限必須是public，其他private等權(quán)限，事務(wù)失效 方法被定義成了final的，這樣會(huì)導(dǎo)致事務(wù)失效。 在同一個(gè)類中的方法直接內(nèi)部調(diào)用，會(huì)導(dǎo)致事務(wù)失效。 一個(gè)方法如果沒交給spring管理，就不會(huì)生成spring事務(wù)。 多線程調(diào)用，兩個(gè)方法不在同一個(gè)線程中，獲取到的數(shù)據(jù)庫連接不一樣的。 表的存儲(chǔ)引擎不支持事務(wù) 如果自己try...catch誤吞了異常，事務(wù)失效。 錯(cuò)誤的傳播特性
推薦大家看下這篇文章：聊聊spring事務(wù)失效的12種場(chǎng)景，太坑了
30. 掌握常用的設(shè)計(jì)模式
把代碼寫好，還是需要熟練常用的設(shè)計(jì)模式，比如策略模式、工廠模式、模板方法模式、觀察者模式等等。設(shè)計(jì)模式，是代碼設(shè)計(jì)經(jīng)驗(yàn)的總結(jié)。使用設(shè)計(jì)模式可以可重用代碼、讓代碼更容易被他人理解、保證代碼可靠性。
我之前寫過一篇總結(jié)工作中常用設(shè)計(jì)模式的文章，寫得挺不錯(cuò)的，大家可以看下：實(shí)戰(zhàn)！工作中常用到哪些設(shè)計(jì)模式
31. 寫代碼時(shí)，考慮線性安全問題
在高并發(fā)情況下，HashMap可能會(huì)出現(xiàn)死循環(huán)。因?yàn)樗欠蔷€性安全的，可以考慮使用ConcurrentHashMap。所以這個(gè)也盡量養(yǎng)成習(xí)慣，不要上來反手就是一個(gè)new HashMap();
Hashmap、Arraylist、LinkedList、TreeMap等都是線性不安全的； Vector、Hashtable、ConcurrentHashMap等都是線性安全的
32.接口定義清晰易懂，命名規(guī)范。
我們寫代碼，不僅僅是為了實(shí)現(xiàn)當(dāng)前的功能，也要有利于后面的維護(hù)。說到維護(hù)，代碼不僅僅是寫給自己看的，也是給別人看的。所以接口定義要清晰易懂，命名規(guī)范。
33. 接口的版本控制
接口要做好版本控制。就是說，請(qǐng)求基礎(chǔ)報(bào)文，應(yīng)該包含version接口版本號(hào)字段，方便未來做接口兼容。其實(shí)這個(gè)點(diǎn)也算接口擴(kuò)展性的一個(gè)體現(xiàn)點(diǎn)吧。
比如客戶端APP某個(gè)功能優(yōu)化了，新老版本會(huì)共存，這時(shí)候我們的version版本號(hào)就派上用場(chǎng)了，對(duì)version做升級(jí)，做好版本控制。
34. 注意代碼規(guī)范問題
注意一些常見的代碼壞味道：
大量重復(fù)代碼（抽共用方法，設(shè)計(jì)模式） 方法參數(shù)過多（可封裝成一個(gè)DTO對(duì)象） 方法過長(zhǎng)（抽小函數(shù)） 判斷條件太多（優(yōu)化if...else） 不處理沒用的代碼 不注重代碼格式 避免過度設(shè)計(jì)
代碼的壞味道，這里我都寫到啦：25種代碼壞味道總結(jié)+優(yōu)化示例
35.保證接口正確性，其實(shí)就是保證更少的bug
保證接口的正確性，換個(gè)角度講，就是保證更少的bug，甚至是沒有bug。所以接口開發(fā)完后，一般需要開發(fā)自測(cè)一下。然后的話，接口的正確還體現(xiàn)在，多線程并發(fā)的時(shí)候，保證數(shù)據(jù)的正確性,等等。比如你做一筆轉(zhuǎn)賬交易，扣減余額的時(shí)候，可以通過CAS樂觀鎖的方式保證余額扣減正確吧。
如果你是實(shí)現(xiàn)秒殺接口，得防止超賣問題吧。你可以使用Redis分布式鎖防止超賣問題。使用Redis分布式鎖，有幾個(gè)注意要點(diǎn)，大家可以看下我之前這篇文章哈：七種方案！探討Redis分布式鎖的正確使用姿勢(shì)
36.學(xué)會(huì)溝通，跟前端溝通，跟產(chǎn)品溝通
我把這一點(diǎn)放到最后，學(xué)會(huì)溝通是非常非常重要的。比如你開發(fā)定義接口時(shí)，一定不能上來就自己埋頭把接口定義完了，需要跟客戶端先對(duì)齊接口。遇到一些難點(diǎn)時(shí)，跟技術(shù)leader對(duì)齊方案。實(shí)現(xiàn)需求的過程中，有什么問題，及時(shí)跟產(chǎn)品溝通。
總之就是，開發(fā)接口過程中，一定要溝通好~
最后(求關(guān)注，別白嫖我)
如果這篇文章對(duì)您有所幫助，或者有所啟發(fā)的話，求一鍵三連：點(diǎn)贊、轉(zhuǎn)發(fā)、在看，您的支持是我堅(jiān)持寫作最大的動(dòng)力。
推薦閱讀：
歡迎關(guān)注微信公眾號(hào)：互聯(lián)網(wǎng)全棧架構(gòu)，收取更多有價(jià)值的信息。