微服务架构—自动化测试全链路设计

  • 背景
  • 被忽视的软件工程环节 - DEVTESTOPS
  • 微服务架构下测试复杂度和效率问题
  • 开发阶段 unitTest mock 外部依赖
  • 连调阶段 mock 外部依赖
  • 自动化测试阶段 mock 需求
  • autoTest Mock Gateway 浮出水面
  • 轻量级版本实现 整体逻辑架构 将 mock parameter 纳入服务框架标准 request contract 使用 AOP + RestEasy HttpClientRequest SPI 初步实现 Mock
  • 总结

背景

从SOA架构到现在大行其道的微服务架构,系统越拆越小,整体架构的复杂度也是直线上升,我们一直老生常谈的微服务架构下的技术难点及解决方案也日渐成熟(包括典型的数据一致性,系统调用带来的一致性问题,还是跨节点跨机房复制带来的一致性问题都有了很多解决方案),但是有一个环节我们明显忽略了。

在现在的微服务架构趋势下,微服务在运维层面和自动化部署方面基本上是比较完善了。从我个人经验来看,上层的开发、测试对微服务架构带来的巨大变化还在反应和学习中。

开发层面讨论微服务的更多是框架、治理、性能等,但是从完整的软件工程来看我们严重缺失分析、设计知识,这也是我们现在的工程师普遍缺乏的技术。

我们经常会发现一旦你想重构点东西是多么的艰难,就是因为在初期构造这栋建筑的时候严重缺失了通盘的分析、设计,最终导致这个建筑慢慢僵化最后人见人怕,因为他逐渐变成一个怪物。(比如,开发很少写unitTest,我们总是忽视单元测试背后产生的软件工程的价值。)

被忽视的软件工程环节 — DEVTESTOPS

我们有没有发现一个现象,在整个软件过程里,测试这个环节容易被忽视。任何一种软件工程模型都有QA环节,但是这个环节似乎很薄很弱,目前我们绝大多数工程师、架构师都严重低估了这个环节的力量和价值,还停留在无技术含量,手动功能测试低级效率印象里。

这主要是测试这个角色整个技术体系、工程化能力偏弱,一部分是客观大环境问题,还有一部分自身问题,没有让自己走出去,多去学习整个工程化的技术,多去了解开发的技术,生产上的物理架构,这会有助于测试放大自己的声音。

导致测试环节在国内整个设计创新薄弱的原因还有一个主要原因就是,开发工程师普遍没有完整的工程基础。在国外IT发达国家,日本、美国等,一个合格的开发工程师、测试工程师都是边界模糊的,自己开发产品自己测试,这需要切换思维模式,需要同时具备这两种能力,但是这才是整个软件工程的完整流程。

我们有没有想过一个问题,为什么现在大家都在谈论DevOps,而不是DevTestOps,为什么偏偏跳过测试这个环节,难道开发的系统需要具备良好的可运维性就不需要可测试性吗,开发需要具备运维能力,运维需要具备开发能力,为什么测试环节忽略了。

我们对QA环节的轻视,对测试角色的不重视其实带来的副作用是非常大的。

微服务架构下测试复杂度和效率问题

微服务的拆分粒度要比SOA细了很多,从容器化镜像自动部署来衡量,是拆小了之后很方便,但是拆小了之后会给整个开发、测试环节增加很大的复杂度和效率问题。

在SOA时期,契约驱动这个原则在微服务里也一样适用,跨部门需求定义好契约你就可以先开发上线了。但是这个里面最大的问题就是当前系统的部分连调问题和自动化回归问题,如果是新系统上线还需要做性能压测,这外部的依赖如何解决。

也许我们会说,不是应该依赖方先ready,然后我们紧接着进行测试、发布吗。如果是业务、架构合理的情况下,这种场景最大的问题就是我们的项目容易被依赖方牵制,这会带来很多问题,比如,研发人员需要切换出来做其他事情,branch一直挂着,不知道哪天突然来找你说可以对接了,也许这已经过去一个月或者更久,这种方式一旦养成习惯性研发流程就很容易产生线上BUG。

还有一种情况也是合理的情况就是平台提供方需要调用业务方的接口,这里面有一般调用的callback接口、交易链路上的marketing接口、配送routing接口等。

这里给大家分享我们目前正在进行中的marketing-cloud (营销云) 规则引擎项目。

marketing-cloud提供了一些营销类业务,有团购、优惠券、促销等,但是我们的业务方需要有自己个性化的营销活动玩法,我们需要在marketing-cloud规则引擎中抽象出业务方营销活动的返回信息,同时打通个性化营销活动与公共交易、结算环节,形成一个完整的业务流。

