熟悉spring的朋友应该知道，在spring体系中，如果一个接口有多个实现类，此时通过接口注入会导致启动报错，而如果我们在某个实现类上标记一个@Primary注解，那么spring为优先为我们注入这个实现。
由此，在我们复杂的业务场景中，可能会需要门面层这一层。
所谓门面层：就是随着业务的越来越复杂，我们可能对不同的客户需要走不同的实现，但返回的结果却是一样的。
举个例子，同样是下单这样的一个操作，我们系统可能会随着业务的发展支持多个租户，原先的租户可能仅是在支付宝下单，而新租户可能在微信下单，同样是下单操作，但不同的租户有着不同的逻辑。
在这个场景下，一个优秀的程序员一定会编写一个下单的接口，方便后期的业务拓展。
比如：
public interface OrderService{
Result order(OrderContext context);
}
我们可能一开始只会有一个实现类（支付宝支付），故而在其他模块中直接使用接口注入。这在初期当然是没有问题的。随着后期业务的扩大，可能又需要实现一个微信支付，可这个时候，一个接口就会有多个实现了，可是直接使用的接口注入，spring自然就不知道为我们注入谁了，启动会直接报错。
也许你会说，难道开发初期不会考虑到既支持支付宝，又支持微信吗？非等需要来了才改？一开始的设计就是有问题的。
是的，在我们实际工作中，确实有一部分情况下是初期设计不好，即便我们足够优秀，我们无法左右你身边人的技术功底，确实身边可能会有一些不够资深的开发者写出的代码会为我们后期埋下坑点。
但还有一种，就是你可能根本在前期想不到的需求，即便你是经验非常丰富，也未必能一次考虑到，比如我们突然有个需求，A租户取某一条数据时候使用mysql数据库，而B租户获取的时候使用http等等这类奇葩到你根本想不到的需求呢？
好了，接下来我们谈谈如果使用Primary的这一特性去编写一个门面层，去解决这类问题。
假如，我们在用户登录后的上下文对象中已经保存了当前用户的租户信息，我们需要根据这个租户去路由到不同的实现类。
你或许会增加如下的实现类，这里附上一段伪代码：
@Primary
@Service
public class OrderServiceProxy implements OrderService {
//注入这个接口所有的实现类，注意，当前这个代理类也会被注入
@Autowired
public List<OrderService> serviceImpls;
public Result order(OrderContext context){
//获取租户信息
String tntId = UserContext.current().getTntId();
//根据tntId去找应该去调用的实现类，你可以根据实现类的包名路径，
// 或是类上加注解，这里你可以自己去实现，这里假设你最终取的是第0个
return serviceImls.get(0).order(context);
}
}
确实，这样可以很好的引入一个门面层，解决我们的service多实现类路由的这样一个问题。
但如果你是一名爱思考的java开发者，你一定会思考下面的问题：
1、如果团队内有成员在OrderService中增加，修改方法，门面层就需要进行增加，修改，然而我们不希望门面层让基层的程序员感知。重点还有，每个方法的实现逻辑还都是一样的，无非就是找到对应的实现类去调用他，如果方法很多，会写非常多的重复代码。
2、我们可能不仅仅有OrderService，还有很多个若干个XXXService，这些Service的逻辑和OrderService一样，导致相同的逻辑我们需要编写很多个XXXServiceProxy。
接下来讲讲如果解决上面提到的第两个问题：
如果解决第一个问题？其实很简单，改为动态代理即可优雅解决，但你需要解决的难题是，把这个动态代理放入Spring Bean 容器中。
如何解决第二个问题？设置包扫描吧，把这些Service放在同一个包下方便去扫描，或是在这些Service上加上一个标记的注解，扫描到了后，自动创建动态代理再将这些动态代理放入Spring bean中，嗯，就这个思路。
使用这种形式编写门面层后你会发现还有个好处，就是这个门面层是个可插可拔的，如果未来某个租户我们不为他服务了，不打门面层的jar包，不会对我们代码有任何影响。
好了，这里主要讲解一个设计思路，如果有需要代码学习的，可以给作者打赏一波再加个关注私信联系我哈。
