有一种场景：解耦
如果实现类没有接口，如果有一天这个实现类不想用了，换成另一个实现类，众多方法调用了我的实现类中的方法，那么是不是每一个调用我实现类的都要改一下呢？起码注入的类要改成新类吧？这样不利于扩展和解耦，因为你改变了东西我们都要改原来写好的代码(你要不影响我以前代码的使用才行)，耦合度太高了。
如果是实现接口了的话，你们调用我的接口，只要注入接口就行了。如果我实现类更换了，那你也不需要更改注入的类了吧？
这是接口降低耦合度的一种。至少我换一个实现类或者改n次实现类的名字也不会让调用方去跟着改，因为我接口没变，你只是调我接口。
第二种场景：扩展
为什么会出现接口？不就是为了弥补单继承的缺陷吗？接口可以多继承啊。假如我要实现的service接口它要扩展呢？继承多个接口就好了。那么我要实现的这个接口不是又多了很多方法？我的接口只需要再继承多个接口就多了很多方法。
或者假如我没有实现接口，我这个类给别人注入使用，后来我这个类另一个人也想用同样的那个方法，但是功能逻辑和原来的不一样了，而且原来的功能别人也还在调用，那么我就得改原来的逻辑。但是如果使用接口就可以再写一个实现类，另一个人用新的实现类的方法就行了，不用修改原来的方法。这符合开闭原则(对扩展开放，对修改关闭)。
这是接口利于扩展的一种。
第三种场景：设计模式
很多设计模式中会用到接口，抽象类。我们的service层完全可以使用多种设计模式来设计，提高代码复用，健壮性。比如最常用的模板模式，张三和李四的功能
第四种场景：rpc远程调用
springaop使用了两种代理模式：jdk动态代理和cglib动态代理，他们可以来回切换。人家spring都没抛弃jdk动态代理肯定是有他的可取之处的，毕竟jdk基于反射生成代理类很快。spring都鼓励我们使用接口呢。不只是spring，dubbo，springCloud以及其他框架都鼓励我们使用接口呢。
远程调用，接口暴露了，但是却不暴露实现细节。
总结：解耦，扩展，设计模式，rpc远程调用。这些都是service层需要实现接口的理由。
应该还有很多理由。