图片描述

这是一个marketing-cloud逻辑架构图,跟我们主题相关的就是营销规则引擎,他就是我们这里所说的合理的业务场景。

在整个正向下单过程中,营销规则引擎要肩负起既要提供marketing-cloud内的共用营销活动,还需要桥接外部营销中心的各类营销玩法,外部的营销中心会有多个,目前我们主要有两个。

由于这篇文章不是介绍营销平台怎么设计,所以这里不打算扩展话题。主要是起到抛砖引玉的目的,平台型的业务会存在各种各样的对外系统依赖的业务场景。文章接下来的部分将展开marketing-cloud 规则引擎在打通测试链路上的实践。

开发阶段 unitTest mock 外部依赖

在开发阶段,我们会经常性的编写单元测试来测试我们的逻辑,在编写unitTest的时候都需要mock周边的依赖,mock出来的对象分为两种类型,一种是不具有Assert逻辑的stub 桩对象,还有一种就是需要支持Assert的mocker模拟对象。

但是我们也不需要明显区分他们,两者的区别不是太明显,在编码规范内可能需要区分。

我们关心的是如何解决对象之间的依赖问题,各种mock框架其实提供了很多非常好用的工具,我们可以很轻松的mock周边的依赖。

given(marketingService.mixMarketingActivity(anyObject())).willReturn(stubResponse);
RuleCalculateResponse response = this.ruleCalculatorBiz.ruleCalculate(request);

这里我们mock了marketingService.mixMarketingActivity()方法。

Java世界里提供了很多好用的mock框架,比较流行好用的框架之一mockito可以轻松mock Service层的依赖,当然除了mockito之外还有很多优秀的mock框架。

这些框架大同小异,编写unitTest最大的问题就是如何重构逻辑使之更加便于测试,也就是代码是否具备很好的可测试性,是否已经消除了绝大多数private方法,private方法是否有某些指责是我们没有捕捉到业务概念。

连调阶段 mock 外部依赖

在我们完成了所有的开发,完善的单元测试保证了我们内部的逻辑是没有问题的(当然这里不讨论unitTest的case的设计是否完善情况)。

现在我们需要对接周边系统开发进行连调了,这个周边系统还是属于本平台之类的其他支撑系统。比如我们的marketing-cloud 规则引擎系统与下单系统之间的关系。在开发的时候我们编写unitTest是顺利的完成了开发解决的验证工作,但是现在面对连调问题。

系统需要正式的跑起来,但是我们缺乏对外部营销中心的依赖,我们怎么办。其实我们也需要在连调阶段mock外部依赖,只不过这个mock的技术和方法不是通过unitTest框架来支持,而是需要我们自己来设计我们的整个服务的开发架构。

首先要能识别本次request是需要mock的,那就需要某种mock parameter参数来提供识别能力。

我们来看下marketing-cloud 营销规则引擎在这块的一个初步尝试。

public interface CCMarketingCentralFacade {
    CallResponse callMarketingCentral(CallRequest request);
}
public interface ClassMarketingCentralFacade {
    CallResponse callMarketingCentral(CallRequest request);
}

营销规则引擎使用RestEasy client api作为rest调用框架。这两个Facade是营销平台对CCTalk、沪江网校沪江两大子公司营销中心发起调用的Facade。

(为了尽量还原我们的工程实践干货同时需要消除一些敏感信息的情况下,整篇文章所有的代码实例,我都删除了一些不影响阅读且和本文无关的代码,同时做了一些伪编码和省略,使代码更精简更便于阅读。)

在正常逻辑下,我们会根据营销路由key来决定调用哪个公司的营销中心接口,但是由于我们在开发这个项目的时候暂时业务方还没有存在的地址让我们对接,所以我们自己做了mock facade,来解决连调问题。

public class CCMarketingCentralFacadeMocker implements CCMarketingCentralFacade {

    @Override
    public CallResponse callMarketingCentral(CallRequest request) {

        CallResponse response = ...
        MarketingResultDto marketingResultDto = ...
        marketingResultDto.setTotalDiscount(new BigDecimal("90.19"));
        marketingResultDto.setUseTotalDiscount(true);

        response.getData().setMarketingResult(marketingResultDto);

        return response;
    }
}
public class ClassMarketingCentralFacadeMocker implements ClassMarketingCentralFacade {

