背景
昨天跟同事聊天，他提了一個問題，我覺得挺有意思，分享給大家。
原話是這樣的：我提供了一個批量鎖庫存的接口，結果那誰傳了十萬條數據過來，把我弄死了，麻蛋，我就不應該給他提供這個批量的接口，我現在怎麼辦？（頭大）
所以，我們應不應該提供批量的接口呢？
我認爲不應該提供。
動機
首先，我們分析一下需要批量的動機。
客戶端（調用者）想把數據組裝成一個大List批量調用你的接口，肯定是考慮到如果一條一條調用你，中間的網絡開銷非常大，浪費很多時間，所以，他認爲批量調用你的接口，可以把這一部分耗時給節約了，提高他接口的響應速度。
危害
然後，我們再分析一下如果你提供了批量接口，會出現哪些危害呢。
第一點，客戶端相當於把他的壓力轉移到你這裏了，整個系統出現問題，誰背鍋，無需多言了。
第二點，本來客戶端一個請求一個請求來調用你的，你可以部署10臺機器來抗併發，結果現在一個請求過來10萬數據，全部打到你的一臺機器的一個線程中，你怎麼處理？多線程？多線程你也是在一臺機器裏面搞。加消息隊列再分發？這無疑大幅度增加了你的設計複雜度。
第三點，現在是10萬數據，以後呢？會不會出現100萬、1000萬來調你？不可控，只要你提供了，別人就可能來搞你。
所以，無論怎麼看，你都不應該提供批量接口，只要你提供了，無疑是在作死，而且死的心安理得，因爲確實是你的問題，你跟客戶端撕逼可能都撕不過。
因此，千萬不要提供批量接口。
客戶端調用的正確姿勢
那麼，問題來了，如果不提供批量接口，客戶端怎麼加快他的處理速度呢？
客戶端應該改變思維，不是一個請求一個請求的同步調用你的接口，而應該多個請求異步併發調用你的接口，這樣，你這邊完全不用修改，只要簡單的加機器就可以輕鬆實現無限擴容。
但是，客戶端的代碼並沒有那麼好寫，在java中，就是使用Future啦，或者直接使用Completable Future，有興趣的可以去看看Dubbo的源碼，新版本已經全部改成使用CompletableFuture來實現遠程調用了，當然，dubbo本身就是支持異步調用的，用起來很簡單，但是如果你是feign可能需要自己包一層了。
好了，今天我們這裏說的客戶端實際上是後端服務之間的調用，不包含前端那種批量導入的場景，就先分享到這裏了。
結語
最後，我想問，你們的系統服務之間有沒有批量的接口呢？又是怎麼處理這種大請求的呢？
歡迎留言討論。