接口設(shè)計技巧
2022-05-11 11:00:45

原文鏈接：https://mp.weixin.qq.com/s/Zri7YMhZINV1Mu2DPUecPA

---

1. 接口參數(shù)校驗

入?yún)⒊鰠⑿ｒ炇敲總€程序員必備的基本素養(yǎng)。設(shè)計接口，必須先校驗參數(shù)。

比如入?yún)⑹欠裨试S為空，入?yún)㈤L度是否符合預(yù)期長度。這個要養(yǎng)成習(xí)慣，日常開發(fā)中，很多低級 bug 都是不校驗參數(shù)導(dǎo)致的。

比如你的數(shù)據(jù)庫表字段設(shè)置為varchar(16)，對方傳了一個 32 位的字符串過來，如果你不校驗參數(shù)，插入數(shù)據(jù)庫就直接異常了。

出參也是，比如你定義的接口報文，參數(shù)是不為空的，但是你的接口返回參數(shù)沒有做校驗，因為程序某些原因，返回別人一個null值。

2. 修改老接口，注意接口的兼容性

很多 bug 都是因為修改了對外老接口但是卻不做兼容導(dǎo)致的。關(guān)鍵這個問題多數(shù)是比較嚴(yán)重的，可能直接導(dǎo)致系統(tǒng)發(fā)版失敗。新手程序員很容易犯這個錯誤。所以，如果你的需求是在原來接口上做修改，尤其這個接口是對外提供服務(wù)的話，一定要考慮接口兼容。

舉個例子吧，比如 dubbo 接口，原本是只接收 A、B 參數(shù)，現(xiàn)在加了一個參數(shù) C，就可以考慮這樣處理（方法重載）：

//老接口
void oldService(A,B){
  //兼容新接口，傳個null代替C
  newService(A,B,null);
}

//新接口，暫時不能刪掉老接口，需要做兼容。
void newService(A,B,C){
  ...
}

3. 設(shè)計接口時，充分考慮接口的可擴(kuò)展性

要根據(jù)實際業(yè)務(wù)場景設(shè)計接口，充分考慮接口的可擴(kuò)展性。

比如你接到一個需求：用戶添加或者修改員工時，需要刷臉。那你是反手提供一個員工管理的提交刷臉信息接口呢？還是先思考：提交刷臉是不是通用流程呢？

比如轉(zhuǎn)賬或者一鍵貼現(xiàn)需要接入刷臉的話，你是否需要重新實現(xiàn)一個接口呢？還是當(dāng)前按業(yè)務(wù)類型劃分模塊，復(fù)用這個接口就好，保留接口的可擴(kuò)展性。

如果按模塊劃分的話，未來如果其他場景比如一鍵貼現(xiàn)接入刷臉的話，不用再搞一套新的接口，只需要新增枚舉，然后復(fù)用刷臉通過流程接口，實現(xiàn)一鍵貼現(xiàn)刷臉的差異化即可。

4. 接口考慮是否需要做防重處理

如果前端重復(fù)請求，你的邏輯如何處理？是不是考慮接口去重處理。當(dāng)然，如果是查詢類的請求，其實不用防重。如果是更新修改類的話，尤其金融轉(zhuǎn)賬類的，就要過濾重復(fù)請求了。簡單點，你可以使用 Redis 防重復(fù)請求，同樣的請求方，一定時間間隔內(nèi)的相同請求，考慮是否過濾。當(dāng)然，轉(zhuǎn)賬類接口，并發(fā)不高的話，推薦使用數(shù)據(jù)庫防重表，以唯一流水號作為主鍵或者唯一索引。

5. 重點接口，考慮線程池隔離

一些登錄、轉(zhuǎn)賬交易、下單等重要接口，考慮線程池隔離。

如果你所有業(yè)務(wù)都共用一個線程池，有些業(yè)務(wù)出 bug 導(dǎo)致線程池阻塞打滿的話，那就杯具了，所有業(yè)務(wù)都影響了。因此進(jìn)行線程池隔離，重要業(yè)務(wù)分配多一點的核心線程，就能更好保護(hù)重要業(yè)務(wù)。

6. 調(diào)用第三方接口要考慮異常和超時處理

如果你調(diào)用第三方接口，或者分布式遠(yuǎn)程服務(wù)的話，需要考慮：

• 異常處理

比如，你調(diào)別人的接口，如果異常了，怎么處理，是重試還是當(dāng)做失敗還是告警處理。