    @Override
    public CallResponse callMarketingCentral(CallRequest request) {
        CallResponse response = ...

        MarketingResultDto marketingResultDto = ...
        marketingResultDto.setUseCoupon(true);
        marketingResultDto.setTotalDiscount(null);
        marketingResultDto.setUseTotalDiscount(false);

        List<MarketingProductDiscountDto> discountDtos = ...

        request.getMarketingProductTagsParameter().getMarketingTags().forEach(item -> {

            MarketingProductDiscountDto discountDto = ...
            discountDto.setProductId(item.getProductID());
            ...
            discountDtos.add(discountDto);
        });
...
        return response;
    }
}

我们定义了两个mock类,都是一些测试数据,就是为了解决在连调阶段的问题,也就是在DEV环境上的依赖问题。

有了mock facade之后就需要request定义mock parameter参数了。

public abstract class BaseRequest implements Serializable {
    public MockParameter mockParameter;
}
public class MockParameter {

    /**
     * mock cc 营销调用接口
     */
    public Boolean mockCCMarketingInterface;

    /**
     * mock class 营销调用接口
     */
    public Boolean mockClassMarketingInterface;

    /**
     * 是否自动化测试 mock
     */
    public Boolean useAutoTestMock;

    /**
     * 测试mock参数
     */
    public String testMockParam;

}

我们暂且忽略通用型之类的设计,这里只是我们在赶项目的情况下做的一个迭代尝试,等我们把这整个流程都跑通了再来考虑重构提取框架。

有了输入参数,我们就可以根据参数判断来动态注入mock facade。

自动化测试阶段 mock 需求

我们继续向前推进,过了连调阶段紧接着就进入测试环节,现在基本上大多数互联网公司都是自动化的测试,很少在有手动的,尤其是后端系统。

那么在autoTest阶段面临的一个问题就是,我们需要一个公共的autoTest地址,这个测试地址是不变的,我们在自动化测试下mock的facade bean的地址就是这个地址,这个地址输出的值需要能够对应到每次自动化脚本执行的上下文中。

我们有很多微服务系统来组成一个平台,每个服务都有依赖的第三方接口,原来在自动化测试这些服务的时候都需要去了解业务方系统的接口、DB、前台入口等,因为在编写自动化脚本的时候需要同步创建测试数据,最后才能Assert。

这个跨部门的沟通和协作效率严重低下,而且人员变动、系统变动都会直接影响上线周期,这里绝对值得创新来解决这个效率严重阻塞问题。

@Value("${marketing.cloud.business.access.url.mock}")
private String mockUrl;
/**
     * 自动化测试 mocker bean
     */
    @Bean("CCMarketingCentralFacadeTestMock")
    public CCMarketingCentralFacade CCMarketingCentralFacadeTestMock() {
        RestClientProxyFactoryBean<CCMarketingCentralFacade> restClientProxyFactoryBean ...
        restClientProxyFactoryBean.setBaseUri(this.mockUrl);
        ...
    }

    /**
     * 自动化测试 mocker bean
     */
    @Bean("ClassMarketingCentralFacadeTestMock")
    public ClassMarketingCentralFacade ClassMarketingCentralFacadeTestMock()  {
        RestClientProxyFactoryBean<ClassMarketingCentralFacade> restClientProxyFactoryBean ...
        restClientProxyFactoryBean.setBaseUri(this.mockUrl);
        ...
    }

这里的mockUrl就是我们抽象出来的统一的autoTest地址,在前面的mock parameter中有一个useAutoTestMock Boolean类型的参数,如果当前请求此参数为true,我们将动态注入自动化测试mock bean,后续的所有调用都会走到mockUrl指定的地方。

autoTest Mock Gateway 浮出水面

到目前为止,我们遇到了自动化测试统一的mock地址要收口所有微服务在这方面的需求。现在最大的问题就是,所有的微服务对外依赖的response都不相同,自动化脚本在执行的时候预先创建好的response要能适配到当前测试的上下文中。

比如,营销规则引擎,我们的自动化脚本在创建一个订单的时候需要预先构造好当前商品(比如,productID:101010),在获取外部营销中心提供的活动信息和抵扣信息的response,最后才能去Assert订单的金额和活动信息记录是否正确,这就是一次autoTest context。

图片描述

有两种方式来识别当前autoTest context,一种是在case执行的时候确定商品ID,最后通过商品ID来获取mock的response。还有一种就是支持传递autoTest mock参数给到mockUrl指定的服务,可以使用这个参数来识别当前测试上下文。

一个测试case可能会穿过很多微服务,这些所有的依赖服务可能都需要预设mock response,这基本上是一劳永逸的。

