有一種場景：解耦
如果實現類沒有接口，如果有一天這個實現類不想用了，換成另一個實現類，眾多方法調用了我的實現類中的方法，那么是不是每一個調用我實現類的都要改一下呢？起碼注入的類要改成新類吧？這樣不利於擴展和解耦，因為你改變了東西我們都要改原來寫好的代碼(你要不影響我以前代碼的使用才行)，耦合度太高了。
如果是實現接口了的話，你們調用我的接口，只要注入接口就行了。如果我實現類更換了，那你也不需要更改注入的類了吧？
這是接口降低耦合度的一種。至少我換一個實現類或者改n次實現類的名字也不會讓調用方去跟着改，因為我接口沒變，你只是調我接口。
第二種場景：擴展
為什么會出現接口？不就是為了彌補單繼承的缺陷嗎？接口可以多繼承啊。假如我要實現的service接口它要擴展呢？繼承多個接口就好了。那么我要實現的這個接口不是又多了很多方法？我的接口只需要再繼承多個接口就多了很多方法。
或者假如我沒有實現接口，我這個類給別人注入使用，后來我這個類另一個人也想用同樣的那個方法，但是功能邏輯和原來的不一樣了，而且原來的功能別人也還在調用，那么我就得改原來的邏輯。但是如果使用接口就可以再寫一個實現類，另一個人用新的實現類的方法就行了，不用修改原來的方法。這符合開閉原則(對擴展開放，對修改關閉)。
這是接口利於擴展的一種。
第三種場景：設計模式
很多設計模式中會用到接口，抽象類。我們的service層完全可以使用多種設計模式來設計，提高代碼復用，健壯性。比如最常用的模板模式，張三和李四的功能
第四種場景：rpc遠程調用
springaop使用了兩種代理模式：jdk動態代理和cglib動態代理，他們可以來回切換。人家spring都沒拋棄jdk動態代理肯定是有他的可取之處的，畢竟jdk基於反射生成代理類很快。spring都鼓勵我們使用接口呢。不只是spring，dubbo，springCloud以及其他框架都鼓勵我們使用接口呢。
遠程調用，接口暴露了，但是卻不暴露實現細節。
總結：解耦，擴展，設計模式，rpc遠程調用。這些都是service層需要實現接口的理由。
應該還有很多理由。