• 接口超時

沒法預(yù)估對方接口多久返回，一般設(shè)置個超時斷開時間，以保護(hù)你的接口。之前見過一個生產(chǎn)問題，就是 http 調(diào)用不設(shè)置超時時間，最后響應(yīng)方進(jìn)程假死，請求一直占著線程不釋放，拖垮線程池。

• 重試次數(shù)

你的接口調(diào)失敗，需不需要重試？重試幾次？需要站在業(yè)務(wù)角度思考這個問題。

7. 接口實現(xiàn)考慮熔斷和降級

當(dāng)前互聯(lián)網(wǎng)系統(tǒng)一般都是分布式部署的。而分布式系統(tǒng)中經(jīng)常會出現(xiàn)某個基礎(chǔ)服務(wù)不可用，最終導(dǎo)致整個系統(tǒng)不可用的情況，這種現(xiàn)象被稱為服務(wù)雪崩效應(yīng)。

比如分布式調(diào)用鏈路A->B->C....，下圖所示：

如果服務(wù) C 出現(xiàn)問題，比如是因為慢 SQL 導(dǎo)致調(diào)用緩慢，那將導(dǎo)致 B 也會延遲，從而 A 也會延遲。

堵住的 A 請求會消耗占用系統(tǒng)的線程、IO 等資源。當(dāng)請求 A 的服務(wù)越來越多，占用計算機(jī)的資源也越來越多，

最終會導(dǎo)致系統(tǒng)瓶頸出現(xiàn)，造成其他的請求同樣不可用，最后導(dǎo)致業(yè)務(wù)系統(tǒng)崩潰。

為了應(yīng)對服務(wù)雪崩，常見的做法是熔斷和降級。最簡單是加開關(guān)控制，當(dāng)下游系統(tǒng)出問題時，開關(guān)降級，不再調(diào)用下游系統(tǒng)。還可以選用開源組件Hystrix。

8. 日志打印好，接口的關(guān)鍵代碼，要有日志保駕護(hù)航

關(guān)鍵業(yè)務(wù)代碼無論身處何地，都應(yīng)該有足夠的日志保駕護(hù)航。

比如：你實現(xiàn)轉(zhuǎn)賬業(yè)務(wù)，轉(zhuǎn)個幾百萬，然后轉(zhuǎn)失敗了，接著客戶投訴，然后你還沒有打印到日志，想想那種水深火熱的困境下，你卻毫無辦法。。。

那么，你的轉(zhuǎn)賬業(yè)務(wù)都需要哪些日志信息呢？至少，方法調(diào)用前，入?yún)⑿枰蛴“?，接口調(diào)用后，需要捕獲一下異常吧，同時打印異常相關(guān)日志，如下：

public?void?transfer(TransferDTO?transferDTO){
????log.info("invoke?tranfer?begin");
????//打印入?yún)?????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");
????}

9. 接口的功能定義要具備單一性

單一性是指接口做的事情比較單一、專一。比如一個登錄接口，它做的事情就只是校驗賬戶名密碼，然后返回登錄成功以及userId即可。

但是如果為了減少接口交互，把一些注冊、一些配置查詢等全放到登錄接口，就不太妥。

其實這也是微服務(wù)一些思想，接口的功能單一、明確。比如訂單服務(wù)、積分、商品信息相關(guān)的接口都是劃分開的。將來拆分微服務(wù)的話，是不是就比較簡便啦。

10. 接口有些場景，使用異步更合理

舉個簡單的例子，比如實現(xiàn)一個用戶注冊的接口，用戶注冊成功時，發(fā)個郵件或者短信去通知用戶。這個郵件或者發(fā)短信，就更適合異步處理。因為總不能一個通知類的失敗，導(dǎo)致注冊失敗吧。至于做異步的方式，簡單的就是用線程池。還可以使用消息隊列，就是用戶注冊成功后，生產(chǎn)者產(chǎn)生一個注冊成功的消息，消費者拉到注冊成功的消息，就發(fā)送通知。

?

不是所有的接口都適合設(shè)計為同步接口。比如你要做一個轉(zhuǎn)賬的功能，如果是單筆的轉(zhuǎn)賬，你是可以把接口設(shè)計同步。