所以,我们抽象出了autoTest Mock Gateway(自动化测试mock网关服务),在整个自动化测试环节还有很多需要支持的工作,服务之间的鉴权,鉴权key的mock,加解密,加解密key的mock,自动化测试case交替并行执行等。

作为工程师的我们都希望用系统化、工程化的方式来解决整体问题,而不是个别点状问题。有了这个mock gateway我们可以做很多事情,也可以普惠所有需要的其他部门。

图片描述

在一次autoTest context里构造好mock response,然后通过mock parameter来动态识别具体的来源服务进行路由、鉴权、加解密等操作。

MockGateway是一个支点,我相信这个支点可以撬动很多测试空间和创新能力。

轻量级版本实现

接下来我们将展示在marketing-cloud 营销规则引擎中的初步尝试。

整体逻辑架构

图片描述

自动化脚本在每跑一个case的时候会创建当前case对应的autoTestContext,这里面都是一些meta data,用来表示这个case中所有涉及到的微服务系统哪些是需要走mock gateway的。

在mockGateway中所有的配置都是有一个autoTestContext所对应,如果没有autoTestContext说明是所有case共用。

将 mock parameter 纳入服务框架标准 request contract

要想打通整个微服务架构中的所有通道,就需要在标准request contract定义mockParameter,这是这一切的前提。

服务与服务之间调用走标准微服务request contract,服务与外部系统的依赖可以选择走HTTP Header,也可以选择走标准request,就要看我们的整个服务框架是否已经覆盖所有的产线及一些遗留系统的问题。

public abstract class BaseRequest implements Serializable {
    public MockParameter mockParameter;
}

BaseRequest是所有request的基类,这样才能保证所有的请求能够正常的传递。

使用 AOP + RestEasy HttpClientRequest SPI 初步实现 Mock

整个系统的开发架构分层依赖是:facade->biz->service,基本的所有核心逻辑都是在service中,请求的request dto最多不能越界到service层,按照规范讲request dto顶多滞留在biz层,但是在互联网的世界中一些都是可以快速迭代的,并不是多么硬性规定,及时重构是偿还技术债务的主要方法。

前面我们已经讲过,我们采用的RPC框架是RestEasy + RestEasy client,我们先来看下入口的地方。

@Component
@Path("v1/calculator/")
public class RuleCalculatorFacadeImpl extends BaseFacade implements RuleCalculatorFacade {
    @MockFacade(Setting = MockFacade.SETTING_REQUEST_MOCK_PARAMETER)
    public RuleCalculateResponse ruleCalculate(RuleCalculateRequest request)  {
    ...
    }
}

再看下service对象。

@Component
public class MarketingServiceImpl extends MarketingBaseService implements MarketingService {
    @MockFacade(Setting = MockFacade.SETTING_FACADE_MOCK_BEAN)
    public MarketingResult onlyExtendMarketingActivity(Marketing..Parameter tagsParameter) {
    ...
    }

我们重点看下@MockFacadeannotation 声明。

@Target({ElementType.METHOD})
@Retention(RetentionPolicy.RUNTIME)
public @interface MockFacade {

    String SETTING_REQUEST_MOCK_PARAMETER = "setting_request_mock_parameter";
    String SETTING_FACADE_MOCK_BEAN = "setting_facade_mock_bean";

    String Setting();
}

通过这个 annotation 我们的主要目的就是将mockParameter放到ThreadLocal中去和请求处理完时的清理工作。还有一个功能就是service层的mock bean处理。

@Aspect
@Component
@Slf4j
public class MockMarketingFacadeInterceptor {

    @Before("@annotation(mockFacade)")
    public void beforeMethod(JoinPoint joinPoint, MockFacade mockFacade) {

        String settingName = mockFacade.Setting();

        if (MockFacade.SETTING_REQUEST_MOCK_PARAMETER.equals(settingName)) {

            Object[] args = joinPoint.getArgs();
            if (args == null) return;

            List<Object> argList = Arrays.asList(args);
            argList.forEach(item -> {

                if (item instanceof BaseRequest) {
                    BaseRequest request = (BaseRequest) item;

                    if (request.getMockParameter() != null) {
                        MarketingBaseService.mockParameterThreadLocal.set(request.getMockParameter());
                        log.info("----setting mock parameter:{}", JSON.toJSONString(request.getMockParameter()));
                    }
                }
            });
        } else if (MockFacade.SETTING_FACADE_MOCK_BEAN.equals(settingName)) {

            MarketingBaseService marketingBaseService = (MarketingBaseService) joinPoint.getThis();
            marketingBaseService.mockBean();
            log.info("----setting mock bean.");
        }
    }

