# 昨日回顧 昨天我們討論了服務間是否應該提供批量介面的問題，很多同學留言討論，非常好，一起討論一起進步。 其中，留言最多的一種觀點是說可以提供，但是要限制條數，比如每次最多傳1000條資料過來。 說句實話，我們的專案很多也是這麼做的。 不過我還是堅持我的觀點，最好就不要提供批量介面。 因為隨著資料量的不斷增大，勢必導致儲存架構升級。 我們以商品查詢為例，資料量變大，肯定是要上Redis的吧，以前批量介面可能直接一個數據庫in就解決了，現在你是先走快取還是不走呢？走的話要改程式碼，不走的話效能肯定不高。資料量再繼續增大，分庫分表了，批量介面怎麼處理？上Elasticsearch了，怎麼處理？ 這裡，我們舉例是說的批量查詢，如果換成批量操作呢？每次儲存架構升級可能都要改這塊的程式碼，而且還有另外一個操蛋的問題，比如你們規定服務間呼叫超時最大是1秒鐘，超過1秒就有熔斷邏輯，那麼，你要不要單獨為這個批量介面配置超時？ 所以，批量介面極其容易形成瓶頸，需要花費巨大的代價去維護這個程式碼，還是不提供比較好。 當然，如果你們的資料量在可以預見的未來都不會增長到那麼大，提供一個批量介面也不是不可以，視情況自行決定哈。（資料量都沒有，還不趕緊跑路