用戶發(fā)起轉(zhuǎn)賬時，客戶端再靜靜等待轉(zhuǎn)賬結(jié)果就好。如果是批量轉(zhuǎn)賬，一個批次一千筆，甚至一萬筆的，你則可以把接口設(shè)計為異步。就是用戶發(fā)起批量轉(zhuǎn)賬時，持久化成功就先返回受理成功。然后用戶隔十分鐘或者十五分鐘再來查轉(zhuǎn)賬結(jié)果就好。又或者，批量轉(zhuǎn)賬成功后，再回調(diào)上游系統(tǒng)。

11. 優(yōu)化接口耗時，遠(yuǎn)程串行考慮改并行調(diào)用

假設(shè)我們設(shè)計一個 APP 首頁的接口，它需要查用戶信息、需要查 banner 信息、需要查彈窗信息等等。那是一個一個接口串行調(diào)，還是并行調(diào)用呢？

如果是串行一個一個查，比如查用戶信息 200ms，查 banner 信息 100ms、查彈窗信息 50ms，那一共就耗時350ms了，如果還查其他信息，那耗時就更大了。這種場景是可以改為并行調(diào)用的。也就是說查用戶信息、查 banner 信息、查彈窗信息，可以同時發(fā)起。

12. 接口合并或者說考慮批量處理思想

數(shù)據(jù)庫操作或者是遠(yuǎn)程調(diào)用時，能批量操作就不要 for 循環(huán)調(diào)用。

一個簡單例子，我們平時一個列表明細(xì)數(shù)據(jù)插入數(shù)據(jù)庫時，不要在 for 循環(huán)一條一條插入，建議一個批次幾百條，進(jìn)行批量插入。

同理遠(yuǎn)程調(diào)用也類似想法，比如你查詢營銷標(biāo)簽是否命中，可以一個標(biāo)簽一個標(biāo)簽去查，也可以批量標(biāo)簽去查，那批量進(jìn)行，效率就更高嘛。

//反例
for(int?i=0;i<n;i++){
??remoteSingleQuery(param)
}

//正例
remoteBatchQuery(param);

小伙伴們是否了解過kafka為什么這么快呢？其實其中一點原因，就是 kafka?使用批量消息提升服務(wù)端處理能力。

13. 接口實現(xiàn)過程中，恰當(dāng)使用緩存

哪些場景適合使用緩存？讀多寫少且數(shù)據(jù)時效要求越低的場景。

緩存用得好，可以承載更多的請求，提升查詢效率，減少數(shù)據(jù)庫的壓力。

比如一些平時變動很小或者說幾乎不會變的商品信息，可以放到緩存，請求過來時，先查詢緩存，如果沒有再查數(shù)據(jù)庫，并且把數(shù)據(jù)庫的數(shù)據(jù)更新到緩存。但是，使用緩存增加了需要考慮這些點：緩存和數(shù)據(jù)庫一致性如何保證、集群、緩存擊穿、緩存雪崩、緩存穿透等問題。

• 保證數(shù)據(jù)庫和緩存一致性：緩存延時雙刪、刪除緩存重試機(jī)制、讀取 biglog 異步刪除緩存。
• 緩存擊穿：設(shè)置數(shù)據(jù)永不過期。
• 緩存雪崩：Redis 集群高可用、均勻設(shè)置過期時間。
• 緩存穿透：接口層校驗、查詢?yōu)榭赵O(shè)置個默認(rèn)空值標(biāo)記、布隆過濾器。

一般用Redis分布式緩存，當(dāng)然有些時候也可以考慮使用本地緩存，如Guava Cache、Caffeine等。

使用本地緩存有些缺點，就是無法進(jìn)行大數(shù)據(jù)存儲，并且應(yīng)用進(jìn)程的重啟，緩存會失效。

14. 接口考慮熱點數(shù)據(jù)隔離性

瞬時間的高并發(fā)，可能會打垮你的系統(tǒng)?？梢宰鲆恍狳c數(shù)據(jù)的隔離。比如業(yè)務(wù)隔離、系統(tǒng)隔離、用戶隔離、數(shù)據(jù)隔離等。

• 業(yè)務(wù)隔離：比如 12306 的分時段售票，將熱點數(shù)據(jù)分散處理，降低系統(tǒng)負(fù)載壓力。
• 系統(tǒng)隔離：比如把系統(tǒng)分成了用戶、商品、社區(qū)三個板塊。這三個塊分別使用不同的域名、服務(wù)器和數(shù)據(jù)庫，做到從接入層到應(yīng)用層再到數(shù)據(jù)層三層完全隔離。
• 用戶隔離：重點用戶請求到配置更好的機(jī)器。
• 數(shù)據(jù)隔離：使用單獨的緩存集群或者數(shù)據(jù)庫服務(wù)熱點數(shù)據(jù)。

