万字长文:一文详解单元测试干了什么

架构互联高可用 2024-03-02 15:27:53

导读

随着我们各种“code大赛”的不断推进,大家对于单元测试也越发重视。好的单元测试不仅可以验证代码结构设计得是否合理,而且可以提前发现代码中的漏洞,将线上风险扼杀在摇篮中。写好单元测试是每一位程序员的基本功,但是有不少同学对于单元测试有些知其然但不知其所以然,对于单元测试的底层逻辑并未深入研究过,只停留在使用的层面。本文从常用的单元测试框架出发,对Mockito框架深入浅出的讲解,希望能帮到每一位同学。

单元测试框架

Java中存在很多单元测试框架,每种框架有着自己独特的特点,根据不同的需求和团队要求,每位同学所使用的框架不尽相同,目前主流的测试框架有且不仅有以下几种:

JUnit

JUnit是Java中最常用的单元测试框架。该框架提供了丰富的测试与断言方法,例如:assert、assertTrue、assertEquals等,使用方法比较简单。JUnit目前已经更新到JUnit5版本,该版本提供了更多的新特性,例如:动态测试,依赖注入等,使得该框架更为健壮。

官网介绍:https://junit.org/junit5/

TestNG

TestNG是Java中的另一种测试框架,集团内使用的较为小众。该框架的设计是受了JUnit的启发,初衷是为了更好地支持从单元测试到集成测试的各个方面,用来完成一些JUnit所不能完成的测试任务。该框架较JUnit相比,功能更加强大,提供了更多的高级特性,例如:测试套件、数据驱动测试、依赖测试、并行测试等。在更复杂的测试场景(如参数化测试、依赖测试等)中,TestNG的表现更加优异。官网介绍:https://testng.org/

Spock

Spock是基于Groovy语言编写的测试框架,该框架可以用来测试Java和Groovy的代码程序。Spock用来写测试代码的语言十分优美、表达力强,这一优点大大提高了测试代码的可读性和可维护性。Spock框架融合了JUnit、jMock、RSpec、Groovy、Scala和Vulcans等多种框架和语言的优点,旨在提供一套强大的测试平台。官网介绍:https://spockframework.org/

Mockito

Mockito不是一个完整的单元测试框架,而是专注于mock对象的创建、验证。它通常与JUnit或TestNG结合使用来简化对复杂依赖的测试。是目前集团内最主流的测试框架,下文中将对该框架进行详细阐述。

官网介绍:http://site.mockito.org/

EasyMock

EasyMock是一套通过简单方法对于给定的接口生成mock对象的类库,通过使用Java代理机制动态生成模拟对象。该框架提供对接口的模拟,能够通过录制、回放、检查三步来完成大体的测试过程,可以验证方法的调用种类、次数、顺序等,还可以令mock对象返回指定的值或抛出指定异常。开发者通过EasyMock可以方便的构造mock对象而忽略对象背后真正的业务逻辑。一般情况下,EasyMock与JUnit或TestNG配合使用。

官网介绍:https://easymock.org/

PowerMock

PowerMock是一种用于Java单元测试的框架,它扩展了其他mocking框架的能力,比如EasyMock和Mockito。PowerMock的主要特点是它可以mock静态方法、私有方法、final方法、构造函数,甚至系统类(如System、String等),这些通常是传统mocking框架所做不到的。有了这些功能,PowerMock在一些复杂场景下进行单元测试更加方便。虽然PowerMock提供了强大的功能,但由于它修改了类加载器和字节码操作,可能会导致一些测试方法与JVM或第三方库之间的兼容性问题。所以,在使用PowerMock时需要权衡其提供的功能和可能带来的复杂性。

ps:由于PowerMock的执行速度问题(每个测试类都需要重启spring的TestContext),我们团队内部不建议使用该框架。官网介绍:https://github.com/powermock/powermock

JMock

JMock是一种用于Java单元测试的框架,属于一种轻量级框架,该框架采用了行为驱动开发(BDD)的测试风格。用来在单元测试中mock接口或类的依赖项,对代码进行隔离测试,而无需关心整个系统的其他部分。JMock支持通过声明式的方式来指定对象间的交互行为。