    @After("@annotation(mockFacade)")
    public void afterMethod(JoinPoint joinpoint, MockFacade mockFacade) {

        if (MockFacade.SETTING_FACADE_MOCK_BEAN.equals(mockFacade.Setting())) {

            MarketingBaseService marketingBaseService = (MarketingBaseService) joinpoint.getThis();
            marketingBaseService.mockRemove();

            log.info("----remove mock bean.");
        }

        if (MockFacade.SETTING_REQUEST_MOCK_PARAMETER.equals(mockFacade.Setting())) {

            MarketingBaseService.mockParameterThreadLocal.remove();

            log.info("----remove ThreadLocal. ThreadLocal get {}", MarketingBaseService.mockParameterThreadLocal.get());
        }
    }
}

这些逻辑完全基于一个约定,就是 MarketingBaseService,不具有通用型,只是在逐步的重构和提取中,最终会是一个plugin框架。

public abstract class MarketingBaseService extends BaseService {

    protected ClassMarketingCentralFacade classMarketingCentralFacade;

    protected CCMarketingCentralFacade ccMarketingCentralFacade;

    public static ThreadLocal<MockParameter> mockParameterThreadLocal = new ThreadLocal<>();

    public void mockBean() {

        MockParameter mockParameter = mockParameterThreadLocal.get();

        if (mockParameter != null &amp;&amp; mockParameter.mockClassMarketingInterface) {
            if (mockParameter.useAutoTestingMock) {
                this.setClassMarketingCentralFacade(SpringContextHolder.getBean("ClassMarketingCentralFacadeTestMock", ClassMarketingCentralFacade.class));
            } else {
                this.setClassMarketingCentralFacade(SpringContextHolder.getBean("ClassMarketingCentralFacadeMocker", ClassMarketingCentralFacadeMocker.class));
            }
        } else {
            this.setClassMarketingCentralFacade(SpringContextHolder.getBean("ClassMarketingCentralFacade", ClassMarketingCentralFacade.class));
        }

        if (mockParameter != null &amp;&amp; mockParameter.mockCCMarketingInterface) {
            if (mockParameter.useAutoTestingMock) {
                this.setCcMarketingCentralFacade(SpringContextHolder.getBean("CCMarketingCentralFacadeTestMock", CCMarketingCentralFacade.class));
            } else {
                this.setCcMarketingCentralFacade(SpringContextHolder.getBean("CCMarketingCentralFacadeMocker", CCMarketingCentralFacadeMocker.class));
            }
        } else {
            this.setCcMarketingCentralFacade(SpringContextHolder.getBean("CCMarketingCentralFacade", CCMarketingCentralFacade.class));
        }
    }

    public void mockRemove() {
        mockParameterThreadLocal.remove();
    }
}

我们可以顺利的将request中的mockParameter放到ThreadLocal中,可以动态的通过AOP的方式来注入相应的mockerBean。

现在我们还要处理的就是对mockGateway的调用将 _mockParameter 中的autoContext中的标示字符串放到HTTP Header中去。

@Component
public class MockHttpHeadSetting implements ClientRequestFilter {

    @Override
    public void filter(ClientRequestContext requestContext) throws IOException {

        MultivaluedMap<String, Object> header = requestContext.getHeaders();

        MockParameter mockParameter = MarketingBaseService.mockParameterThreadLocal.get();

        if (mockParameter != null &amp;&amp; StringUtils.isNotBlank(mockParameter.getTestingMockParam())) {
            header.add("Mock-parameter", mockParameter.getTestingMockParam());
        }
    }
}

接着在SPI(javax.ws.rs.ext.Providers )文件中配置即可

com.hujiang.marketingcloud.ruleengine.service.MockHttpHeadSetting

总结

在整个微服务架构的实践中,工程界一直缺少探讨的就是在微服务架构的测试这块,离我们比较近的是自动化测试,因为自动化测试基本上是所有系统都需要的。

但是有一块我们一直没有重视的就是全链路压力测试这块,在生产上进行全链路的真实的压力测试需要解决很多问题,比较重要的就是DB这块,压测的时候产生的所有交易数据不能够参与结算、财务流程,这就需要借助影子表来解决,所有的数据都不会写入最终的真实的交易数据中去。当然还有其他地方都需要解决,一旦打开全链路压测开关,应该需要处理所有产生数据的地方,这是一个庞大的工程,但是也会非常有意思。

本篇文章只是我们在这块的一个初步尝试,我们会继续扩展下去,在下次产线全链路压测的时候我们就可以借助现在的实践架构扩展起来。

作者:王清培 (沪江集团资深JAVA架构师)