15. 可變參數(shù)配置化，比如紅包皮膚切換等

假如產(chǎn)品經(jīng)理提了個紅包需求，圣誕節(jié)的時候，紅包皮膚為圣誕節(jié)相關(guān)的，春節(jié)的時候，為春節(jié)紅包皮膚等。

如果在代碼寫死控制，可有類似以下代碼：

if(duringChristmas){
???img?=?redPacketChristmasSkin;
}else?if(duringSpringFestival){
???img?=??redSpringFestivalSkin;
}

如果到了元宵節(jié)的時候，運營小姐姐突然又有想法，紅包皮膚換成燈籠相關(guān)的，這時候，是不是要去修改代碼了，重新發(fā)布了？

從一開始接口設(shè)計時，可以實現(xiàn)一張紅包皮膚的配置表，將紅包皮膚做成配置化。更換紅包皮膚，只需修改一下表數(shù)據(jù)就好了。

當(dāng)然，還有一些場景適合一些配置化的參數(shù)：一個分頁多少數(shù)量控制、某個搶紅包多久時間過期這些，都可以搞到參數(shù)配置化表里面。這也是擴(kuò)展性思想的一種體現(xiàn)。

16. 接口考慮冪等性

接口是需要考慮冪等性的，尤其搶紅包、轉(zhuǎn)賬這些重要接口。最直觀的業(yè)務(wù)場景，就是用戶連著點擊兩次，你的接口有沒有?hold 住?；蛘呦㈥犃谐霈F(xiàn)重復(fù)消費的情況，你的業(yè)務(wù)邏輯怎么控制？

回憶下，什么是冪等？

計算機(jī)科學(xué)中，冪等表示一次和多次請求某一個資源應(yīng)該具有同樣的副作用，或者說，多次請求所產(chǎn)生的影響與一次請求執(zhí)行的影響效果相同。

大家別搞混哈，防重和冪等設(shè)計其實是有區(qū)別的。防重主要為了避免產(chǎn)生重復(fù)數(shù)據(jù)，把重復(fù)請求攔截下來即可。

而冪等設(shè)計除了攔截已經(jīng)處理的請求，還要求每次相同的請求都返回一樣的效果。不過呢，很多時候，它們的處理流程、方案是類似的。

接口冪等實現(xiàn)方案主要有 8 種：

• select + insert + 主鍵/唯一索引沖突
• 直接 insert + 主鍵/唯一索引沖突
• 狀態(tài)機(jī)冪等
• 抽取防重表
• token 令牌
• 悲觀鎖
• 樂觀鎖
• 分布式鎖

17. 讀寫分離，優(yōu)先考慮讀從庫，注意主從延遲問題

我們的數(shù)據(jù)庫都是集群部署的，有主庫也有從庫，當(dāng)前一般都是讀寫分離的。

比如寫入數(shù)據(jù)，肯定是寫入主庫，但是對于讀取實時性要求不高的數(shù)據(jù)，則優(yōu)先考慮讀從庫，因為可以分擔(dān)主庫的壓力。

如果讀取從庫的話，需要考慮主從延遲的問題。

18. 接口注意返回的數(shù)據(jù)量，如果數(shù)據(jù)量大需要分頁

一個接口返回報文，不應(yīng)該包含過多的數(shù)據(jù)量。

過多的數(shù)據(jù)量不僅處理復(fù)雜，并且數(shù)據(jù)量傳輸?shù)膲毫σ卜浅４蟆?/p>

如果數(shù)量實在是比較大，可以分頁返回，如果是功能不相關(guān)的報文，那應(yīng)該考慮接口拆分。

19. 好的接口實現(xiàn)，離不開 SQL 優(yōu)化

我們做后端的，寫好一個接口，離不開 SQL 優(yōu)化。

SQL 優(yōu)化從以下這幾個維度思考：