官网介绍:http://jmock.org/大部分开发者在使用这些测试框架时,不会独立使用其中一种,而是会结合使用,例如,可以在JUnit或TestNG的基础上使用Mockito来创建和使用mock对象,来完成比较复杂的测试任务。每个框架都有其独特的优点与缺点,选择哪个框架通常取决于个人偏好、项目需求以及现有代码库的兼容性。当然,实际开发中的单元测试框架远不止以上所提到的这些,还有一些同样优秀的框架在本文中没有介绍,例如:Selenium、Cucumber、Appium等,感兴趣的读者可以自行学习。

我们在用什么?

目前集团内主流的单元测试框架用的是Mockito框架,该框架的单元测试流程为:

以下面的代码为例,展示一下单元测试的常用写法: @Autowired private BenefitRecordQueryServiceI benefitRecordQueryServiceI; @Override public List<BenefitRecordExtendVO> queryBenefitRecordList(Long companyId, String scene) { Validate.not(companyId, "companyId cannot be "); Validate.notBlank(scene, "scene cannot be "); BenefitRecordQueryParam param = new BenefitRecordQueryParam(); param.setCompanyId(companyId); param.setScene(scene); MultiResponse<BenefitRecordExtendDTO> res = benefitRecordQueryServiceI .pageQueryBenefitRecordWithExtendAttrs(param); if (res == || !res.isSuccess()) { log.error("pageQueryBenefitRecordWithExtendAttrs error, companyId:{}, scene:{}, res:{}",companyId, scene, JSON.toJSONString(res)); throw new SupplierFosterException("pageQueryBenefitRecordWithExtendAttrs error"); } return DataObjectUtils.transferDeep(res.getData(), BenefitRecordExtendVO.class); }对以上代码写一段合格的单元测试是每一位程序员的基本功,无非就是@InjectMocks、@Mock、Mockito.when()、Mockito.verify()等一系列操作。当然,我们也是这样做的: @InjectMocks private BenefitAdaptorImpl benefitAdaptor; @Mock private BenefitRecordQueryServiceI benefitRecordQueryServiceI; @Test public void testQueryBenefitRecordListWhenSuccess() { Long companyId = 123L; String scene = "cnfm"; MultiResponse<BenefitRecordExtendDTO> res = new MultiResponse<>(); List<BenefitRecordExtendDTO> resList = new ArrayList<>(); BenefitRecordExtendDTO benefitRecordExtendDTO = new BenefitRecordExtendDTO(); benefitRecordExtendDTO.setBenefitCode("rfq"); resList.add(benefitRecordExtendDTO); res.setSuccess(true); res.setData(resList); Mockito.when(benefitRecordQueryServiceI.pageQueryBenefitRecordWithExtendAttrs( Mockito.any())).thenReturn(res); List<BenefitRecordExtendVO> result = benefitAdaptor.queryBenefitRecordList(companyId, scene); Assert.assertEquals(1, result.size()); BenefitRecordExtendVO benefitRecordRes = result.get(0); Assert.assertNot(benefitRecordRes); Assert.assertEquals("rfq", benefitRecordRes.getBenefitCode()); Mockito.verify(benefitRecordQueryServiceI).pageQueryBenefitRecordWithExtendAttrs( Mockito.any()); }点击,运行,没问题!ok,继续写下一段,等等~真的没问题了吗?那请尝试回答一下下面的几个问题:

@InjectMocks干了什么,mock的benefitAdaptor对象有什么特性?

@Mock干了什么,mock的benefitRecordQueryServiceI对象有什么特性?

Mockito.when().thenReturn()干了什么,如何模拟方法调用的?

Mockito.verify()干了什么,如何验证方法的调用运行?

如果你能清晰的回答以上4个问题,那么这篇文章对于你来说是一个温故的作用;如果回答不上来,那么阅读这篇文章来知新吧!

mockito怎么运行的?

@RunWith(MockitoJUnitRunner.class)@RunWith(MockitoJUnitRunner.class)是Junit中的一个注解,用来指定测试运行环境(MockitoJUnitRunner)。该注解的主要作用就是自动初始化mock对象。在Mockito 1.9.5之前,初始化mock对象需要通过手动的显示调用: @Before public void initMocks() { MockitoAnnotations.initMocks(this); }Mockito 1.9.5之后,将该初始化过程集成到MockitoJUnitRunner中,仅需要一个注解,就可以完成mock对象的注入,让我们一起看一下MockitoJUnitRunner到底是怎么执行的,以Mockito 2.23.0版本为例:

