在不同环境下(线下/预发/线上),使用不同的bean

不同的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数据的开销是很小的。

最后编辑于
©著作权归作者所有,转载或内容合作请联系作者
平台声明:文章内容(如有图片或视频亦包括在内)由作者上传并发布,文章内容仅代表作者本人观点,简书系信息发布平台,仅提供信息存储服务。

推荐阅读更多精彩内容