不同的bean
spring项目中，在使用类dubbo微服务框架时候，需在项目中定义bean。
如：
<bean id="xxxService" class="com.xxx.xxx.xxxBean" init-method="init">
<property name="url" value="xxx"/>
<!--省略其他配置-->
</bean>
url属性用于定位到远程服务所在服务器，并进行后续调用。
在公司有一套与dubbo类似微服务框架，只需指定服务地址和服务对应的接口，即可进行调用。
此外，该框架还有以下功能：
- 根据当前项目环境，自动调用对应环境的远程服务。若当前应用部署在beta上，则自动调用远程服务的beta机器。
最近刚使用了一次这个rpc框架，遇到一个问题：
本次所需调用的远程服务aService在beta上几乎没数据。
为方便测试，在beta环境下，需强制指定调用远程服务的预发/ppe环境。
体现在xml上的是，需要指定远程服务ppe机器的ip地址，额外配置ip和port(端口)属性。
那么在beta测试时，xml配置如下：
<bean id="aService" class="com.xxx.xxx.xxxBean" init-method="init">
<property name="url" value="xxx"/>
<property name="ip" value="xxx.xxx.xxx.xxx"/>
<property name="port" value="1111"/>
<!--省略其他配置-->
</bean>
并且在上线时，需去掉ip和port属性，否则在线上也会调用远程服务的ppe环境。
如此一来，每次在上线时，需要新建一个分支，合并到master，甚是麻烦。
于是考虑能否在线下和线上使用不同的配置，即注入不同的bean。
考虑到在实际项目中，常在service层中发起远程调用，如：
@Service
public class HelloWorldServiceImpl implements HelloWorldService{
@Autowired
private AService aService;
public void sayHello(){
aService.sayHello();
}
}
在本次需求中，需要在不同环境中为HelloWorldServiceImpl类注入不同的bean，及aService。
为了做到这一点，首先考虑使用的是配置中心，如阿里的diamond等。
在配置中心上配置一个key为xxx.bean.name，线下环境的value为aServiceBeta，线上环境则为aService。
该配置明确在线下使用的bean为aServiceBeta，而线上使用的bean为aService。
于是，在xml中将两个bean都配置上。
<!--线上环境使用的bean-->
<bean id="aService" class="com.xxx.xxx.xxxBean" init-method="init">
<property name="url" value="xxx"/>
<!--省略其他配置-->
</bean>
<!--线下环境使用的bean-->
<bean id="aServiceBeta" class="com.xxx.xxx.xxxBean" init-method="init">
<property name="url" value="xxx"/>
<property name="ip" value="xxx.xxx.xxx.xxx"/>
<property name="port" value="1111"/>
<!--省略其他配置-->
</bean>
方案一
在spring中，依赖注入优先使用byType。本次需求根据bean的名称分环境注入，则需要byName。
首先考虑@Qualifier注解，该注解可指定需要注入的bean的名称。
于是考虑以下代码，假设XXX.get为从配置中心获取配置的静态方法。
@Autowired
@Qualifier(XXX.get(xxx.bean.name))
private AService aService;
然而，@Qualifier的注解参数只支持常量。
于是，该方案失败。
方案二
使用xml配置HelloWorldServiceImpl，如下：
<bean id = "helloWorldServiceImpl" class = "com.xxx.xxx.service.impl.HelloWorldServiceImpl">
<property name = "aService" ref="${xxx.bean.name}" />
</bean>
因为配置中心支持直接在xml文件中使用，则该方案可行。
但是，该方案需要在xml为每个使用到AService的服务实现类进行定义，并且这些服务中不仅使用到AService，配置略麻烦，且不利于修改。
方案三
在执行AService方法时，动态取出环境对应的bean。
如在线上执行AService的sayHello()方法时，动态决定应使用的bean为aService而非aServiceBeta。
我们都知道，Spring将所有的bean保存在一个称为beanFactory的map中。(因为平时使用的bean均为单例，所以此处用所有二字)
如果可以在调用服务时，根据bean的名称，从beanFactory中取出不同的bean，即可完成本次需求。
spring提供了类似new XmlApplcationContext(xxx).getBean(xxx)的方法从上下文中根据名字获取bean。
然而，这样的操作需要每次新建上下文，spring本身并不提供从项目当前上下文获取bean的功能。
好在，spring提供了另一个功能，允许bean保存上下文beanFactory。
在spring中，有一个接口BeanFactoryAware，在初始化实现该接口的bean时，spring会检查每个bean是否实现该接口。
若实现该接口，则调用其setBeanFactory方法，并将当前上下文beanFactory作为参数传入。
于是，可以新建一个如下的bean：
@Component
public class SpringFactoryUtil implements BeanFactoryAware {
private static BeanFactory beanFactory;
@Override
public void setBeanFactory(BeanFactory factory) throws BeansException {
SpringFactoryUtil.beanFactory = factory;
}
/**
* 根据beanName名字取得bean
*
* @param beanName
* @return
*/
public static <T> T getBean(String beanName) {
if (null != beanFactory) {
return (T) beanFactory.getBean(beanName);
}
return null;
}
}
该bean实现BeanFactoryAwarej接口，在setBeanFactoryf方法中，将上下文beanFactory保存到一个静态变量beanFactory中。
此外，该bean还提供根据beanName获取bean的方法，getBean。
后续操作可以通过getBean静态方法，按照名称在当前项目的上下文中取出对应的bean。
有个这个类，可以在AService外封装一层，命名为AFacade，如下：
@Component
public class AFacade implements AService{
@Override
public void sayHello(){
getAService().sayHello();
}
…………
private AService getAService(){
// XXX.get为从配置中心获取配置的静态方法。
return SpringFactoryUtil.getBean(XXX.get(xxx.bean.name));
}
}
AFacade实现AService接口，AService有的方法AFacade都有。
在调用对应方法时，AFacade按照环境(从配置中心取出不同值)在beanFactory中取出所需的aService，再进行方法调用。
于是HelloWorldServiceImpl代码变成：
@Service
public class HelloWorldServiceImpl implements HelloWorldService{
@Autowired
private AFacade aFacade;
…………
}
该方案只需新增一个AFacade类，即可实现不同环境注入不同bean的需求。
此外，在其余需要使用AService的类中，直接注入aFacade这个bean即可。
对比方案二和方案三，最终选择方案三。
虽然方案三需要在运行时动态决定需要使用的bean，多一个步骤。
然而，aService和aServiceBeta这两个bean都为单例，都保存在map中，从map中get数据和从配置中心get数据的开销是很小的。
网友评论