看起来MockitoAnnotations.initMocks(this)可能不是在MockitoJUnitRunner的构造函数中直接调用的。相反,MockitoJUnitRunner可能在另外一个封装层(如StrictRunner或RunnerFactory中创建的某个Runner)中处理初始化mock的逻辑:

可以看出,InternalRunner接口的实现类DefaultInternalRunner的构造函数中调用了MockitoAnnotations.initMocks(this)来初始化mock对象。这样做的好处主要有两点:1)代码更加简洁;2)在运行测试用例之前保证对象都已经mock完成。至于MockitoAnnotations.initMocks(this)是怎么mock对象的,请继续往下看。@InjectMocks@InjectMocks是Mockito测试框架提供的一个注解,会自动将mock对象注入到被测试类的实例中,来创建和初始化那些需要被注入的mock对象,被测试对象通常是要被进行单元测试的类。@InjectMocks注解如下:

根据官网对@InjectMocks的介绍,注入mock对象的方式有3种:

构造器注入:Mockito会寻找被标注类的构造器,并尝试使用可用的mock对象作为参数来实例化类。它首先尝试使用最多参数的构造器,如果失败,则尝试较少参数的构造器。

属性注入:如果构造器注入不可行或者不成功,Mockito会尝试将mock对象直接设置到被标注类的属性中,这包括私有属性。它会通过反射来忽略访问修饰符,直接向属性赋值。

方法注入:如果前两种方式都不可行,Mockito会尝试调用类中的setter方法来注入mock对象。

仅仅知道这3种注入方式,并不能帮我们深入理解Mockito到底是怎么运行的,那么该注解的执行是怎么样的呢?前文提到,Mockito在处理注解时,主要是通过MockitoAnnotations.initMocks(this)方法进入。首先,这个方法会创建一个注解引擎-AnnotationEngine:

这个引擎会对测试类进行扫描,寻找所有Mockito注解字段(包括@Mock,@Spy,@Captor和@InjectMocks),每一种注解有着相对应的处理器进行相应的处理,以InjectingAnnotationEngine为例:

通过injectMocks和injectMocksOnFields方法可以看出,Mockito是会尝试在被测试类中找到一个构造器,该构造器的参数与现有的mock对象是相匹配的,并使用这些mock对象实例化@InjectMocks注解的字段。如果没有找到相匹配的构造器,Mockito将使用属性注入的方式直接设置字段的值,或者通过setter方法进行注入。@InjectMocks注解的功能是由Mockito内部的几个类协同工作实现的,逻辑处理十分复杂,涉及到许多边界情况的处理和错误管理,例如,需要处理多个构造器、避免循环依赖、选择最佳的注入策略等。下面通过一段伪代码对上述的流程进行逻辑概括: public MockitoAnnotations { public static void initMocks(Object test) { AnnotationEngine annotationEngine = ...; annotationEngine.process(test.getClass(), test); } } public InjectMocksAnnotationEngine implements AnnotationEngine { public void process(Class<?> clazz, Object testInstance) { // 获取所有 @Mock 标注的字段 Set<Field> mockFields = ...; // 获取所有 @InjectMocks 标注的字段 Set<Field> injectMocksFields = ...; for (Field injectMocksField : injectMocksFields) { // 创建 @InjectMocks 标注字段的实例 Object fieldInstance = createInstance(injectMocksField.getType()); injectMocksField.setAccessible(true); // 将实例设置到测试类的字段中 injectMocksField.set(testInstance, fieldInstance); PropertySetterInjector propertySetterInjector = new PropertySetterInjector(mockFields); ConstructorInjector constructorInjector = new ConstructorInjector(mockFields); if (!constructorInjector.tryConstructorInjection(fieldInstance, injectMocksField)) { propertySetterInjector.tryPropertyOrSetterInjection(fieldInstance, injectMocksField); } } } } public ConstructorInjector { public boolean tryConstructorInjection(Object fieldInstance, Field injectMocksField) { // 使用反射尝试通过构造器注入 mock 对象 } } public PropertySetterInjector { public void tryPropertyOrSetterInjection(Object fieldInstance, Field injectMocksField) { // 使用反射尝试通过属性或setter方法注入 mock 对象 } }对于该注解的执行逻辑,可以总结为以下4步:1.注解处理器的初始化:首先调用MockitoAnnotations.initMocks(this),或者使用MockitoJUnitRunner或JUnit的MockitoExtension。这些方法会扫描测试类,查找所有由Mockito提供的注解(如@Mock,@Spy,@Captor,@InjectMocks)并进行处理。2.mock对象的创建:对于每个使用@Mock注解的字段,Mockito会创建一个相应的mock对象。这是通过调用Mockito.mock()方法完成的(下文会讲怎么mock的),该方法使用动态代理或字节码操作来生成mock对象。3.查找注入点:对于每个使用@InjectMocks注解的字段,Mockito会寻找变量注入的点。首先,Mockito会选择参数最多的、参数完全匹配的构造器注入mock对象。如果没有合适的构造器,它会尝试属性注入,最后考虑setter方法。4.注入过程:一旦找到注入点(构造器、属性或setter方法),Mockito使用反射API来完成注入过程。对于构造器,它会使用找到的mock对象实例化新对象。对于属性或setter方法,它会直接注入mock对象。通过以上的步骤注入的mock对象,和Spring加载的对象有着明显的区别:

使用目的

@InjectMocks主要用于单元测试,注入的是mock对象,用来模拟真实对象的行为。

Spring的依赖注入用于实际的应用运行中,注入的是真实的、由Spring容器创建和管理的bean对象。

运行环境

@InjectMocks在测试环境中使用,不依赖Spring容器。

Spring依赖注入是在应用的生产环境中使用,依赖于Spring容器的生命周期和管理。

对象类型

使用@InjectMocks注入的对象是一个用于模拟的代理对象。

Spring中注入的对象是完全功能的实例。

生命周期

Mockito不负责mock对象的生命周期管理,一旦测试用例运行完毕,mock对象就会被丢弃。

Spring容器负责bean的整个生命周期,包括创建、初始化、注入、销毁等。

对象创建

@Mockito通过动态代理的方式创建mock对象。

Spring通过实例化类定义来创建bean。

@Mock@Mock注解用于注入测试对象,该测试对象通常是被测试对象的依赖或者外部组件,主要用来标记需要模拟的类或者接口。注入之后,可以在测试中模拟该对象的行为和返回值,而忽略该对象中的依赖和外部组件的行为。@Mock注解如下:

1.answer:此属性表示为mock对象指定一个默认的行为,这个行为将应用于所有未打桩的方法调用。它会接受一个Answers枚举类型的值。例如,Answers.RETURNS_DEFAULTS会使未配置打桩的方法返回对应类型的默认值(0、false、等)。其他如Answers.RETURNS_SMART_S可以返回智能空值,这些空值在使用时会抛出异常,并在异常信息中打印出哪个未打桩的方法被调用了。2.stubOnly:表示是否创建一个仅用于打桩的mock对象,如果设置为true,创建的mock对象不会记录任何方法调用,也就不能用于验证方法是否被调用。3.name:对mock对象的命名。命名mock对象有助于错误调试,当验证失败时,异常信息中会包含这个名称。4.extraInterfaces:可以为mock对象实现一些其他接口。5.serializable:表示需要mock对象是否应该是可序列化的,如果设置为true,生成的mock对象将会实现Serializable接口。这样的话,注入的mock对象可以在需要序列化和反序列化的测试场景中使用。@Mock注解的逻辑入口和@InjectMocks一致,都是从MockitoAnnotations.initMocks(this)开始执行,同样创建一个AnnotationEngine引擎:

根据该引擎的执行可以看出,首先通过反射获取测试类中所有字段,检查带有@Mock注解的字段,并为这些字段创建mock对象并设置到相应的字段上:

会根据不同的注解找到不同的处理器进行mock对象的处理:

读取注解的中配置的属性并将其转换为Mockito的MockSettings对象,调用Mockito.mock()方法并传入字段的类型和设置,以便创建具有所需特性的mock对象:

真正创建mock对象的代码如下:

分析上面的代码,发现一共做了以下几件事:1.调用createMockType方法,该方法基于提供的MockCreationSettings生成mock对象的类型;2.从Plugins中获取InstantiatorProvider的实例,然后调用getInstantiator方法获取Instantiator。Instantiator是负责创建mock对象的组件;3.使用Instantiator的newInstance方法创建第一步生成的类型的新对象;4.创建MockMethodInterceptor拦截器对象,主要拦截对mock对象所进行的调用,并根据settings里的设置执行相应的逻辑;5.检查mock对象是否实现了MockAccess接口。如果实现了,将mockMethodInterceptor设置为其拦截器;6.返回创建的mock对象。至此,通过@Mock自动注入mock对象的主要过程就结束了,主要包括mock对象类型的确定、实例的创建、拦截器的设置以及异常的处理。可以看出,逻辑还是非常复杂的。下面通过一段伪代码对上述的流程进行逻辑概括: // MockitoAnnotations.initMocks方法的简化伪代码 public static void initMocks(Object testClassInstance) { Class<?> testClass = testClassInstance.getClass(); Field[] fields = testClass.getDeclaredFields(); for (Field field : fields) { if (field.isAnnotationPresent(Mock.class)) { Mock mock = field.getAnnotation(Mock.class); Object mockObject = createMockObject(field.getType(), mock); field.setAccessible(true); field.set(testClassInstance, mockObject); } } } private static Object createMockObject(Class<?> fieldType, Mock mockAnnotation) { // 创建mock配置 MockSettings mockSettings = configureMockSettings(mockAnnotation); // 使用Mockito API创建mock对象 return Mockito.mock(fieldType, mockSettings); } private static MockSettings configureMockSettings(Mock mockAnnotation) { // 根据@Mock注解的属性配置MockSettings MockSettings mockSettings = Mockito.withSettings(); if (!"".equals(mockAnnotation.name())) { mockSettings.name(mockAnnotation.name()); } if (mockAnnotation.stubOnly()) { mockSettings.stubOnly(); } // 其他配置参数 mockSettings.defaultAnswer(mockAnnotation.answer()); return mockSettings; } // Mockito.mock方法的简化伪代码 public static <T> T mock(Class<T>ToMock, MockSettings mockSettings) { // 检查是否可以被mock if (isNotMockable(classToMock)) { throw new MockitoException("Cannot mock/spy: " +ToMock.getName()); } // 创建mock设置,如果未提供则使用默认设置 if (mockSettings == ) { mockSettings = withSettings(); // 创建mock对象 T mockInstance = createMockInstance(classToMock, mockSetting // 返回mock对象 return mockInstance; } private static <T> T createMockInstance(Class<T>ToMock, MockSettings mockSettings) { // 根据mock设置创建一个MockCreationSettings对象 MockCreationSettings<T> settings = new MockCreationSettings<>(classToMock, mockSetting // 获取MockMaker插件,它负责创建mock实例 MockMaker mockMaker = Plugins.getMockMaker // 使用MockMaker创建mock实例 T mock = mockMaker.createMock(settings, new MockHandlerImpl<T>(settings // 返回创建的mock实例 return mock; }对于该注解的执行原理,可以总结为以下4步:1.注解处理器的初始化:首先调用MockitoAnnotations.initMocks(this),或者使用MockitoJUnitRunner或JUnit的MockitoExtension。这些方法会扫描测试类,查找@Mock注解标记的属性。2.配置注解属性:根据注解参数创建MockCreationSettings对象,它包含了创建mock对象所需的所有设置。3.Mock对象的创建:使用Mockito内部的MockMaker实例和前面步骤中创建的MockCreationSettings,生成mock对象。4.方法Mock对象到字段:通过反射将生成的mock对象赋给测试类中的对应字段。

Mockito.when()Mockito.when()是Mockito框架中的一个核心功能,该功能用于为mock对象的方法调用指定一个预期的行为。例如:返回一个特定的值、抛出一个异常或者执行一个特定的动作。然而,Mockito.when()只用来设置打桩状态,而不会定义预期的返回值,一般结合doReturn()、doThrow()、 doAnswer()、doNothing()、doCallRealMethod()等方法一起使用来指定函数调用的预期行为。当Mockito.when()被调用时,会获取一个线程安全的MockingProgress实例来设置mock对象的打桩状态。该过程会涉及到线程局部变量的操作,以确保验证状态不会与其他线程的操作冲突。

通过pullOngoingStubbing()方法提取当前正在进行的打桩对象:

首先会获取当前的OngoingStubbing,该字段存储着当前线程的正在进行的打桩对象,然后清除该对象,防止未来的打桩操作错误地使用旧的打桩对象,最后返回该对象。OngoingStubbing对象并无法分析开发者设置预期行为,需要链式调用thenReturn()、thenThrow() 等方法。例如:Mockito.when().thenReturn()。下面以thenReturn()为例分析:

当OngoingStubbing对象链式调用thenReturn()之后,首先会通过new Returns(value)实例化一个返回指定值的对象并调用thenAnswer()方法:

从上面代码看,主要是将设置的预期行为添加到Mockito.when()生成的OngoingStubbing对象中,可以分为以下流程:1.获取打桩实例:从invocationForStubbing中获取代表打桩调用的Invocation对象。2.打桩完成通知:MockingProgress对象打桩过程已经完成,这一步可能会更新其内部状态。3.回答验证:如果Answer实例实现了ValidableAnswer接口,那么对第一步获取的Invocation对象进行验证。4.同步打桩列表:在synchronized代码块中,同步打桩列表stubbed。5.添加或更新打桩列表:如果打桩对象设置为连续调用,将Answer对象设置到打桩列表的首位。否则,将创建一个新的StubbedInvocationMatcher实例并设置到打桩列表首位。6.返回打桩匹配器:返回打桩列表中第一个元素,并强转为匹配器类型。由于打桩操作通常遵循“LIFO”规则,所以最后一个设置的Answer是最新被调用的,也就是说,后续的打桩配置会覆盖之前的打桩配置。

Mockito.verify()Mockito.verify()方法是Mockito框架中的一个核心功能,该功能用于验证一个mock对象的某个方法是否被调用,以及调用的次数和参数是否一致。当Mockito.verify()被调用时,大致的运行流程如下:

verify()方法会创建一个新的VerificationMode实例,通常是调用1次的验证模式。所以,当验证函数只调用1次的情况下在verify函数中可以省略times的参数。

分析上面的代码,发现一共做了以下几件事:1.mock对象检查:通过mockingDetails(mock)检查传入的对象是否真的是一个mock对象。2.参数验证:确认mock对象是否仅用于打桩,而非验证。如果是一个仅用于打桩的mock对象,那么就不能对其进行验证。3.通知验证开始:如果验证过程涉及监听器,调用VerificationStartedNotifier.notifyVerificationStarted()方法来通知所有的验证开始监听器。4.获取MockingProgress:获取当前线程的MockingProgress实例来记录验证状态,这会涉及到线程局部变量的操作,以确保验证状态不会与其他线程的操作冲突。5.延迟验证:使用maybeVerifyLazily()方法,该方法可能会修改传入的VerificationMode来延迟验证,当某个特定的方法调用时再进行验证。6.开始验证:创建一个MockAwareVerificationMode实例并将其设置到MockingProgress中。这个实例包含mock对象、实际的验证模式和验证监听器。7.结束验证:返回mock对象。在verify()的实际调用中,还包含了对InOrder验证、验证超时等高级特性的支持,以及对异常处理和各种边界情况的处理,本文仅提供了一个验证流程上的分析。下面通过一段伪代码对上述的流程进行逻辑概括: public Mockito { public static <T> T verify(T mock) { return verify(mock, times(1)); } public static <T> T verify(T mock, VerificationMode mode) { MockingProgress progress = MockingProgressImpl.threadSafeMockingProgress(); progress.verificationStarted(mode); return mock; } } public MockHandlerImpl<T> implements MockHandler<T> { public Object handle(Invocation invocation) throws Throwable { MockingProgress progress = MockingProgressImpl.threadSafeMockingProgress(); VerificationMode verificationMode = progress.pullVerificationMode(); if (verificationMode != ) { // 验证调用 verificationMode.verify(invocation); return ; } else { // 执行实际的mock行为 return invocation.callRealMethod(); } } }

结语

本文讲述了Mockito框架运行单元测试的常用底层逻辑,对其中的一些高级特性并未深入探讨,感兴趣的小伙伴可以自行研究。单元测试是开发中一个庞大的分支,并非一篇文章能论述得清楚。当然,如果此文能引起你对单元测试底层逻辑的兴趣,那便是本文最大的价值了。

本文由高可用架构转载。技术原创及架构实践文章,欢迎通过公众号菜单「联系我们」进行投稿

0 阅读:0

架构互联高可用

简介:感谢大家的关注