• explain 分析 SQL 查詢計劃（重點關(guān)注 type、extra、filtered 字段）。
• show profile 分析，了解 SQL 執(zhí)行的線程的狀態(tài)以及消耗的時間。
• 索引優(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. 代碼鎖的粒度控制好

什么是加鎖粒度呢？

其實就是你要鎖住的范圍是多大。比如你在家上衛(wèi)生間，你只要鎖住衛(wèi)生間就可以了吧，不需要將整個家都鎖起來不讓家人進(jìn)門吧，衛(wèi)生間就是你的加鎖粒度。

我們寫代碼時，如果不涉及到共享資源，就沒有必要鎖住。這就好像你上衛(wèi)生間，不用把整個家都鎖住，鎖住衛(wèi)生間門就可以了。

比如，在業(yè)務(wù)代碼中，有一個 ArrayList 因為涉及到多線程操作，所以需要加鎖操作，假設(shè)剛好又有一段比較耗時的操作（代碼中的slowNotShare方法）不涉及線程安全問題，你會如何加鎖呢？

反例：

//不涉及共享資源的慢方法
private?void?slowNotShare()?{
????try?{
????????TimeUnit.MILLISECONDS.sleep(100);
????}?catch?(InterruptedException?e)?{
????}
}

//錯誤的加鎖方法
public?int?wrong()?{
????long?beginTime?=?System.currentTimeMillis();
????IntStream.rangeClosed(1,?10000).parallel().forEach(i?->?{
????????//加鎖粒度太粗了，slowNotShare其實不涉及共享資源
????????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();//可以不加鎖
????????//只對List這部分加鎖
????????synchronized?(data)?{
????????????data.add(i);
????????}
????});
????log.info("cosume?time:{}",?System.currentTimeMillis()?-?beginTime);
????return?data.size();
}

21. 接口狀態(tài)和錯誤需要統(tǒng)一明確

提供必要的接口調(diào)用狀態(tài)信息。比如一個轉(zhuǎn)賬接口調(diào)用是成功、失敗、處理中還是受理成功等，需要明確告訴客戶端。

如果接口失敗，那么具體失敗的原因是什么。這些必要的信息都必須要告訴給客戶端，因此需要定義明確的錯誤碼和對應(yīng)的描述。

同時，盡量對報錯信息封裝一下，不要把后端的異常信息完全拋出到客戶端。

22. 接口要考慮異常處理

實現(xiàn)一個好的接口，離不開優(yōu)雅的異常處理。

對于異常處理，提十個小建議：

• 盡量不要使用e.printStackTrace()，而是使用log打印。因為e.printStackTrace()語句可能會導(dǎo)致內(nèi)存占滿。
• catch住異常時，建議打印出具體的exception，利于更好定位問題。
• 不要用一個Exception捕捉所有可能的異常。
• 記得使用finally關(guān)閉流資源或者直接使用try-with-resource。
• 捕獲異常與拋出異常必須是完全匹配，或者捕獲異常是拋異常的父類。
• 捕獲到的異常，不能忽略它，至少打點日志吧。
• 注意異常對你的代碼層次結(jié)構(gòu)的侵染。
• 自定義封裝異常，不要丟棄原始異常的信息Throwable cause。
• 運行時異常RuntimeException?，不應(yīng)該通過catch的方式來處理，而是先預(yù)檢查，比如：NullPointerException處理。
• 注意異常匹配的順序，優(yōu)先捕獲具體的異常。

23. 優(yōu)化程序邏輯

優(yōu)化程序邏輯這塊還是挺重要的，也就是說，你實現(xiàn)的業(yè)務(wù)代碼，如果是比較復(fù)雜的話，建議把注釋寫清楚。還有，代碼邏輯盡量清晰，代碼盡量高效。

比如，要使用用戶信息的屬性，根據(jù) session 已經(jīng)獲取到userId了，然后就把用戶信息從數(shù)據(jù)庫查詢出來，使用完后，后面可能又要用到用戶信息的屬性，有些小伙伴沒想太多，反手就把userId再傳進(jìn)去，再查一次數(shù)據(jù)庫。。。我在項目中，見過這種代碼。。。直接把用戶對象傳下來不好嘛。。。

反例：

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對象過來即可，不用再多查一次數(shù)據(jù)庫
public?Response?do(UserInfo?user){
??......
??return?new?Response();?
}

當(dāng)然，這只是一些很小的一個例子，還有很多類似的例子，需要大家開發(fā)過程中，多點思考的哈。

24. 接口實現(xiàn)過程中，注意大文件、大事務(wù)、大對象

• 讀取大文件時，不要Files.readAllBytes直接讀取到內(nèi)存，這樣會 OOM 的，建議使用BufferedReader一行一行來。
• 大事務(wù)可能導(dǎo)致死鎖、回滾時間長、主從延遲等問題，開發(fā)中盡量避免大事務(wù)。
• 注意一些大對象的使用，因為大對象是直接進(jìn)入老年代的，可能會觸發(fā) fullGC。

25. 你的接口，需要考慮限流

如果你的系統(tǒng)每秒扛住的請求是 1000，如果一秒鐘來了十萬請求呢？換個角度就是說，高并發(fā)的時候，流量洪峰來了，超過系統(tǒng)的承載能力，怎么辦呢？

如果不采取措施，所有的請求打過來，系統(tǒng) CPU、內(nèi)存、Load 負(fù)載飚得很高，最后請求處理不過來，所有的請求無法正常響應(yīng)。

針對這種場景，我們可以采用限流方案。就是為了保護(hù)系統(tǒng)，多余的請求，直接丟棄。

限流定義：

在計算機(jī)網(wǎng)絡(luò)中，限流就是控制網(wǎng)絡(luò)接口發(fā)送或接收請求的速率，它可防止 DoS 攻擊和限制 Web 爬蟲。

限流，也稱流量控制。是指系統(tǒng)在面臨高并發(fā)，或者大流量請求的情況下，限制新的請求對系統(tǒng)的訪問，從而保證系統(tǒng)的穩(wěn)定性。

可以使用 Guava 的RateLimiter單機(jī)版限流，也可以使用Redis分布式限流，還可以使用阿里開源組件sentinel限流。

26. 代碼實現(xiàn)時，注意運行時異常（比如空指針、下標(biāo)越界等）

日常開發(fā)中，我們需要采取措施規(guī)避數(shù)組邊界溢出、被零整除、空指針等運行時錯誤。類似代碼比較常見：

String?name?=?list.get(1).getName();?//list可能越界，因為不一定有2個元素哈

應(yīng)該采取措施，預(yù)防一下數(shù)組邊界溢出。正例如下：

if(CollectionsUtil.isNotEmpty(list)&&?list.size()>1){
??String?name?=?list.get(1).getName();?
}

27. 保證接口安全性

如果你的 API 接口是對外提供的，需要保證接口的安全性。保證接口的安全性有?token 機(jī)制和接口簽名。

token 機(jī)制身份驗證方案還比較簡單的，就是：

1. 客戶端發(fā)起請求，申請獲取 token。
2. 服務(wù)端生成全局唯一的 token，保存到 redis 中（一般會設(shè)置一個過期時間），然后返回給客戶端。
3. 客戶端帶著 token，發(fā)起請求。
4. 服務(wù)端去 redis 確認(rèn) token 是否存在，一般用 redis.del(token) 的方式，如果存在會刪除成功，即處理業(yè)務(wù)邏輯，如果刪除失敗不處理業(yè)務(wù)邏輯，直接返回結(jié)果。

接口簽名的方式，就是把接口請求相關(guān)信息（請求報文，包括請求時間戳、版本號、appid 等），客戶端私鑰加簽，然后服務(wù)端用公鑰驗簽，驗證通過才認(rèn)為是合法的、沒有被篡改過的請求。

除了加簽驗簽和 token 機(jī)制，接口報文一般是要加密的。當(dāng)然，用 https 協(xié)議是會對報文加密的。如果是我們服務(wù)層的話，如何加解密呢？

可以參考 HTTPS 的原理，就是服務(wù)端把公鑰給客戶端，然后客戶端生成對稱密鑰，

接著客戶端用服務(wù)端的公鑰加密對稱密鑰，再發(fā)到服務(wù)端，服務(wù)端用自己的私鑰解密，得到客戶端的對稱密鑰。

這時候就可以愉快傳輸報文啦，客戶端用對稱密鑰加密請求報文，服務(wù)端用對應(yīng)的對稱密鑰解密報文。

有時候，接口的安全性，還包括手機(jī)號、身份證等信息的脫敏。就是說，用戶的隱私數(shù)據(jù)，不能隨便暴露。

28. 分布式事務(wù)，如何保證

分布式事務(wù)：就是指事務(wù)的參與者、支持事務(wù)的服務(wù)器、資源服務(wù)器以及事務(wù)管理器分別位于不同的分布式系統(tǒng)的不同節(jié)點之上。簡單來說，分布式事務(wù)指的就是分布式系統(tǒng)中的事務(wù)，它的存在就是為了保證不同數(shù)據(jù)庫節(jié)點的數(shù)據(jù)一致性。

分布式事務(wù)的幾種解決方案：

• 2PC（二階段提交）方案、3PC
• TCC（Try、Confirm、Cancel）
• 本地消息表
• 最大努力通知
• seata

29. 事務(wù)失效的一些經(jīng)典場景

我們的接口開發(fā)過程中，經(jīng)常需要使用到事務(wù)。所以需要避開事務(wù)失效的一些經(jīng)典場景。

• 方法的訪問權(quán)限必須是 public，其他 private 等權(quán)限，事務(wù)失效。
• 方法被定義成了 final 的，這樣會導(dǎo)致事務(wù)失效。
• 在同一個類中的方法直接內(nèi)部調(diào)用，會導(dǎo)致事務(wù)失效。
• 一個方法如果沒交給 spring 管理，就不會生成 spring 事務(wù)。
• 多線程調(diào)用，兩個方法不在同一個線程中，獲取到的數(shù)據(jù)庫連接不一樣的。
• 表的存儲引擎不支持事務(wù)。
• 如果自己 try...catch 誤吞了異常，事務(wù)失效。
• 錯誤的傳播特性。

30. 掌握常用的設(shè)計模式

把代碼寫好，還是需要熟練常用的設(shè)計模式，比如策略模式、工廠模式、模板方法模式、觀察者模式等等。

設(shè)計模式，是代碼設(shè)計經(jīng)驗的總結(jié)。使用設(shè)計模式可以重用代碼、讓代碼更容易被他人理解、保證代碼可靠性。

31. 寫代碼時，考慮線性安全問題

在高并發(fā)情況下，HashMap可能會出現(xiàn)死循環(huán)。因為它是非線性安全的，可以考慮使用ConcurrentHashMap。所以這個也盡量養(yǎng)成習(xí)慣，不要上來反手就是一個new HashMap()。

• Hashmap、Arraylist、LinkedList、TreeMap 等都是線性不安全的。
• Vector、Hashtable、ConcurrentHashMap 等都是線性安全的。

32. 接口定義清晰易懂，命名規(guī)范

我們寫代碼，不僅僅是為了實現(xiàn)當(dāng)前的功能，也要有利于后面的維護(hù)。

說到維護(hù)，代碼不僅僅是寫給自己看的，也是給別人看的。

所以接口定義要清晰易懂，命名規(guī)范。

33. 接口的版本控制

接口要做好版本控制。就是說，請求基礎(chǔ)報文，應(yīng)該包含version接口版本號字段，方便未來做接口兼容。其實這個點也算接口擴(kuò)展性的一個體現(xiàn)點吧。

比如客戶端 APP 某個功能優(yōu)化了，新老版本會共存，這時候我們的version版本號就派上用場了，對version做升級，做好版本控制。

34. 注意代碼規(guī)范問題

注意一些常見的代碼壞味道：

• 大量重復(fù)代碼（抽共用方法，設(shè)計模式）。
• 方法參數(shù)過多（可封裝成一個 DTO 對象）。
• 方法過長（抽小函數(shù)）。
• 判斷條件太多（優(yōu)化 if...else）。
• 不處理沒用的代碼。
• 不注重代碼格式。
• 避免過度設(shè)計。

35. 保證接口正確性，其實就是保證更少的 bug

保證接口的正確性，換個角度講，就是保證更少的bug，甚至是沒有bug。所以接口開發(fā)完后，一般需要開發(fā)自測一下。

然后的話，接口的正確性還體現(xiàn)在，多線程并發(fā)的時候，保證數(shù)據(jù)的正確性，等等。比如做一筆轉(zhuǎn)賬交易，扣減余額的時候，可以通過 CAS 樂觀鎖的方式保證余額扣減正確。

如果你是實現(xiàn)秒殺接口，得防止超賣問題吧?？梢允褂?Redis 分布式鎖防止超賣問題。

36. 學(xué)會溝通，跟前端溝通，跟產(chǎn)品溝通

我把這一點放到最后，學(xué)會溝通是非常非常重要的。

比如你開發(fā)定義接口時，一定不能上來就自己埋頭把接口定義完了，需要跟客戶端先對齊接口。遇到一些難點時，跟技術(shù) leader 對齊方案。

實現(xiàn)需求的過程中，有什么問題，及時跟產(chǎn)品溝通。

總之就是，開發(fā)接口過程中，一定要溝通好~

?