kl博主

kl博主 查看完整档案

上海编辑  |  填写毕业院校凯京集团  |  架构组经理 编辑 www.kailing.pub/ 编辑
编辑

个人动态

kl博主 发布了文章 · 2020-12-23

解决apollo的configService服务启动异常

前言

apollo是一个非常流行的开源的配置中心项目,这里就不多介绍了。接触过apollo和运行过apollo的人肯定都遇到过启动configService时抛异常了,而且100%会抛一个异常。原因是,在apollo的架构中configService既作为config服务,同时也承载了metaService的功能,所以这个模块,既作为eureka的服务端也是eureka的客户端,这就造成了应用启动时,eurekaServer未完全启动,eurekaClient拉取注册表信息时就抛异常了。不过这个拉取动作是在独立的线程中运行的,独立于启动应用的主线程,所以异常并不影响应用的启动,这个问题也就一直从开源到留到了现在。目前,这个问题已被博主解决,正在合并pr中。

本文pr地址:https://github.com/ctripcorp/...

触发原因分析

首先看下异常的信息,异常的信息比较多,如下:

2020-12-23 09:55:19.882 ERROR 7022 --- [           main] c.n.d.s.t.d.RedirectingEurekaHttpClient  : Request execution error

com.sun.jersey.api.client.ClientHandlerException: java.net.ConnectException: Connection refused (Connection refused)
    at com.sun.jersey.client.apache4.ApacheHttpClient4Handler.handle(ApacheHttpClient4Handler.java:187)
    at com.sun.jersey.api.client.filter.GZIPContentEncodingFilter.handle(GZIPContentEncodingFilter.java:123)
    at com.netflix.discovery.EurekaIdentityHeaderFilter.handle(EurekaIdentityHeaderFilter.java:27)
    at com.sun.jersey.api.client.Client.handle(Client.java:652)
    at com.sun.jersey.api.client.WebResource.handle(WebResource.java:682)
    at com.sun.jersey.api.client.WebResource.access$200(WebResource.java:74)
    at com.sun.jersey.api.client.WebResource$Builder.get(WebResource.java:509)
    at com.netflix.discovery.shared.transport.jersey.AbstractJerseyEurekaHttpClient.getApplicationsInternal(AbstractJerseyEurekaHttpClient.java:194)
    at com.netflix.discovery.shared.transport.jersey.AbstractJerseyEurekaHttpClient.getApplications(AbstractJerseyEurekaHttpClient.java:165)
    at com.netflix.discovery.shared.transport.decorator.EurekaHttpClientDecorator$6.execute(EurekaHttpClientDecorator.java:137)
    at com.netflix.discovery.shared.transport.decorator.MetricsCollectingEurekaHttpClient.execute(MetricsCollectingEurekaHttpClient.java:73)
    at com.netflix.discovery.shared.transport.decorator.EurekaHttpClientDecorator.getApplications(EurekaHttpClientDecorator.java:134)
    at com.netflix.discovery.shared.transport.decorator.EurekaHttpClientDecorator$6.execute(EurekaHttpClientDecorator.java:137)
    at com.netflix.discovery.shared.transport.decorator.RedirectingEurekaHttpClient.executeOnNewServer(RedirectingEurekaHttpClient.java:118)
    at com.netflix.discovery.shared.transport.decorator.RedirectingEurekaHttpClient.execute(RedirectingEurekaHttpClient.java:79)
    at com.netflix.discovery.shared.transport.decorator.EurekaHttpClientDecorator.getApplications(EurekaHttpClientDecorator.java:134)
    at com.netflix.discovery.shared.transport.decorator.EurekaHttpClientDecorator$6.execute(EurekaHttpClientDecorator.java:137)
    at com.netflix.discovery.shared.transport.decorator.RetryableEurekaHttpClient.execute(RetryableEurekaHttpClient.java:120)
    at com.netflix.discovery.shared.transport.decorator.EurekaHttpClientDecorator.getApplications(EurekaHttpClientDecorator.java:134)
    at com.netflix.discovery.shared.transport.decorator.EurekaHttpClientDecorator$6.execute(EurekaHttpClientDecorator.java:137)
    at com.netflix.discovery.shared.transport.decorator.SessionedEurekaHttpClient.execute(SessionedEurekaHttpClient.java:77)
    at com.netflix.discovery.shared.transport.decorator.EurekaHttpClientDecorator.getApplications(EurekaHttpClientDecorator.java:134)
    at com.netflix.discovery.DiscoveryClient.getAndStoreFullRegistry(DiscoveryClient.java:1051)
    at com.netflix.discovery.DiscoveryClient.fetchRegistry(DiscoveryClient.java:965)
    at com.netflix.discovery.DiscoveryClient.<init>(DiscoveryClient.java:414)
    at com.netflix.discovery.DiscoveryClient.<init>(DiscoveryClient.java:269)
    at org.springframework.cloud.netflix.eureka.CloudEurekaClient.<init>(CloudEurekaClient.java:63)
    at org.springframework.cloud.netflix.eureka.EurekaClientAutoConfiguration$RefreshableEurekaClientConfiguration.eurekaClient(EurekaClientAutoConfiguration.java:290)
    at org.springframework.cloud.netflix.eureka.EurekaClientAutoConfiguration$RefreshableEurekaClientConfiguration$$EnhancerBySpringCGLIB$$5cf7ced9.CGLIB$eurekaClient$2(<generated>)
    at org.springframework.cloud.netflix.eureka.EurekaClientAutoConfiguration$RefreshableEurekaClientConfiguration$$EnhancerBySpringCGLIB$$5cf7ced9$$FastClassBySpringCGLIB$$328872d8.invoke(<generated>)
    at org.springframework.cglib.proxy.MethodProxy.invokeSuper(MethodProxy.java:228)
    at org.springframework.context.annotation.ConfigurationClassEnhancer$BeanMethodInterceptor.intercept(ConfigurationClassEnhancer.java:365)
    at org.springframework.cloud.netflix.eureka.EurekaClientAutoConfiguration$RefreshableEurekaClientConfiguration$$EnhancerBySpringCGLIB$$5cf7ced9.eurekaClient(<generated>)
    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
    at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
    at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
    at java.lang.reflect.Method.invoke(Method.java:498)
    at org.springframework.beans.factory.support.SimpleInstantiationStrategy.instantiate(SimpleInstantiationStrategy.java:154)
    at org.springframework.beans.factory.support.ConstructorResolver.instantiateUsingFactoryMethod(ConstructorResolver.java:582)
    at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.instantiateUsingFactoryMethod(AbstractAutowireCapableBeanFactory.java:1247)
    at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBeanInstance(AbstractAutowireCapableBeanFactory.java:1096)
    at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.doCreateBean(AbstractAutowireCapableBeanFactory.java:535)
    at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBean(AbstractAutowireCapableBeanFactory.java:495)
    at org.springframework.beans.factory.support.AbstractBeanFactory.lambda$doGetBean$1(AbstractBeanFactory.java:353)
    at org.springframework.cloud.context.scope.GenericScope$BeanLifecycleWrapper.getBean(GenericScope.java:390)
    at org.springframework.cloud.context.scope.GenericScope.get(GenericScope.java:184)
    at org.springframework.beans.factory.support.AbstractBeanFactory.doGetBean(AbstractBeanFactory.java:350)
    at org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:199)
    at org.springframework.aop.target.SimpleBeanTargetSource.getTarget(SimpleBeanTargetSource.java:35)
    at org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:193)
    at com.sun.proxy.$Proxy145.getApplications(Unknown Source)
    at org.springframework.cloud.netflix.eureka.server.EurekaServerAutoConfiguration.peerAwareInstanceRegistry(EurekaServerAutoConfiguration.java:164)
    at org.springframework.cloud.netflix.eureka.server.EurekaServerAutoConfiguration$$EnhancerBySpringCGLIB$$ef07d99b.CGLIB$peerAwareInstanceRegistry$5(<generated>)
    at org.springframework.cloud.netflix.eureka.server.EurekaServerAutoConfiguration$$EnhancerBySpringCGLIB$$ef07d99b$$FastClassBySpringCGLIB$$458f0ac6.invoke(<generated>)
    at org.springframework.cglib.proxy.MethodProxy.invokeSuper(MethodProxy.java:228)
    at org.springframework.context.annotation.ConfigurationClassEnhancer$BeanMethodInterceptor.intercept(ConfigurationClassEnhancer.java:365)
    at org.springframework.cloud.netflix.eureka.server.EurekaServerAutoConfiguration$$EnhancerBySpringCGLIB$$ef07d99b.peerAwareInstanceRegistry(<generated>)
    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
    at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
    at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
    at java.lang.reflect.Method.invoke(Method.java:498)
    at org.springframework.beans.factory.support.SimpleInstantiationStrategy.instantiate(SimpleInstantiationStrategy.java:154)
    at org.springframework.beans.factory.support.ConstructorResolver.instantiateUsingFactoryMethod(ConstructorResolver.java:582)
    at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.instantiateUsingFactoryMethod(AbstractAutowireCapableBeanFactory.java:1247)
    at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBeanInstance(AbstractAutowireCapableBeanFactory.java:1096)
    at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.doCreateBean(AbstractAutowireCapableBeanFactory.java:535)
    at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBean(AbstractAutowireCapableBeanFactory.java:495)
    at org.springframework.beans.factory.support.AbstractBeanFactory.lambda$doGetBean$0(AbstractBeanFactory.java:317)
    at org.springframework.beans.factory.support.DefaultSingletonBeanRegistry.getSingleton(DefaultSingletonBeanRegistry.java:222)
    at org.springframework.beans.factory.support.AbstractBeanFactory.doGetBean(AbstractBeanFactory.java:315)
    at org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:199)
    at org.springframework.beans.factory.config.DependencyDescriptor.resolveCandidate(DependencyDescriptor.java:251)
    at org.springframework.beans.factory.support.DefaultListableBeanFactory.doResolveDependency(DefaultListableBeanFactory.java:1135)
    at org.springframework.beans.factory.support.DefaultListableBeanFactory.resolveDependency(DefaultListableBeanFactory.java:1062)
    at org.springframework.beans.factory.support.ConstructorResolver.resolveAutowiredArgument(ConstructorResolver.java:818)
    at org.springframework.beans.factory.support.ConstructorResolver.createArgumentArray(ConstructorResolver.java:724)
    at org.springframework.beans.factory.support.ConstructorResolver.instantiateUsingFactoryMethod(ConstructorResolver.java:474)
    at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.instantiateUsingFactoryMethod(AbstractAutowireCapableBeanFactory.java:1247)
    at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBeanInstance(AbstractAutowireCapableBeanFactory.java:1096)
    at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.doCreateBean(AbstractAutowireCapableBeanFactory.java:535)
    at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBean(AbstractAutowireCapableBeanFactory.java:495)
    at org.springframework.beans.factory.support.AbstractBeanFactory.lambda$doGetBean$0(AbstractBeanFactory.java:317)
    at org.springframework.beans.factory.support.DefaultSingletonBeanRegistry.getSingleton(DefaultSingletonBeanRegistry.java:222)
    at org.springframework.beans.factory.support.AbstractBeanFactory.doGetBean(AbstractBeanFactory.java:315)
    at org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:199)
    at org.springframework.beans.factory.config.DependencyDescriptor.resolveCandidate(DependencyDescriptor.java:251)
    at org.springframework.beans.factory.support.DefaultListableBeanFactory.doResolveDependency(DefaultListableBeanFactory.java:1135)
    at org.springframework.beans.factory.support.DefaultListableBeanFactory.resolveDependency(DefaultListableBeanFactory.java:1062)
    at org.springframework.beans.factory.annotation.AutowiredAnnotationBeanPostProcessor$AutowiredFieldElement.inject(AutowiredAnnotationBeanPostProcessor.java:583)
    at org.springframework.beans.factory.annotation.InjectionMetadata.inject(InjectionMetadata.java:90)
    at org.springframework.beans.factory.annotation.AutowiredAnnotationBeanPostProcessor.postProcessPropertyValues(AutowiredAnnotationBeanPostProcessor.java:372)
    at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.populateBean(AbstractAutowireCapableBeanFactory.java:1341)
    at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.doCreateBean(AbstractAutowireCapableBeanFactory.java:572)
    at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBean(AbstractAutowireCapableBeanFactory.java:495)
    at org.springframework.beans.factory.support.AbstractBeanFactory.lambda$doGetBean$0(AbstractBeanFactory.java:317)
    at org.springframework.beans.factory.support.DefaultSingletonBeanRegistry.getSingleton(DefaultSingletonBeanRegistry.java:222)
    at org.springframework.beans.factory.support.AbstractBeanFactory.doGetBean(AbstractBeanFactory.java:315)
    at org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:199)
    at org.springframework.beans.factory.support.DefaultListableBeanFactory.preInstantiateSingletons(DefaultListableBeanFactory.java:759)
    at org.springframework.context.support.AbstractApplicationContext.finishBeanFactoryInitialization(AbstractApplicationContext.java:869)
    at org.springframework.context.support.AbstractApplicationContext.refresh(AbstractApplicationContext.java:550)
    at org.springframework.boot.web.servlet.context.ServletWebServerApplicationContext.refresh(ServletWebServerApplicationContext.java:140)
    at org.springframework.boot.SpringApplication.refresh(SpringApplication.java:780)
    at org.springframework.boot.SpringApplication.refreshContext(SpringApplication.java:412)
    at org.springframework.boot.SpringApplication.run(SpringApplication.java:333)
    at org.springframework.boot.SpringApplication.run(SpringApplication.java:1277)
    at org.springframework.boot.SpringApplication.run(SpringApplication.java:1265)
    at com.ctrip.framework.apollo.configservice.ConfigServiceApplication.main(ConfigServiceApplication.java:33)
Caused by: java.net.ConnectException: Connection refused (Connection refused)
    at java.net.PlainSocketImpl.socketConnect(Native Method)
    at java.net.AbstractPlainSocketImpl.doConnect(AbstractPlainSocketImpl.java:476)
    at java.net.AbstractPlainSocketImpl.connectToAddress(AbstractPlainSocketImpl.java:218)
    at java.net.AbstractPlainSocketImpl.connect(AbstractPlainSocketImpl.java:200)
    at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:394)
    at java.net.Socket.connect(Socket.java:606)
    at org.apache.http.conn.scheme.PlainSocketFactory.connectSocket(PlainSocketFactory.java:121)
    at org.apache.http.impl.conn.DefaultClientConnectionOperator.openConnection(DefaultClientConnectionOperator.java:180)
    at org.apache.http.impl.conn.AbstractPoolEntry.open(AbstractPoolEntry.java:144)
    at org.apache.http.impl.conn.AbstractPooledConnAdapter.open(AbstractPooledConnAdapter.java:134)
    at org.apache.http.impl.client.DefaultRequestDirector.tryConnect(DefaultRequestDirector.java:610)
    at org.apache.http.impl.client.DefaultRequestDirector.execute(DefaultRequestDirector.java:445)
    at org.apache.http.impl.client.AbstractHttpClient.doExecute(AbstractHttpClient.java:835)
    at org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:118)
    at org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:56)
    at com.sun.jersey.client.apache4.ApacheHttpClient4Handler.handle(ApacheHttpClient4Handler.java:173)
    ... 107 common frames omitted

2020-12-23 09:55:19.883  WARN 7022 --- [           main] c.n.d.s.t.d.RetryableEurekaHttpClient    : Request execution failed with message: java.net.ConnectException: Connection refused (Connection refused)
2020-12-23 09:55:19.883 ERROR 7022 --- [           main] com.netflix.discovery.DiscoveryClient    : DiscoveryClient_APOLLO-CONFIGSERVICE/172.26.203.178:apollo-configservice:8080 - was unable to refresh its cache! status = Cannot execute request on any known server

com.netflix.discovery.shared.transport.TransportException: Cannot execute request on any known server
    at com.netflix.discovery.shared.transport.decorator.RetryableEurekaHttpClient.execute(RetryableEurekaHttpClient.java:112)
    at com.netflix.discovery.shared.transport.decorator.EurekaHttpClientDecorator.getApplications(EurekaHttpClientDecorator.java:134)
    at com.netflix.discovery.shared.transport.decorator.EurekaHttpClientDecorator$6.execute(EurekaHttpClientDecorator.java:137)
    at com.netflix.discovery.shared.transport.decorator.SessionedEurekaHttpClient.execute(SessionedEurekaHttpClient.java:77)
    at com.netflix.discovery.shared.transport.decorator.EurekaHttpClientDecorator.getApplications(EurekaHttpClientDecorator.java:134)
    at com.netflix.discovery.DiscoveryClient.getAndStoreFullRegistry(DiscoveryClient.java:1051)
    at com.netflix.discovery.DiscoveryClient.fetchRegistry(DiscoveryClient.java:965)
    at com.netflix.discovery.DiscoveryClient.<init>(DiscoveryClient.java:414)
    at com.netflix.discovery.DiscoveryClient.<init>(DiscoveryClient.java:269)
    at org.springframework.cloud.netflix.eureka.CloudEurekaClient.<init>(CloudEurekaClient.java:63)
    at org.springframework.cloud.netflix.eureka.EurekaClientAutoConfiguration$RefreshableEurekaClientConfiguration.eurekaClient(EurekaClientAutoConfiguration.java:290)
    at org.springframework.cloud.netflix.eureka.EurekaClientAutoConfiguration$RefreshableEurekaClientConfiguration$$EnhancerBySpringCGLIB$$5cf7ced9.CGLIB$eurekaClient$2(<generated>)
    at org.springframework.cloud.netflix.eureka.EurekaClientAutoConfiguration$RefreshableEurekaClientConfiguration$$EnhancerBySpringCGLIB$$5cf7ced9$$FastClassBySpringCGLIB$$328872d8.invoke(<generated>)
    at org.springframework.cglib.proxy.MethodProxy.invokeSuper(MethodProxy.java:228)
    at org.springframework.context.annotation.ConfigurationClassEnhancer$BeanMethodInterceptor.intercept(ConfigurationClassEnhancer.java:365)
    at org.springframework.cloud.netflix.eureka.EurekaClientAutoConfiguration$RefreshableEurekaClientConfiguration$$EnhancerBySpringCGLIB$$5cf7ced9.eurekaClient(<generated>)
    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
    at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
    at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
    at java.lang.reflect.Method.invoke(Method.java:498)
    at org.springframework.beans.factory.support.SimpleInstantiationStrategy.instantiate(SimpleInstantiationStrategy.java:154)
    at org.springframework.beans.factory.support.ConstructorResolver.instantiateUsingFactoryMethod(ConstructorResolver.java:582)
    at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.instantiateUsingFactoryMethod(AbstractAutowireCapableBeanFactory.java:1247)
    at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBeanInstance(AbstractAutowireCapableBeanFactory.java:1096)
    at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.doCreateBean(AbstractAutowireCapableBeanFactory.java:535)
    at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBean(AbstractAutowireCapableBeanFactory.java:495)
    at org.springframework.beans.factory.support.AbstractBeanFactory.lambda$doGetBean$1(AbstractBeanFactory.java:353)
    at org.springframework.cloud.context.scope.GenericScope$BeanLifecycleWrapper.getBean(GenericScope.java:390)
    at org.springframework.cloud.context.scope.GenericScope.get(GenericScope.java:184)
    at org.springframework.beans.factory.support.AbstractBeanFactory.doGetBean(AbstractBeanFactory.java:350)
    at org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:199)
    at org.springframework.aop.target.SimpleBeanTargetSource.getTarget(SimpleBeanTargetSource.java:35)
    at org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:193)
    at com.sun.proxy.$Proxy145.getApplications(Unknown Source)
    at org.springframework.cloud.netflix.eureka.server.EurekaServerAutoConfiguration.peerAwareInstanceRegistry(EurekaServerAutoConfiguration.java:164)
    at org.springframework.cloud.netflix.eureka.server.EurekaServerAutoConfiguration$$EnhancerBySpringCGLIB$$ef07d99b.CGLIB$peerAwareInstanceRegistry$5(<generated>)
    at org.springframework.cloud.netflix.eureka.server.EurekaServerAutoConfiguration$$EnhancerBySpringCGLIB$$ef07d99b$$FastClassBySpringCGLIB$$458f0ac6.invoke(<generated>)
    at org.springframework.cglib.proxy.MethodProxy.invokeSuper(MethodProxy.java:228)
    at org.springframework.context.annotation.ConfigurationClassEnhancer$BeanMethodInterceptor.intercept(ConfigurationClassEnhancer.java:365)
    at org.springframework.cloud.netflix.eureka.server.EurekaServerAutoConfiguration$$EnhancerBySpringCGLIB$$ef07d99b.peerAwareInstanceRegistry(<generated>)
    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
    at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
    at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
    at java.lang.reflect.Method.invoke(Method.java:498)
    at org.springframework.beans.factory.support.SimpleInstantiationStrategy.instantiate(SimpleInstantiationStrategy.java:154)
    at org.springframework.beans.factory.support.ConstructorResolver.instantiateUsingFactoryMethod(ConstructorResolver.java:582)
    at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.instantiateUsingFactoryMethod(AbstractAutowireCapableBeanFactory.java:1247)
    at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBeanInstance(AbstractAutowireCapableBeanFactory.java:1096)
    at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.doCreateBean(AbstractAutowireCapableBeanFactory.java:535)
    at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBean(AbstractAutowireCapableBeanFactory.java:495)
    at org.springframework.beans.factory.support.AbstractBeanFactory.lambda$doGetBean$0(AbstractBeanFactory.java:317)
    at org.springframework.beans.factory.support.DefaultSingletonBeanRegistry.getSingleton(DefaultSingletonBeanRegistry.java:222)
    at org.springframework.beans.factory.support.AbstractBeanFactory.doGetBean(AbstractBeanFactory.java:315)
    at org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:199)
    at org.springframework.beans.factory.config.DependencyDescriptor.resolveCandidate(DependencyDescriptor.java:251)
    at org.springframework.beans.factory.support.DefaultListableBeanFactory.doResolveDependency(DefaultListableBeanFactory.java:1135)
    at org.springframework.beans.factory.support.DefaultListableBeanFactory.resolveDependency(DefaultListableBeanFactory.java:1062)
    at org.springframework.beans.factory.support.ConstructorResolver.resolveAutowiredArgument(ConstructorResolver.java:818)
    at org.springframework.beans.factory.support.ConstructorResolver.createArgumentArray(ConstructorResolver.java:724)
    at org.springframework.beans.factory.support.ConstructorResolver.instantiateUsingFactoryMethod(ConstructorResolver.java:474)
    at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.instantiateUsingFactoryMethod(AbstractAutowireCapableBeanFactory.java:1247)
    at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBeanInstance(AbstractAutowireCapableBeanFactory.java:1096)
    at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.doCreateBean(AbstractAutowireCapableBeanFactory.java:535)
    at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBean(AbstractAutowireCapableBeanFactory.java:495)
    at org.springframework.beans.factory.support.AbstractBeanFactory.lambda$doGetBean$0(AbstractBeanFactory.java:317)
    at org.springframework.beans.factory.support.DefaultSingletonBeanRegistry.getSingleton(DefaultSingletonBeanRegistry.java:222)
    at org.springframework.beans.factory.support.AbstractBeanFactory.doGetBean(AbstractBeanFactory.java:315)
    at org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:199)
    at org.springframework.beans.factory.config.DependencyDescriptor.resolveCandidate(DependencyDescriptor.java:251)
    at org.springframework.beans.factory.support.DefaultListableBeanFactory.doResolveDependency(DefaultListableBeanFactory.java:1135)
    at org.springframework.beans.factory.support.DefaultListableBeanFactory.resolveDependency(DefaultListableBeanFactory.java:1062)
    at org.springframework.beans.factory.annotation.AutowiredAnnotationBeanPostProcessor$AutowiredFieldElement.inject(AutowiredAnnotationBeanPostProcessor.java:583)
    at org.springframework.beans.factory.annotation.InjectionMetadata.inject(InjectionMetadata.java:90)
    at org.springframework.beans.factory.annotation.AutowiredAnnotationBeanPostProcessor.postProcessPropertyValues(AutowiredAnnotationBeanPostProcessor.java:372)
    at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.populateBean(AbstractAutowireCapableBeanFactory.java:1341)
    at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.doCreateBean(AbstractAutowireCapableBeanFactory.java:572)
    at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBean(AbstractAutowireCapableBeanFactory.java:495)
    at org.springframework.beans.factory.support.AbstractBeanFactory.lambda$doGetBean$0(AbstractBeanFactory.java:317)
    at org.springframework.beans.factory.support.DefaultSingletonBeanRegistry.getSingleton(DefaultSingletonBeanRegistry.java:222)
    at org.springframework.beans.factory.support.AbstractBeanFactory.doGetBean(AbstractBeanFactory.java:315)
    at org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:199)
    at org.springframework.beans.factory.support.DefaultListableBeanFactory.preInstantiateSingletons(DefaultListableBeanFactory.java:759)
    at org.springframework.context.support.AbstractApplicationContext.finishBeanFactoryInitialization(AbstractApplicationContext.java:869)
    at org.springframework.context.support.AbstractApplicationContext.refresh(AbstractApplicationContext.java:550)
    at org.springframework.boot.web.servlet.context.ServletWebServerApplicationContext.refresh(ServletWebServerApplicationContext.java:140)
    at org.springframework.boot.SpringApplication.refresh(SpringApplication.java:780)
    at org.springframework.boot.SpringApplication.refreshContext(SpringApplication.java:412)
    at org.springframework.boot.SpringApplication.run(SpringApplication.java:333)
    at org.springframework.boot.SpringApplication.run(SpringApplication.java:1277)
    at org.springframework.boot.SpringApplication.run(SpringApplication.java:1265)
    at com.ctrip.framework.apollo.configservice.ConfigServiceApplication.main(ConfigServiceApplication.java:33)

最终我们就定位到这一行,定位问题的过程是一个非常复杂的事情。所以这里直接写明,并不是一开始我就知道关键点在这里,这个需要平时多积累知识面,才能快速定位关键点

at com.netflix.discovery.DiscoveryClient.<init>(DiscoveryClient.java:414)。
代码逻辑如下:
if (clientConfig.shouldFetchRegistry() && !fetchRegistry(false)) {
    fetchRegistryFromBackup();
}

上面的异常就是这个地方触发的,在初始化eurekaClient时,会通过判断fetchRegistry来触发拉取eurekaServer端的注册表信息,但是这个时候eurekaServer还没准备好,所以抛了如上的异常。fetchRegistry对应了Spring 初始化eurekaClient的一个配置,如:

//是否拉取注册表信息,如果配置为false,则代表只注册,通过eurekaClient获取不到任何实例
eureka.client.fetch-registry=true

eurekaClient的构造

了解了异常触发的原因和触发的节点后,在来详细了解下eurekaClient在spring下是如何被加载的。直接定位到EurekaClientAutoConfiguration.java文件,找到如下的代码:

@Bean(destroyMethod = "shutdown")
@ConditionalOnMissingBean(value = EurekaClient.class, search = SearchStrategy.CURRENT)
@org.springframework.cloud.context.config.annotation.RefreshScope
@Lazy
public EurekaClient eurekaClient(ApplicationInfoManager manager, EurekaClientConfig config, EurekaInstanceConfig instance) {
   manager.getInfo(); // force initialization
 return new CloudEurekaClient(manager, config, this.optionalArgs,
 this.context);
}

可以看到EurekaClientConfig是从上下文中注入到这个方法的,而且这个方法贴上了@RefreshScope的标记,代表这个实例可以被动态的刷新,有了这两个特性,我们的解决方案就基本出炉了。通过程序动态控制eurekaClient的fetchRegistry加载时机也就变得可行了。

实施解决方案

最终的解决方案分成了两个关键步骤,如下:

  • 1、configService启动前,设置fetchRegistry为false。
  • 2、监听EurekaClient的注册事件,判断是否注册成功,注册成功则重新设置fetchRegistry为true,刷新eurekaClient上下文

针对步骤一,直接修改configService模块的bootstrap.yml配置文件,新增fetchRegistry为false的配置,如:

eureka:
  instance:
    hostname: ${hostname:localhost}
    preferIpAddress: true
 status-page-url-path: /info
    health-check-url-path: /health
  server:
    peerEurekaNodesUpdateIntervalMs: 60000
 enableSelfPreservation: false
 client:
    serviceUrl:
      # This setting will be overridden by eureka.service.url setting from ApolloConfigDB.ServerConfig or System Property
 # see com.ctrip.framework.apollo.biz.eureka.ApolloEurekaClientConfig defaultZone: http://${eureka.instance.hostname}:8080/eureka/
    healthcheck:
      enabled: true
    eurekaServiceUrlPollIntervalSeconds: 60
 fetch-registry: false
management:
  health:
    status:
      order: DOWN, OUT_OF_SERVICE, UNKNOWN, UP

针对步骤二,新增了一个eurekaClient的配置类,如:

/**
 * @author : kl
 * After startup, set FetchRegistry to true, refresh eureka client
 **/
@Configuration
@ConditionalOnProperty(value = "eureka.client.enabled", havingValue = "true", matchIfMissing = true)
public class ConfigServerEurekaClientConfigure {

    private static final String EUREKACLIENT_BEANNAME = "eurekaClient";
    private final ApolloEurekaClientConfig eurekaClientConfig;
    private final AtomicBoolean isRefresh = new AtomicBoolean(false);
    private final RefreshScope refreshScope;

    public ConfigServerEurekaClientConfigure(ApolloEurekaClientConfig eurekaClientConfig, RefreshScope refreshScope) {
        this.eurekaClientConfig = eurekaClientConfig;
        this.refreshScope = refreshScope;
    }

    @EventListener
    public void listenEurekaInstanceRegisteredEvent(EurekaInstanceRegisteredEvent event) {
        InstanceInfo.InstanceStatus status = event.getInstanceInfo().getStatus();
        if (InstanceInfo.InstanceStatus.UP.equals(status) && !eurekaClientConfig.isFetchRegistry()) {
            this.refreshEurekaClient();
        }
    }

    private void refreshEurekaClient() {
        if (isRefresh.compareAndSet(false, true)) {
            eurekaClientConfig.setFetchRegistry(true);
            refreshScope.refresh(EUREKACLIENT_BEANNAME);
        }
    }
}

结语

经过改造后,存在了这么久的异常终于消失了。整个过程还是有一些曲折的,最初曾尝试过,自定义EurekaClient的初始化,妄想try住整个的实例化过程,接住异常自行处理,但是忽略了fetchRegistry的过程是在一个新的线程里了。其次,最初的时候以为将fetchRegistry设置为false就ok了,然后在metaService服务获取configService时候啥也获取不到,才明白了fetchRegistry的真正意图。还尝试过将刷新EurekaClient的逻辑放在ApplicationRunner的run方法内,这个造成了结果时好时坏。最终随着对Eureka的深入,才采用了现在的方案,目前的方案还算完美。最后,希望得到大家的测验反馈,早点合并到主干道,解决这个烦人的问题。

查看原文

赞 0 收藏 0 评论 0

kl博主 发布了文章 · 2020-12-10

Feign-hystrix的配置,有了Apollo,还用Archaius吗?

前言

feign是一个出色的Http请求客户端封装框架,feign-hystrix是整个框架体系里的其中一个模块,用来集成hystrix熔断器的,feign和hystrix这两个项目都是Netflix开源的(openfeign已独立迭代)。在spring boot项目中,可以使用spring-cloud-starter-openfeign模块,无缝集成feign和hystrix。但是,hystrix默认采用的Archaius来驱动hystrix的配置系统,无缝集成的同时,也会把archaius-core给引入进来。archaius是一个配置中心项目,类似spring cloud config和apollo,如果archaius只是作为hystrix配置的驱动,项目启动时会打印烦人的警告日志,提示你没有配置任何动态配置源。当项目里已经采用了apollo时,可以直接剔除掉Archaius,他们的功能定位高度重合了。直接剔除依赖,会导致原本配置在spring中的配置不生效,博主也是在不小心剔除后,遇到了配置不生效的问题,才有了本篇博文,记录下过程。只要稍加改动,结合apollo配置动态下发能力,可以做到hystrix的配置实时动态生效。

archaius警告日志

2020-12-10 11:19:41.766 WARN 12835 --- [ main] c.n.c.sources.URLConfigurationSource : No URLs will be polled as dynamic configuration sources.
2020-12-10 11:19:41.766 INFO 12835 --- [ main] c.n.c.sources.URLConfigurationSource : To enable URLs as dynamic configuration sources, define System property archaius.configurationSource.additionalUrls or make config.properties available on classpath.
2020-12-10 11:19:41.772 WARN 12835 --- [ main] c.n.c.sources.URLConfigurationSource : No URLs will be polled as dynamic configuration sources.
2020-12-10 11:19:41.772 INFO 12835 --- [ main] c.n.c.sources.URLConfigurationSource : To enable URLs as dynamic configuration sources, define System property archaius.configurationSource.additionalUrls or make config.properties available on classpath.

我们遇到的问题

在一次系统优化重构中,博主给整个项目来了一个360的大瘦身,把所有的未使用的依赖统统给挪走了。其中就包括了spring-cloud-starter-openfeign模块的archaius-core依赖。因为我们已经使用了apollo配置中心,archaius在这个项目里显得很多余,而且还会打印烦人的警告日志。所以就直接排除了,如:

implementation ('org.springframework.cloud:spring-cloud-starter-openfeign'){
    exclude(module:"archaius-core")
}

为此,专门了解了下archaius的来历,并且针对feign的熔断器的Fallback能力进行了测试,一切运行正常。上线一周后,问题暴露出来了,同事反馈,hystrix的配置好像不生效了。现象是,原本设置的hystrix线程执行不超时,却发生了很多执行一秒就超时了,我们的关键配置如下(这不是一个很好的配置示范,后面会调整更细粒度控制):

#禁止执行超时
hystrix.command.default.execution.timeout.enabled = false

直观感觉就是这个配置不生效了,联想到archaius-core被移除,所以先立马恢复了依赖,重新打包上线,问题解决。就这?为了彻底搞清楚Hystrix的配置加载过程,我们对feign整合hystrix进行了全面的了解。

hystrix在feign中的加载过程

在spring-cloud-starter-openfeign的封装下,使用起来非常简单,但是内部的加载流程非常复杂。所以博主也不打算全面铺开来说这块内容,有机会会独立一篇来说。这里根据我们上文遇到的禁用执行超时不生效的问题,博主总结了加载流程中的几个关键的地方:
Feign和Hystrix的桥接器Feign-Hystrix
image2020-12-10_13-27-43.png
这个项目是feign和hystrix的桥接器,通过这样的一个桥接器,将两个框架的api能力整合在了一起,下面简要阐述下,加载过程关键类的作用:

  • SetterFactory:承载了构造HystrixCommand实例的所有的配置的接口,有一个默认实现Default,在下面会用到,是自定义配置实现的突破口
  • HystrixInvocationHandler:这是一个实现了JDK代理接口类,用来代理Feign最终的执行,HystrixCommand类就是在这个实例里被构造执行的,使用的构造方法正是带入参Setter的构造方法,集成方会实现SetterFactory来构造Setter。调试程序时我们将端点打进这个类里,就可以看到配置加载的情况

WX20201210-135202@2x.png

spring boot自动加载hystrix

@Configuration
@ConditionalOnClass({ HystrixCommand.class, HystrixFeign.class })
protected static class HystrixFeignConfiguration {

   @Bean
   @Scope("prototype")
   @ConditionalOnMissingBean
   @ConditionalOnProperty(name = "feign.hystrix.enabled")
   public Feign.Builder feignHystrixBuilder() {
      return HystrixFeign.builder();
   }
}

这里是Hystrix在feign框架下加载的总入口。这个默认的构建器Builder中,有一个默认实现的SetterFactory,这个SetterFactory专门负责传递参数给Hystrix初始化HystrixCommand用。可以看到这里Bean的实例化加上了@ConditionalOnMissingBean条件约束,既我们可以自定义实现Hystrix的构造器,覆盖这里的实现,在自定义的构造器中,可以通过自定义实现SetterFactory,来注入任意的配置。这个是实现Hystrix配置自定义加载的方式之一,不过不推荐,没必要破坏spirng现有的这种结构,而且代码也会比较冗长(下面{...}省略了一百多行配置处理代码,用来兼容Hystrix现有配置定义),看起来如下:
image2020-12-10_13-43-29.png

Hystrix的动态兜底配置

配置是hystrix的核心,各种策略的选择执行都需要配置来驱动,所以,虽然在应用层面不需要太多的配置设置,但是必要的配置hystrix都会填充一个默认值,比如,hystrix默认执行超时设置的1s。Hystrix中的配置有三个层次的加载优先级,如:

  1. 最先加载Setter:Setter是用户传递给Hystrix构造器的,所以优先级别最高
  2. 其次加载动态配置源:如果必要的配置在Setter里没有找到,则在动态配置源中获取
  3. 最后加载默认配置:如果动态配置源中也没有找到配置,则采用默认的配置

其中动态配置源,有一个基于SystemProperties的配置实现HystrixDynamicPropertiesSystemProperties。HystrixCommand在实例化时,如果用户没有给到具体的配置,Hystrix每次都会去SystemProperties中寻找配置。也就是说,我们可以通过-D参数注入任意Hystrix的配置参数,都会生效。有了这个特性,可以非常简单的结合apollo,达到hystrix配置动态生效的效果,而且所有配置兼容Hystrix原本的配置。

apollo配置驱动Hystrix

实现这个功能的关键是。系统初始化时,将hystrix.command前缀相关的配置从apollo中获取到然后统统注入SystemProperties。配置更新时,同时更新SystemProperties中的配置即可,非常简单,用代码说话:

/**
 * @author kl (http://kailing.pub)
 * @since 2020/12/10
 */
@Slf4j
@Configuration
@AutoConfigureBefore(value = {FeignClientsConfiguration.class, FeignAutoConfiguration.class})
public class HystrixConfiguration{

    public static final String DYNAMIC_TAG = "dynamic.";
    public static final String DYNAMIC_PREFIX = DYNAMIC_TAG + "hystrix.command.";
    public static final String PREFIX = "hystrix.command.";

    @ApolloConfig
    private Config config;

    @PostConstruct
    public void initHystrix(){
        this.config.addChangeListener(
                event -> this.loadHystrixConfig(event.changedKeys()),
                null,
                Sets.newHashSet(DYNAMIC_PREFIX)
        );
        this.loadHystrixConfig(config.getPropertyNames());
    }

    private void loadHystrixConfig(Set<String> configkyes) {
        configkyes.forEach(key -> {
            if (StringUtils.containsIgnoreCase(key, PREFIX)) {
                String value = config.getProperty(key, null);
                String realKey = key.replaceAll(DYNAMIC_TAG,"").trim();
                System.setProperty(realKey, value);
                log.info("Hystrix config: {}={}", key, value);
            }
        });
    }

}

这里注意一个问题:为啥这里多设计了一个dynamic.前缀的配置,这是因为博主在测试过程中触发了apollo配置监听器隐藏的问题,导致Apollo的动态监听器不生效了。Apollo配置加载是以SystemProperties为最高优先级的,当配置发生变化时,apollo会将SystemProperties覆盖到配置之后,才比较本次配置发布是否有更新。因为我们一开始就将相关的配置加载到SystemProperties里了,所以每次变更都会被覆盖成之前的值,导致更新判断失效,一直进不了监听器。如果想要动态更新,就需要维护一份apollo的配置和SystemProperties里的映射关系,而不能保持一致,这样每次修改apollo时,就可以将维护映射关系的前缀去掉,然后将值动态更新到SystemProperties。目前的设计里,既支持原生的所有配置一次性加载,也支持dynamic.前缀拼装原有配置动态加载

配置示例
#初始化时一次性加载
hystrix.command.default.execution.timeout.enabled = true
#每次修改动态生效
dynamic.hystrix.command.default.execution.timeout.enabled = true

结语

Feign-hystrix的配置,有了Apollo,还用Archaius吗?当然不用,采用apollo实现方案,既兼容了所有原生配置,还可以做到动态生效,岂不美哉。

查看原文

赞 0 收藏 0 评论 0

kl博主 发布了文章 · 2020-12-09

Swagger异常定位纪实,是用的不对,还是Swagger本身设计问题

前言

swagger ui是一个采用注解驱动的接口文档工具,目前已支持标准的open api v3规范协议,所以不仅可以在java项目里使用,每个语言都有相应的open api实现。项目集成swagger后,可以生成导出open api v3格式化的元数据集,有了这个接口元数据,你可以在任何支持v3协议的ui上展示你的api信息。在前后端分离的项目中,swagger ui的出现,大大提高了前后端联调的效率。swagger ui在解析注解标注的元数据信息时,特别场景下会抛异常,而且抛的异常没有直观的有价值的异常信息,所以深入的debug了一番,虽然最后问题解决很简单,但是过程非常曲折。故将bug定位过程记录在此。

异常信息

image
这个异常只会在加载swagger-ui的页面时会抛出,每次刷新页面,获取一次api接口就会触发一次异常。

异常分析

@JsonProperty("x-example")
public Object getExample() {
    if (example == null) {
        return null;
 }
    try {
        if (BaseIntegerProperty.TYPE.equals(type)) {
            return Long.valueOf(example);
 } else if (DecimalProperty.TYPE.equals(type)) {
            return Double.valueOf(example);
 } else if (BooleanProperty.TYPE.equals(type)) {
            if ("true".equalsIgnoreCase(example) || "false".equalsIgnoreCase(defaultValue)) {
                return Boolean.valueOf(example);
 }
        }
    } catch (NumberFormatException e) {
        LOGGER.warn(String.format("Illegal DefaultValue %s for parameter type %s", defaultValue, type), e);
 }
    return example;
}

如上是异常相关的代码。从异常信息表象来看,是一个强转导致的问题,代码试图将一个空的字符串转换成数值类型导致异常抛出。并且是getExample时抛出的异常,这里需要了解swagger ui的加载过程和基础架构才能直接定位。swagger中的example是为了在生成的api doc中,给出相关字段的调用示例,并在触发接口调用时,默认自动填充example的值。这里显然是哪个地方的example设置不合理导致的异常。那么,接下来要做的就是找到这个空字符串的原始代码。

debug找到真实原因

借助IDEA的debug功能,点击异常后面的create breakpoint,在触发异常的地方打上断点。触发异常,进入断点,获取到了关键信息
image
一个被描述为app id的字段,用这个信息全局搜索,得到如下的结果:
image
有三个相关的Model实体,首先,这三个Model的appId字段都没有设置过example属性,所以,到这一步,可以先下一个小的结论,不是我们设置的example导致的问题,默认在不设置的情况下,example的默认值就是空字符串。然后肯定只有其中一个有问题,因为异常只会触发一次。在不知道结果情况下,依次对这三个Model的appId字段加上正确的example描述,经测试,只有GetAppBannerRequestDTO加上时,异常才消失,罪魁祸首就是它了。但是,为什么呢?其他两个Model为啥就没有问题呢?在博主交叉测验后,发现了最终的原因。

结论及注意事项

当Model作用于请求的接收参数时,并且请求的类型为GET,那么Swagger Ui会自动收集Model所有属性的examole参数,因为这个参数是字符串类型,所以会做一个类型转换动作。当字段类型为数值类型,又有没手动设置example的值,那么Swagger框架拿到的是个空字符串,强转空字符串就抛异常了。而如果请求是POST,就不会触发这段逻辑,所以同为携带数值类型DTO的ImgReplaceRequestDTO没有问题。如果不是接收参数,作为响应参数,也不会触发这段逻辑,故而AppBannerResponseVO也就没有问题了。所以,需要注意的就是当DTO作用于GET请求的接收参数时,切记给所有的数值类型加上正确的example属性

后记

博主认为这里属于一个设计缺陷,而不是我们的使用问题。在获取example的逻辑里,第一段代码就判断了example是否为null。这表明了example有可能为空,但是默认值却设置了一个空字符串。代表不手动将example设置为null,这段判null返回的逻辑就永远跑不到,而且没人会这么做,手动给example设置为null。况且,在触发异常的这种场景下,框架不能强制使用者设置example这种操作。在github仓库追踪这块代码发现,目前Swagger ui已经迈入了3.x版本,全面基于open api v3协议规范设计。所以,这部分代码完全不一样了。而存档的1.5x版本这个问题依旧。

下面是3.x的处理方式,虽然example的默认值还是“”。但是通过NotBlank判断了下,所以不会触发异常了
image

为啥不直接升级3.x?

3.x版本既然已经修复了,为啥不直接升级到3.x版本呢?可能有人会有这个疑问。Swagger3.x版本属于一个大跨度的迭代版本,和之前的版本完全不兼容,3.x主要面向了open api v3规范协议设计实现,注解实体等模型都是一一对应的。而在这个版本之前的1.5x系列版本是Swagger自己设计的api模型。所以代码层上面完全不兼容,升级的工作量会非常大。不过,新项目还是推荐使用3.x版本,这个版本的api数据更通用。可以根据api的数据生成各种语言的客户端包。就像proto生成客户端包一样。

查看原文

赞 0 收藏 0 评论 0

kl博主 发布了文章 · 2020-12-01

HTTP基准压测工具wrk使用指南

前言

wrk是一个开源的、热门的、现代的单机HTTP基准测试工具,目前在github开源平台累计了26.9k的star数目,足以可见wrk在Http基准测试领域的热门程度。它结合了多线程设计和可扩展的事件通知系统,如epoll和kqueue,可以在有限的资源下并发出极致的的负载请求。并且内置了一个可选的LuaJIT脚本执行引擎,可以处理复杂的HTTP请求生成、响应处理以及自定义压测报告。
wrk项目地址:https://github.com/wg/wrk

安装wrk

mac下安装:

brew install wrk

其他平台参考:https://github.com/wg/wrk/wiki

基础使用

wrk -t12 -c100 -d30s --latency http://localhost:8010/healthz

如上指令描述了采用12个线程,100个链接,针对/healthz 接口服务,持续压测30s。wrk本身不是依赖线程数来模拟并发数的所以线程数量设置在核心数左右最好,线程数多了测试系统消耗大,可能带来反效果。亲测核心数一致的线程数和两倍核心数的线程数,前者压出的QPS更高。压测结果如下:

Running 30s test @ http://localhost:8010/healthz (运行30s测试)
  12 threads and 100 connections(12个线程100个连接)
    Thread Stats        Avg(均值)      Stdev(标准差值)     Max(最大值)   +/- Stdev(正负标准差值)
    Latency(延迟)         1.39ms        668.10us           23.95ms       90.34%
    Req/Sec(每秒请求数)    5.44k          545.23             10.27k        76.47%
  Latency Distribution(延迟直方图)
     50%    1.32ms (50%请求延迟在1.32ms内)
     75%    1.49ms (75%请求延迟在1.49ms内)
     90%    1.72ms (90%请求延迟在1.72ms内)
     99%    4.77ms (99%请求延迟在4.77ms内)
  1952790 requests in 30.08s, 271.90MB read (共1952790次请求,用时30s,传输了271.9M数据)
Requests/sec(每秒请求数):  64930.12
Transfer/sec(每秒传输数据):      9.04MB

wrk的结果相比ab测试结果来说,多了一个延时直方图,有了这个直方图,我们可以更清晰的看到延迟的分布情况。这也是博主选择wrk最重要的原因

常用指令说明

 -c, --connections: 要保持打开的HTTP连接的总数,每个线程处理数N =连接/线程
    -d, --duration:    测试持续时间, 如 2s, 2m, 2h
    -t, --threads:     测试线程总数
    -s, --script:      指定加载lua测试扩展脚本
    -H, --header:      添加请求头信息, 如"User-Agent: wrk"
        --latency:     打印延迟直方图信息
        --timeout:     如果在此时间内没有收到响应,则记录超时.

-开头的指令为简写的,后面两个打印延迟直方图和超时设置没有简写的,只能--开头指定

高阶用法,lua测试脚本

wrk内置了全局变量,全局方法,以及五个测试请求发起流程的方法,还有一个模拟延迟发送的方法,wrk是内置对象,在lua测试脚本的每个方法内都可以直接使用

  • 全局变量
-- 全局的变量
wrk = {
  scheme  = "http",
  host    = "localhost",
  port    = nil,
  method  = "GET",
  path    = "/",
  headers = {},
  body    = nil,
  thread  = userdata,
}
  • 全局方法
-- 返回请求字符串值,其中包含所传递的参数和来自wrk表的值。例如:返回 http://www.kailing.pub
function wrk.format(method, path, headers, body);
-- 获取域名的IP和端口,返回table,例如:返回 `{127.0.0.1:80}`
function wrk.lookup(host, service)
-- 判断addr是否能连接,例如:`127.0.0.1:80`,返回 true 或 false
function wrk.connect(addr)
  • 请求过程方法
-- 请求前,对每个线程调用一次,并接收表示该线程的userdata对象。
function setup(thread)
    thread.addr = "http://www.kailing.pub"        -- 设置请求的地址
    thread:get("name")        -- 获取全局变量的值
    thread:set("name", "kl") -- 在线程的环境中设置全局变量的值
    thread:stop()           -- 停止线程
end
--初始化,每个线程执行一次
function init(args) --args为从命令行传过来的额外参数
    print(args)
end
--发起请求,每次请求执行一次,返回包含HTTP请求的字符串。每次构建新请求的开销都很大,在测试高性能服务器时,
--一种解决方案是在init()中预先生成所有请求,并在request()中进行快速查找。
function request()
    requests = requests + 1
    return wrk.request()
end
--响应处理,每次请求执行一次
function response(status, headers, body)
    responses = responses + 1
end
--请求完成,每次测试执行一次。done()函数接收一个包含结果数据的表和两个统计数据对象,分别表示每个请求延迟和每个线程请求速率。
--持续时间和延迟是微秒值,速率是以每秒请求数来度量的。
function done(summary, latency, requests)
    for index, thread in ipairs(threads) do
        local id = thread:get("id")
        local requests = thread:get("requests")
        local responses = thread:get("responses")
        local msg = "thread %d made %d requests and got %d responses"
        print(msg:format(id, requests, responses))
    end
end

整个脚本处理过程被分为准备阶段、运行阶段、完成阶段。准备阶段在目标IP地址被解析并且所有线程都已经初始化但还没有启动之后开始。运行阶段从对init()的单个调用开始,然后对每个请求周期调用request()和response()。init()函数接收脚本的任何额外命令行参数,这些参数必须用“——”与wrk参数分隔开。

lua测试脚本案例分析

案例:我们线上有一个带缓存场景的接口服务,根据appId的值的查询结果缓存,所以,如果单纯对指定的appId压测,就变成了测试缓存系统的负载了,测试不出实际的服务性能,这个场景就需要测试工具发起每次请求的测试参数都是动态的。根据这个场景我们定制了如下的lua测试脚本:

-- 测试指令:wrk -t16 -c100 -d5s -sreview_digress_list.lua --latency htt://127.0.0.1:8081
wrk.method ="GET"
wrk.path = "/app/{appId}/review_digress_list"

function request()
    -- 动态生成每个请求的url
    local requestPath = string.gsub(wrk.path,"{appId}",math.random(1,10))
    -- 返回请求的完整字符串:http://127.0.0.1//app/666/review_digress_list
    return wrk.format(nil, requestPath)
end
查看原文

赞 0 收藏 0 评论 0

kl博主 发布了文章 · 2020-11-30

spring boot metrics使用指南

spring boot metrics是什么?

针对应用监控指标暴露,spring boot有一套完整的解决方案,并且内置了好很多的指标收集器,如tomcat、jvm、cpu、kafka、DataSource、spring mvc(缺少直方图的数据)等。基于micrometer技术,几乎支持所有主流的监控服务的指标数据收集,这其中就包含了我们线上使用的Prometheus,这份指南旨在最快速接入boot的metrics功能,暴露prometheus的数据监控指标服务。

micrometer地址:https://micrometer.io/

一、引入依赖

implementation ('org.springframework.boot:spring-boot-starter-actuator')
implementation ('io.micrometer:micrometer-registry-prometheus:1.6.1')
implementation ('io.micrometer:micrometer-core:1.6.1')

actuator是spring boot中负责运维功能的包,这里主要是通过它来暴露和管理metrics接口的。其他两个依赖是为了包兼容引入的,在sprinr boot2.x中,actuator中默认引入的prometheus支持包存在兼容性问题,如果你的环境不存在兼容性问题,可以不用引入下面两个依赖。

二、配置启用

通过如下的配置,来开启prometheus的端点接口服务

management.endpoints.web.exposure.include=prometheus

开启服务后,会暴露/actuator/prometheus 端点接口服务。在浏览器中,输入http://localhost:8080/actuator/prometheus 。可以看到内置的指标收集器收集到的监控指标

三、独立的web服务

默认情况下,/actuator/prometheus端点服务跟随应用的web容器一起发布,但是当我们的web服务面向公网需要授权认证时,可以使用如下配置启用独立的容器暴露服务

management.server.port=8081

四、全局标签设置

在metrics监控系统设计中,tag用来标记区分一组指标集。比如我们在监控grpc时,servicename就是是监控指标的其中一个tag。有的时候为了区分环境和应用,我们会设置一些全局的tag:

management.metrics.tags.application = ${spring.application.name}
management.metrics.tags.region = bj

如上配置,我们添加了一个应用的名字和一个区域的tag。这种配置是全局的。虽然grpc的组件可能只记录了servicename,但是最终数据呈现时,也会带上全局配置的tag

五、自定义指标收集

spring boot所有的指标最终都是通过MeterRegistry来注册的,这个实例被spring托管,所以你可以在spring的上下文中注入这个实例,结合micrometer指标定义(点我),自定义自己的监控指标

六、推送or拉取指标

目前,我们线上是通过k8s的monitoring.coreos.com/v1 api定义指定prometheus主动拉取应用pod的监控指标信息,主要是因为之前的metrics系统是基于prometheus client模式暴露的。在基于spring boot的metrics系统中,主动推送数据的模式非常容易实现,这里需要prometheus-gateway支持

引入依赖

implementation("io.prometheus:simpleclient_pushgateway")

启用push模式

#开启prometheus的数据推送模式
management.metrics.export.prometheus.pushgateway.enabled=true
#prometheus服务端地址
management.metrics.export.prometheus.pushgateway.base-url=localhost:9091
#推送数据的频率,默认1m(单位分钟)
management.metrics.export.prometheus.pushgateway.push-rate=1m
#在jvm关闭之前将数据推送出去
management.metrics.export.prometheus.pushgateway.shutdown-operation=push
查看原文

赞 0 收藏 0 评论 0

kl博主 发布了文章 · 2020-11-24

RocketMQ本地IDEA开发调试环境搭建

前言

发现公司这边的消息中间件采用了aliyun的RocketMQ服务,熟悉开源的同学都知道,RocketMQ是国内最早一批捐献Apache并成功毕业的项目。架构设计参考了kafka的模式,所以如果你了解kafka的架构,对于RocketMQ就可以轻车熟路了,虽然参考了kafka,但是RocketMQ也有很多的升级,比如Broker的注册和发现就采用了内部的NameServer,没有引入更多的第三方依赖,而且添加了诸如消息回溯、事务消息、延时消息等特色功能。由于之前没有接触过RocketMQ(之前一直用的kafka和RabbitMQ),准备研究一番,也为了后面集成spring boot metrics监控RocketMQ客户端信息做准备。研究一个开源项目,最好的方法就是Debug,所以记录下本地搭建RocketMq的调试环境过程

生成安装包

项目地址:https://github.com/apache/rocketmq ,从这个地址下载项目后,导入到IDEA开发工具,执行mvn install,生成安装RocketMQ包,生成成功后,在distribution模块下,会有如下目录,这个目录等下会用到
image.png

启动NameServer

找到namesrv模块,运行NamesrvStartup的main方法,这个时候会提示你,需要设置ROCKETMQ_HOME,提示信息如下:
image.png

这个时候就需要第一步生成的目录,拷贝/Users/kl/githubnamespace/rocketmq/distribution/target/rocketmq-4.7.1/rocketmq-4.7.1目录,在IDEA的运行设置界面,添加如下参数:

-Drocketmq.home.dir=/Users/kl/githubnamespace/rocketmq/distribution/target/rocketmq-4.7.1/rocketmq-4.7.1

如:
image.png

然后在启动,就可以成功启动了

启动broker

参照启动NameServer的模式,找到borker模块,设置好ROCKETMQ_HOME,在用相同的方式采用-D方式,配置下NameServer的地址,如:

-Drocketmq.namesrv.addr=127.0.0.1:9876

然后启动即可,此时一个完整的跑在IDEA中的单节点架构的RocketMQ服务就搭建好了

安装RocketMQ Console

为了更好的观察了解RocketMQ的功能,可以安装一个web管理控制台,这个需要用到另一个项目

项目地址:https://github.com/apache/rocketmq-externals/tree/master/rocketmq-console

安装成功后,就可以通过web页面查询producer发送的message信息,打开浏览器,输入:http://localhost:8080。就可以看到如下页面:
image.png

尽情的Debug

一切准备就绪后,可以找到项目的example模块,里面内置了各种特性功能的使用案例,接下来就可以一个一个案例Runing起来,尽情的Deubg

查看原文

赞 0 收藏 0 评论 0

kl博主 发布了文章 · 2020-11-21

给gRPC-spring-boot-starter一个pr的说明

前言

为了更好的说明给gRPC-spring-boot-starter项目提交bug修复的pr的原因,解答作者的问题。以博文的形式记录了整个过程的上下文,目前pr未合并还在沟通处理中,希望此博文可以更清楚描述问题

pr地址:https://github.com/yidongnan/grpc-spring-boot-starter/pull/454

gRPC-spring-boot-starter是什么?

这是一个spring-boot-starter项目,用来在spring boot框架下,快速便捷的使用grpc技术,开箱即用。它提供如下等功能特性:

  • 在 spring boot 应用中,通过@GrpcService自动配置并运行一个嵌入式的 gRPC 服务。
  • 使用@GrpcClient自动创建和管理您的 gRPC Channels 和 stubs
  • 支持Spring Cloud(向ConsulEurekaNacos注册服务并获取 gRPC 服务端信息)
  • 支持Spring Sleuth作为分布式链路跟踪解决方案(如果brave-instrument-grpc存在)
  • 支持全局和自定义的 gRPC 服务端/客户端拦截器
  • 支持Spring-Security
  • 支持metric (基于micrometer/actuator)
  • 也适用于 (non-shaded) grpc-netty

选型gRPC-spring-boot-starter

博主新入职公司接手的项目采用grpc做微服务通讯框架,项目底层框架采用的spring boot,然后grpc的使用是纯手工配置的,代码写起来比较繁琐, 而且这种繁琐的模板化代码充斥在每个采用了grpc的微服务项目里。所以技术选型后找到了gRPC-spring-boot-starter 这个开源项目,这个项目代码质量不错,非常规范,文档也比较齐全。但是鉴于之前工作经验遇到过开源项目的问题(博主选型的原则,如果有合适的轮子,就摸透这个轮子,然后基于这个轮子二开,没有就自己造一个轮子),而且一般解决周期比较长,所以 最后,我们没有直接采用他们的发行包,而是fork了项目后,打算自己维护。正因为如此,才为后面迅速解决问题上线成为可能。也验证了二开这个选择是正确的。

bug出现,grpc未优雅下线

风风火火重构了所有代码,全部换成gRPC-spring-boot-starter后就上线了,上线后一切都非常好,但是项目在第二次需求上线投产时发生了一些问题。 这个时候还不确定是切换grpc实现导致的问题,现象就是,线上出现了大量的请求异常。上线完成后,异常就消失了。后面每次滚动更新都会出现类似的异常。 这个时候就很容易联系到是否切换grpc实现后,grpc未优雅下线,导致滚动更新时,大量的进行中的请求未正常处理,导致这部分流量异常?因为我们线上 流量比较大,几乎每时每刻都有大量请求,所以我们要求线上服务必须支持无缝滚动更新。如果流量比较小,这个问题可能就不会暴露出来,这也解释了之前和同事讨论的点,为什么这么明显的问题没有被及早的发现。不过都目前为止,这一切都只是猜测,真相继续往下。

定位bug,寻找真实原因

有了上面的猜测,直接找到了gRPC-spring-boot-starter管理维护GrpcServer生命周期的类GrpcServerLifecycle,这个类实现了spring的SmartLifecycle接口,这个接口是用来注册SpringContextShutdownHook的钩子用的,它的实现如下:

@Slf4j
public class GrpcServerLifecycle implements SmartLifecycle {
    private static AtomicInteger serverCounter = new AtomicInteger(-1);

    private volatile Server server;
    private volatile int phase = Integer.MAX_VALUE;
    private final GrpcServerFactory factory;

    public GrpcServerLifecycle(final GrpcServerFactory factory) {
        this.factory = factory;
    }

    @Override
    public void start() {
        try {
            createAndStartGrpcServer();
        } catch (final IOException e) {
            throw new IllegalStateException("Failed to start the grpc server", e);
        }
    }

    @Override
    public void stop() {
        stopAndReleaseGrpcServer();
    }

    @Override
    public void stop(final Runnable callback) {
        stop();
        callback.run();
    }

    @Override
    public boolean isRunning() {
        return this.server != null && !this.server.isShutdown();
    }

    @Override
    public int getPhase() {
        return this.phase;
    }

    @Override
    public boolean isAutoStartup() {
        return true;
    }

    /**
     * Creates and starts the grpc server.
     *
     * @throws IOException If the server is unable to bind the port.
     */
    protected void createAndStartGrpcServer() throws IOException {
        final Server localServer = this.server;
        if (localServer == null) {
            this.server = this.factory.createServer();
            this.server.start();
            log.info("gRPC Server started, listening on address: " + this.factory.getAddress() + ", port: "
                    + this.factory.getPort());

            // Prevent the JVM from shutting down while the server is running
            final Thread awaitThread = new Thread(() -> {
                try {
                    this.server.awaitTermination();
                } catch (final InterruptedException e) {
                    Thread.currentThread().interrupt();
                }
            }, "grpc-server-container-" + (serverCounter.incrementAndGet()));
            awaitThread.setDaemon(false);
            awaitThread.start();
        }
    }

    /**
     * Initiates an orderly shutdown of the grpc server and releases the references to the server. This call does not
     * wait for the server to be completely shut down.
     */
    protected void stopAndReleaseGrpcServer() {
        final Server localServer = this.server;
        if (localServer != null) {
            localServer.shutdown();
            this.server = null;
            log.info("gRPC server shutdown.");
        }
    }

}

也就是说当spring容器关闭时,会触发ShutdownHook,进而关闭GrpcServer服务,问题就出现在这里,从stopAndReleaseGrpcServer()方法可知,Grpc进行shudown()后,没有进行任何操作,几乎瞬时就返回了,这就导致了进程在收到kill命令时,Grpc的服务会被瞬间回收掉,而不会等待执行中的处理完成,这个判断可以从shutdown()的文档描述中进一步得到确认,如:

  /**
   * Initiates an orderly shutdown in which preexisting calls continue but new calls are rejected.
   * After this call returns, this server has released the listening socket(s) and may be reused by
   * another server.
   *
   * <p>Note that this method will not wait for preexisting calls to finish before returning.
   * {@link #awaitTermination()} or {@link #awaitTermination(long, TimeUnit)} needs to be called to
   * wait for existing calls to finish.
   *
   * @return {@code this} object
   * @since 1.0.0
   */
  public abstract Server shutdown();

文档指出,调用shutdown()后,不在接收新的请求流量,进行中的请求会继续处理完成,但是请注意,它不会等待现有的调用请求完成,必须使用awaitTermination()方法等待请求完成,也就是说,这里处理关闭的逻辑里,缺少了awaitTermination()等待处理中的请求完成的逻辑。

模拟环境,反复验证

验证方法:

这个场景的问题非常容易验证,只需要在server端模拟业务阻塞耗时长一点,然后kill掉java进程,看程序是否会立刻被kill。正常优雅下线关闭的话,会等待阻塞的时间后进程kill。否则就会出现不管业务阻塞多长时间,进程都会立马kill。

验证定位的bug

先验证下是否如上面所说,不加awaitTermination()时,进程是否立马就死了。直接使用gRPC-spring-boot-starter里自带的demo程序,在server端的方法里加上如下模拟业务执行耗时的代码:

@GrpcService public class GrpcServerService extends SimpleGrpc.SimpleImplBase {

    @Override
  public void sayHello(HelloRequest req, StreamObserver<HelloReply> responseObserver) {
        HelloReply reply = HelloReply._newBuilder_().setMessage("Hello ==> " \+ req.getName()).build();
 try {
            System._err_.println("收到请求,阻塞等待");
  TimeUnit._MINUTES_.sleep(1);
  System._err_.println("阻塞完成,请求结束");
  } catch (InterruptedException e) {
            e.printStackTrace();
  }
        responseObserver.onNext(reply);
  responseObserver.onCompleted();
  }
}

上面代码模拟的执行一分钟的方法,然后触发grpc client调用。接着找到server端的进程号,直接kill掉。发现进程确实立马就kill了。继续加大阻塞的时间,从一分钟加大到六分钟,重复测试,还是立马就kill掉了,没有任何的等待。

验证修复后的效果

先将上面的代码修复下,正确的关闭逻辑应该如下,在Grpc发出shutdown指令后,阻塞等待所有请求正常结束,同时,这里阻塞也会夯住主进程不会里面挂掉。

    protected void stopAndReleaseGrpcServer() {
        final Server localServer = this.server;
        if (localServer != null) {
            localServer.shutdown();
            try {
                this.server.awaitTermination();
            } catch (final InterruptedException e) {
                Thread.currentThread().interrupt();
            }
            this.server = null;
            log.info("gRPC server shutdown.");
        }
    }

同样,如上述步骤验证,当kill掉java进程后,此时java进程并没有立马就被kill,而是被awaitTermination()阻塞住了线程,直到业务方法中模拟的业务阻塞结束后,java进程才被kill掉,这正是我们想要达到的优雅下线关闭的效果。被kill时的,线程堆栈如下:

即使被kill了,还是能打印如下的日志【阻塞完成,请求结束】,进一步验证了修复后确实解决了问题:

查看原文

赞 0 收藏 0 评论 0

kl博主 发布了文章 · 2020-11-20

集成apollo动态日志,“消灭”logback-spring.xml

前言

动态调整线上日志级别是一个非常常见的场景,借助apollo这种配置中心组件非常容易实现。作为apollo的官方技术支持,博主经常在技术群看到有使用者询问apollo是否可以托管logback的配置文件,毕竟有了配置中心后,消灭所有的本地配置全部交给apollo管理是我们的最终目标。可是,apollo不具备直接托管logback-spring.xml配置文件能力,但是,我们可以基于spring和logback的装载机制,完全取缔logback-spring.xml配置,以apollo中的配置驱动。而且,改造后,大大提高了日志系统的灵活性和可扩展性。

apollo动态日志

何为apollo动态日志?直接这样说可能会有歧义,以为是apollo里的日志,其实不然。举个简单的例子,比如,我们项目很多地方使用了log.debug()打印日志,为了方便通过日志信息排查问题,但是一般情况下,生产环境的日志级别会配置成info。只有遇到需要排查线上问题的时候才会临时打开debug级别日志。这个时候只能需改配置文件,将日志级别调整成debug,然后重新打包部署验证。不仅流程繁琐耗时,还会破坏当时的"案发现场的环境",导致判断不准确。如果应用具备了apollo动态日志这种能力,就只需在apollo修改下配置然后提交,就可以热更新日志级别,马上打印debug级别日志。这就是所谓的apollo动态日志。实现这个效果,需要具备两个能力,分别由spring和apollo提供

spring日志系统热更新日志级别

spring应用中,spring适配了主流的日志框架,如logback、log4j2等,在这些日志框架之上,又抽象了自己的日志系统服务,这里我们用到了spring的LoggingSystem,用它来热更新日志级别,这个类在日志系统初始化时就添加到了spring的容器中,所以只要在spring的上下文管理范围内,就可以直接注入,以下为主要使用到的api描述:

    /**
     * 设置给定日志记录器的日志级别.
     * @param loggerName 要设置的日志记录器的名称({@code null}可用于根日志记录器)。
     * @param level 日志级别
     */
    public void setLogLevel(String loggerName, LogLevel level) {
        throw new UnsupportedOperationException("Unable to set log level");
    }

apollo日志配置变更动态下发

apollo作为分布式配置中心,配置集中管理和配置热更新是其最核心的功能,此外,apollo还提供了配置变更下发监听的功能。基于这个配置监听的设计,实现动态日志就变得非常简单了。而且不仅可以实现日志动态热更,基于这个思路,连接池、数据源等都可以轻松实现。apollo实现监听配置变更有多种方式,可以通过Config实例手动添加,如:

    @ApolloConfig
    public Config config;
    
    public void addConfigChangeListener(){
        config.addChangeListener(changeEvent->{
            System.out.println("config change keys" + changeEvent.changedKeys());
        });
    }

也可以通过注解直接驱动

    @ApolloConfigChangeListener
    public void addConfigChangeListener(ConfigChangeEvent changeEvent){
            System.out.println("config change keys" + changeEvent.changedKeys());
    }

实现日志调整热更新

有了上述能力,在结合spring支持的日志加载配置方式,如:

logging.level.org.springframework.web=debug
logging.level.org.hibernate=error

可以实现如下代码完成功能,遇到需要调整日志级别时,修改apollo里的配置,即可实时生效

@Configuration
public class LogbackConfiguration {

    private static final Logger logger = LoggerFactory.getLogger(LoggerConfiguration.class);
    private static final String LOGGER_TAG = "logging.level.";
    private final LoggingSystem loggingSystem;
    public LogbackConfiguration(LoggingSystem loggingSystem) {
        this.loggingSystem = loggingSystem;
    }

    @ApolloConfigChangeListener
    private void onChange(ConfigChangeEvent changeEvent) {
        for (String key : changeEvent.changedKeys()) {
            if (this.containsIgnoreCase(key, LOGGER_TAG)) {
                String strLevel = changeEvent.getChange(key).getNewValue();
                LogLevel level = LogLevel.valueOf(strLevel.toUpperCase());
                loggingSystem.setLogLevel(key.replace(LOGGER_TAG, ""), level);
                logger.info("logging changed: {},oldValue:{},newValue:{}", key, changeEvent.getChange(key).getOldValue(), strLevel);
            }
        }
    }
    
    private boolean containsIgnoreCase(String str, String searchStr) {
        if (str == null || searchStr == null) {
            return false;
        }
        int len = searchStr.length();
        int max = str.length() - len;
        for (int i = 0; i <= max; i++) {
            if (str.regionMatches(true, i, searchStr, 0, len)) {
                return true;
            }
        }
        return false;
    }
}

消灭logback-spring.xml配置

在"消灭"logback-xml配置之前,先看下这个配置文件有哪些配置信息,起到了哪些作用,下面贴出一个典型的配置文件内容:

<?xml version="1.0" encoding="UTF-8"?>
<configuration>
  <include resource="org/springframework/boot/logging/logback/defaults.xml"/>
  <include resource="org/springframework/boot/logging/logback/console-appender.xml"/>
  <appender name="Sentry" class="io.sentry.logback.SentryAppender">
    <filter class="ch.qos.logback.classic.filter.ThresholdFilter">
      <level>ERROR</level>
    </filter>
  </appender>
  <root level="INFO">
    <appender-ref ref="CONSOLE"/>
    <appender-ref ref="Sentry"/>
  </root>
  <logger name="org.apache.ibatis.session" level="WARN"/>
  <springProfile name="dev">
    <logger name="com.taptap.server" level="DEBUG"/>
    <logger name="com.taptap.commons" level="DEBUG"/>
  </springProfile>
  <springProfile name="prod">
    <logger name="com.taptap.server" level="WARN"/>
    <logger name="com.taptap.commons" level="WARN"/>
  </springProfile>
</configuration>

一个典型的logback配置文件里包含了Appender和日志级别设置的信息,Appender可以理解为日志的输出源。如上贴出的这个配置,添加了两个Appender信息,一个是spring中内置的,将日志输出到控制台的Appender。一个是将error日志信息发送到Sentry应用监控平台的Appender。其他的配置描述了每个包路径不同的日志级别信息。到这里,我们很容易想到,上文已经说过,spring已经支持以logging.level.包名=info这种配置来设置日志系统的日志级别。那么剩下的只要解决Appender的配置就ok了。在这里,其实只需要解决SentryAppender的加载就行,因为consoleAppender spring自己会处理。有了目标和方向,就好办了。以logback-spring.xml配置的信息,最终都会加载成class对象。就和spring.xml配置一样。所以研究的方向就变成了Logback的加载原理的问题。

Logback加载原理

在java的日志生态里,除了响当当的logback、log4j2、apache common log外,还有一个日志框架不得不提,就是sl4j。正因为java生态强大,日志框架层出不穷,所以sl4j出来了,不干实事,专门定义日志标准、规范定义接口。而且,在我们平时的编码过程中,也建议使用sl4j的api,这样,无论底层日志框架实现怎么切换,都不会影响。主流的日志框架都有实现sl4j的接口,spring中日志系统的加载也是面向的sl4j,而不是直接面向日志实现,加载过程是一个自动化的过程,系统会自动扫描实现了sl4j的接口实现,如:

public interface ILoggerFactory {
    public Logger getLogger(String name);
}

每个日志框架都会实现这个接口,如Logback中的LoggerContext。Logback所有的功能都集成在了这个Context中,logback-spring.xml的配置也是为了配置LoggerContext中的属性信息,所有我们只要拿到了LoggerContext实例,问题就解决了一大半。这涉及到sl4j的另一个接口,获取ILoggerFactory实例的接口:

public interface LoggerFactoryBinder {

    public ILoggerFactory getLoggerFactory();

    public String getLoggerFactoryClassStr();
}

Logback的实现类为StaticLoggerBinder,也就是说,我们可以通过StaticLoggerBinder的getLoggerFactory方法拿到LoggerContext实例了。

javaBean加载SentryAppender

拿到Logback的LoggerContext后,就好办了,见代码:

@Configuration
public class LogbackConfiguration {

    private final LoggerContext ctx = (LoggerContext) StaticLoggerBinder.getSingleton().getLoggerFactory();

    @Bean
    @Profile(PROD_ENV)
    public void initSenTry() {
        SentryAppender sentryAppender = new SentryAppender();
        sentryAppender.setContext(ctx);
        ThresholdFilter filter = new ThresholdFilter();
        filter.setLevel(Level.ERROR.levelStr);
        filter.start();
        sentryAppender.addFilter(filter);
        sentryAppender.start();
        ctx.addTurboFilter(new TurboFilter() {
            @Override
            public FilterReply decide(Marker marker, ch.qos.logback.classic.Logger logger, Level level, String format, Object[] params, Throwable t) {
                logger.addAppender(sentryAppender);
                return FilterReply.NEUTRAL;
            }
        });
    }
}

看到这种代码就非常有感觉了,配置文件中的xml其实就是描述了日志组成对象以及对象的属性。在使用java bean的方式配置时需要注意,Logback的设计里,每个日志系统组成实例都有一个start状态属性,上面的start()方法其实不是动作,只是标记了这个属性为true。而在xml里这个属性只要配置了就自动激活为true了,这里必须显示的start()一下。解决了日志级别配置和Appender配置后,Logback-spring.xml文件就可以彻底的删除了

查看原文

赞 0 收藏 0 评论 0

kl博主 发布了文章 · 2020-06-11

JPA多数据源分布式事务处理-两种事务方案

前言

多数据源的事务处理是个老生常谈的话题,跨两个数据源的事务管理也算是分布式事务的范畴,在同一个JVM里处理多数据源的事务,比较经典的处理方案是JTA(基于XA协议建模的java标准事务抽象)+XA(XA事务协议),常见的JTA实现框架有Atomikos、Bitronix、Narayana,Spring对这些框架都有组件封装,基本可以做到开箱即用程度。本文除了分享XA事务方案外,提供了一种新的多数据源事务解决思路和视角。

问题背景

在解决mysql字段脱敏处理时,结合sharding-jdbc的脱敏组件功能,为了sql兼容和最小化应用改造,博主给出了一个多数据源融合的字段脱敏解决方案(只把包含脱敏字段表的操作走sharding-jdbc脱敏代理数据源)。这个方案解决了问题的同时,带来了一个新的问题,数据源的事务是独立的,正如我文中所述《JPA项目多数据源模式整合sharding-jdbc实现数据脱敏》,在spring上下文中,每个数据源对应一个独立的事务管理器,默认的事务管理器的数据源就用业务本身的数据源,所以需要加密的业务使用时,需要指定@Transactional注解里的事务管理器名称为脱敏对应的事务管理器名称。简单的业务场景这样用也就没有问题了,但是一般的业务场景总有一个事务覆盖两个数据源的操作,这个时候单指定哪个事务管理器都不行,so,这里需要一种多数据源的事务管理器。

XA事务方案

XA协议采用2PC(两阶段提交)的方式来管理分布式事务。XA接口提供资源管理器与事务管理器之间进行通信的标准接口。在JDBC的XA事务相关api抽象里,相关接口定义如下

XADataSource,XA协议数据源

public interface XADataSource extends CommonDataSource {
  /**
   * 尝试建立物理数据库连接,使用给定的用户名和密码。返回的连接可以在分布式事务中使用
   */
  XAConnection getXAConnection() throws SQLException;
   //省略getLogWriter等非关键方法
 }

XAConnection

public interface XAConnection extends PooledConnection {

    /**
     * 检索一个{@code XAResource}对象,事务管理器将使用该对象管理该{@code XAConnection}对象在分布式事务中的事务行为
     */
    javax.transaction.xa.XAResource getXAResource() throws SQLException;
}

XAResource

public interface XAResource {
    /**
     * 提交xid指定的全局事务
     */
    void commit(Xid xid, boolean onePhase) throws XAException;

    /**
     * 结束代表事务分支执行的工作。资源管理器从指定的事务分支中分离XA资源,并让事务完成。
     */
    void end(Xid xid, int flags) throws XAException;

    /**
     * 通知事务管理器忽略此xid事务分支
     */
    void forget(Xid xid) throws XAException;

    /**
     * 判断是否同一个资源管理器
     */
    boolean isSameRM(XAResource xares) throws XAException;

    /**
     * 指定xid事务准备阶段
     */
    int prepare(Xid xid) throws XAException;

    /**
     * 从资源管理器获取准备好的事务分支的列表。事务管理器在恢复期间调用此方法,
     * 以获取当前处于准备状态或初步完成状态的事务分支的列表。
     */
    Xid[] recover(int flag) throws XAException;

    /**
     * 通知资源管理器回滚代表事务分支完成的工作。
     */
    void rollback(Xid xid) throws XAException;

    /**
     * 代表xid中指定的事务分支开始工作。
     */
    void start(Xid xid, int flags) throws XAException;

    //省略非关键方法
}

相比较普通的事务管理,JDBC的XA协议管理多了一个XAResource资源管理器,XA事务相关的行为(开启、准备、提交、回滚、结束)都由这个资源管理器来控制,这些都是框架内部的行为,体现在开发层面提供的数据源也变成了XADataSource。而JTA的抽象里,定义了UserTransaction、TransactionManager。想要使用JTA事务,必须先实现这两个接口。所以,如果我们要使用JTA+XA控制多数据源的事务,在sprign boot里以Atomikos为例,

引入Atomikos依赖

        <dependency>
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-starter-jta-atomikos</artifactId>
        </dependency>

spring boot已经帮我们把XA事务管理器自动装载类定义好了,如:

创建JTA事务管理器

@Configuration(proxyBeanMethods = false)
@EnableConfigurationProperties({ AtomikosProperties.class, JtaProperties.class })
@ConditionalOnClass({ JtaTransactionManager.class, UserTransactionManager.class })
@ConditionalOnMissingBean(PlatformTransactionManager.class)
class AtomikosJtaConfiguration {

    @Bean(initMethod = "init", destroyMethod = "shutdownWait")
    @ConditionalOnMissingBean(UserTransactionService.class)
    UserTransactionServiceImp userTransactionService(AtomikosProperties atomikosProperties,
            JtaProperties jtaProperties) {
        Properties properties = new Properties();
        if (StringUtils.hasText(jtaProperties.getTransactionManagerId())) {
            properties.setProperty("com.atomikos.icatch.tm_unique_name", jtaProperties.getTransactionManagerId());
        }
        properties.setProperty("com.atomikos.icatch.log_base_dir", getLogBaseDir(jtaProperties));
        properties.putAll(atomikosProperties.asProperties());
        return new UserTransactionServiceImp(properties);
    }
    @Bean(initMethod = "init", destroyMethod = "close")
    @ConditionalOnMissingBean(TransactionManager.class)
    UserTransactionManager atomikosTransactionManager(UserTransactionService userTransactionService) throws Exception {
        UserTransactionManager manager = new UserTransactionManager();
        manager.setStartupTransactionService(false);
        manager.setForceShutdown(true);
        return manager;
    }
    @Bean
    @ConditionalOnMissingBean(XADataSourceWrapper.class)
    AtomikosXADataSourceWrapper xaDataSourceWrapper() {
        return new AtomikosXADataSourceWrapper();
    }
    @Bean
    JtaTransactionManager transactionManager(UserTransaction userTransaction, TransactionManager transactionManager,
            ObjectProvider<TransactionManagerCustomizers> transactionManagerCustomizers) {
        JtaTransactionManager jtaTransactionManager = new JtaTransactionManager(userTransaction, transactionManager);
        transactionManagerCustomizers.ifAvailable((customizers) -> customizers.customize(jtaTransactionManager));
        return jtaTransactionManager;
    }
    、、、、、、、、、、
}

显然,想要使用XA事务,除了需要提供UserTransaction、TransactionManager的实现。还必须要有一个XADataSource,而sharding-jdbc代理的数据源是DataSource的,我们需要将XADataSource包装成普通的DataSource,spring已经提供了一个AtomikosXADataSourceWrapper的XA数据源包装器,而且在AtomikosJtaConfiguration里已经注册到Spring上下文中,所以我们在自定义数据源时可以直接注入包装器实例,然后,因为是JPA环境,所以在创建EntityManagerFactory实例时,需要指定JPA的事务管理类型为JTA,综上,普通的业务默认数据源配置如下:

/**
 * @author: kl @kailing.pub
 * @date: 2020/5/18
 */
@Configuration
@EnableConfigurationProperties({JpaProperties.class, DataSourceProperties.class})
public class DataSourceConfiguration{

    @Primary
    @Bean
    public DataSource dataSource(AtomikosXADataSourceWrapper wrapper, DataSourceProperties dataSourceProperties) throws Exception {
        MysqlXADataSource dataSource = dataSourceProperties.initializeDataSourceBuilder().type(MysqlXADataSource.class).build();
        return wrapper.wrapDataSource(dataSource);
    }

    @Primary
    @Bean(initMethod = "afterPropertiesSet")
    public LocalContainerEntityManagerFactoryBean entityManagerFactory(JpaProperties jpaProperties, DataSource dataSource, EntityManagerFactoryBuilder factoryBuilder) {
        return factoryBuilder.dataSource(dataSource)
                .packages(Constants.BASE_PACKAGES)
                .properties(jpaProperties.getProperties())
                .persistenceUnit("default")
                .jta(true)
                .build();
    }

    @Bean
    @Primary
    public EntityManager entityManager(EntityManagerFactory entityManagerFactory){
        //必须使用SharedEntityManagerCreator创建SharedEntityManager实例,否则SimpleJpaRepository中的事务不生效
        return SharedEntityManagerCreator.createSharedEntityManager(entityManagerFactory);
    }
}

sharding-jdbc加密数据源和普通业务数据源其实是同一个数据源,只是走加解密逻辑的数据源需要被sharding-jdbc的加密组件代理一层,加上了加解密的处理逻辑。所以配置如下:

/**
 * @author: kl @kailing.pub
 * @date: 2020/5/18
 */
@Configuration
@EnableConfigurationProperties({JpaProperties.class,SpringBootEncryptRuleConfigurationProperties.class, SpringBootPropertiesConfigurationProperties.class})
public class EncryptDataSourceConfiguration {

    @Bean
    public DataSource encryptDataSource(DataSource dataSource,SpringBootPropertiesConfigurationProperties props,SpringBootEncryptRuleConfigurationProperties encryptRule) throws SQLException {
        return EncryptDataSourceFactory.createDataSource(dataSource, new EncryptRuleConfigurationYamlSwapper().swap(encryptRule), props.getProps());
    }

    @Bean(initMethod = "afterPropertiesSet")
    public LocalContainerEntityManagerFactoryBean encryptEntityManagerFactory(@Qualifier("encryptDataSource") DataSource dataSource,JpaProperties jpaProperties, EntityManagerFactoryBuilder factoryBuilder) throws SQLException {
        return factoryBuilder.dataSource(dataSource)
                .packages(Constants.BASE_PACKAGES)
                .properties(jpaProperties.getProperties())
                .persistenceUnit("encryptPersistenceUnit")
                .jta(true)
                .build();
    }

    @Bean
    public EntityManager encryptEntityManager(@Qualifier("encryptEntityManagerFactory") EntityManagerFactory entityManagerFactory){
        //必须使用SharedEntityManagerCreator创建SharedEntityManager实例,否则SimpleJpaRepository中的事务不生效
        return SharedEntityManagerCreator.createSharedEntityManager(entityManagerFactory);
    }
}
  • 遇到问题1、:Connection pool exhausted - try increasing 'maxPoolSize' and/or 'borrowConnectionTimeout' on the DataSourceBean.
  • 解决问题:默认AtomikosXADataSourceWrapper包装器初始化的数据源连接池最大为1,所以需要添加配置参数如:
spring.jta.atomikos.datasource.max-pool-size=20
  • 遇到问题2、: XAER_INVAL: Invalid arguments (or unsupported command)
  • 解决问题:这个是mysql实现XA的bug,仅当您在同一事务中多次访问同一MySQL数据库时,才会发生此问题,在mysql连接url加上如下参数即可,如:
spring.datasource.url = jdbc:mysql://127.0.0.1:3306/xxx?pinGlobalTxToPhysicalConnection=true

Mysql XA事务行为

在这个场景中,虽然是多数据源,但是底层链接的是同一个mysql数据库,所以XA事务行为为,从第一个执行的sql开始(并不是JTA事务begin阶段),生成xid并XA START事务,然后XA END。第二个数据源的sql执行时会判断是否同一个mysql资源,如果是同一个则用刚生成的xid重新XA START RESUME,然后XA END,最终虽然在应用层是两个DataSource,其实最后只会调用XA COMMIT一次。mysql驱动实现的XAResource的start如下:

    public void start(Xid xid, int flags) throws XAException {
        StringBuilder commandBuf = new StringBuilder(MAX_COMMAND_LENGTH);
        commandBuf.append("XA START ");
        appendXid(commandBuf, xid);

        switch (flags) {
            case TMJOIN:
                commandBuf.append(" JOIN");
                break;
            case TMRESUME:
                commandBuf.append(" RESUME");
                break;
            case TMNOFLAGS:
                // no-op
                break;
            default:
                throw new XAException(XAException.XAER_INVAL);
        }
        dispatchCommand(commandBuf.toString());
        this.underlyingConnection.setInGlobalTx(true);
    }

第一次sql执行时,flags=0,走的TMNOFLAGS逻辑,第二次sql执行时,flags=134217728,走的TMRESUME,重新开启事务的逻辑。以上是Mysql XA的真实事务逻辑,但是博主研究下来发现,msyql xa并不支持XA START RESUME这种语句,而且有很多限制《Mysql XA交易限制》,所以在mysql数据库使用XA事务时,最好了解下mysql xa的缺陷

链式事务方案

链式事务不是我首创的叫法,在spring-data-common项目的Transaction包下,已经有一个默认实现ChainedTransactionManager,前文中《深入理解spring的@Transactional工作原理》已经分析了Spring的事务抽象,由PlatformTransactionManager(事务管理器)、TransactionStatus(事务状态)、TransactionDefinition(事务定义)等形态组成,ChainedTransactionManager也是实现了PlatformTransactionManager和TransactionStatus。实现原理也很简单,在ChainedTransactionManager内部维护了事务管理器的集合,通过代理编排真实的事务管理器,在事务开启、提交、回滚时,都分别操作集合里的事务。以达到对多个事务的统一管理。这个方案比较简陋,而且有缺陷,在提交阶段,如果异常不是发生在第一个数据源,那么会存在之前的提交不会回滚,所以在使用ChainedTransactionManager时,尽量把出问题可能性比较大的事务管理器放链的后面(开启事务、提交事务顺序相反)。这里只是抛出了一种新的多数据源事务管理的思路,能用XA尽量用XA管理。

普通的业务默认数据源配置如下:

/**
 * @author: kl @kailing.pub
 * @date: 2020/5/18
 */
@Configuration
@EnableConfigurationProperties({JpaProperties.class, DataSourceProperties.class})
public class DataSourceConfiguration{

    @Primary
    @Bean
    public DataSource dataSource(DataSourceProperties dataSourceProperties){
       return dataSourceProperties.initializeDataSourceBuilder().type(HikariDataSource.class).build();
    }

    @Primary
    @Bean(initMethod = "afterPropertiesSet")
    public LocalContainerEntityManagerFactoryBean entityManagerFactory(JpaProperties jpaProperties, DataSource dataSource, EntityManagerFactoryBuilder factoryBuilder) {
        return factoryBuilder.dataSource(dataSource)
                .packages(Constants.BASE_PACKAGES)
                .properties(jpaProperties.getProperties())
                .persistenceUnit("default")
                .build();
    }

    @Bean
    @Primary
    public EntityManager entityManager(EntityManagerFactory entityManagerFactory){
        //必须使用SharedEntityManagerCreator创建SharedEntityManager实例,否则SimpleJpaRepository中的事务不生效
        return SharedEntityManagerCreator.createSharedEntityManager(entityManagerFactory);
    }

    @Primary
    @Bean
    public PlatformTransactionManager transactionManager(EntityManagerFactory entityManagerFactory){
        JpaTransactionManager txManager = new JpaTransactionManager();
        txManager.setEntityManagerFactory(entityManagerFactory);
        return txManager;
    }
}

sharding-jdbc加密数据源配置如下:

/**
 * @author: kl @kailing.pub
 * @date: 2020/5/18
 */
@Configuration
@EnableConfigurationProperties({JpaProperties.class,SpringBootEncryptRuleConfigurationProperties.class, SpringBootPropertiesConfigurationProperties.class})
public class EncryptDataSourceConfiguration {

    @Bean
    public DataSource encryptDataSource(DataSource dataSource,SpringBootPropertiesConfigurationProperties props,SpringBootEncryptRuleConfigurationProperties encryptRule) throws SQLException {
        return EncryptDataSourceFactory.createDataSource(dataSource, new EncryptRuleConfigurationYamlSwapper().swap(encryptRule), props.getProps());
    }

    @Bean(initMethod = "afterPropertiesSet")
    public LocalContainerEntityManagerFactoryBean encryptEntityManagerFactory(@Qualifier("encryptDataSource") DataSource dataSource,JpaProperties jpaProperties, EntityManagerFactoryBuilder factoryBuilder) throws SQLException {
        return factoryBuilder.dataSource(dataSource)
                .packages(Constants.BASE_PACKAGES)
                .properties(jpaProperties.getProperties())
                .persistenceUnit("encryptPersistenceUnit")
                .build();
    }

    @Bean
    public EntityManager encryptEntityManager(@Qualifier("encryptEntityManagerFactory") EntityManagerFactory entityManagerFactory){
        //必须使用SharedEntityManagerCreator创建SharedEntityManager实例,否则SimpleJpaRepository中的事务不生效
        return SharedEntityManagerCreator.createSharedEntityManager(entityManagerFactory);
    }

    @Bean
    public PlatformTransactionManager chainedTransactionManager(PlatformTransactionManager transactionManager) throws SQLException {
        JpaTransactionManager encryptTransactionManager = new JpaTransactionManager();
        encryptTransactionManager.setEntityManagerFactory(encryptEntityManagerFactory());
        //使用链式事务管理器包装真正的transactionManager、txManager事务
        ChainedTransactionManager chainedTransactionManager = new ChainedTransactionManager(encryptTransactionManager,transactionManager);
        return chainedTransactionManager;
    }
}

使用这种方案,在涉及到多数据源的业务时,需要指定使用哪个事务管理器,如:

    @PersistenceContext(unitName = "encryptPersistenceUnit")
    private EntityManager entityManager;

    @PersistenceContext
    private EntityManager manager;

    @Transactional(transactionManager = "chainedTransactionManager")
    public AccountModel  save(AccountDTO dto){
        AccountModel accountModel = AccountMapper.INSTANCE.dtoTo(dto);

        entityManager.persist(accountModel);
        entityManager.flush();
        AccountModel accountMode2 = AccountMapper.INSTANCE.dtoTo(dto);

        manager.persist(accountMode2);
        manager.flush();

        return accountModel;
    }

结语

综上,对于JPA的多数据源分布式事务处理,JTA的事务管理器经过spring boot的封装已经可以开箱即用了。重点在JPA环境下,需要指定EntityManagerFactory的事务使用JTA事务。另本文分享了一种链式事务编排的方式也可以应用在这种场景,但是特殊的场景下不能保证事务的完整性,所以博主推荐使用JtaTransactionManager,有符合的场景也可以试试ChainedTransactionManager。

作者简介:

独立博客KL博客(http://www.kailing.pub)博主。

查看原文

赞 1 收藏 0 评论 3

kl博主 发布了文章 · 2020-04-03

dubbo升级2.7.4.1平滑迁移到nacos

前言

dubbo是一款非常优秀的服务治理型RPC框架,dubbo的优秀在于,庞大的架构体系、精湛的模块设计、灵活的SPI设计、丰富的组件实现,博主做微服务技术选型考察dubbo时,非常惊叹在那个年代别人就已经能够产出如此优秀的项目,以至于后面每逢别人说想要学习架构设计时,我都会推荐他读读dubbo的代码,学习下dubbo的架构设计原则。常说dubbo不仅仅是一款RPC框架,是因为他的服务治理特性相对于RPC通讯来说更加的突出,这个特性让我在2017年选型的时候果断选择了他,那个时候dubbo官方还没产出spring boot starter,而我们的项目大部分完成了从spring mvc改造到spring boot项目。为了简化开发集成dubbo组件,我们基于dubbo2.5.6版本自研了一套spring-boot-dubbo-starter组件,并且自定义dubbo服务暴露和引入的注解, 自定义了dubbo的配置装载方式。当时没有专业的运维、搭建高可用zk也费资源,为了简单方便少维护一个组件、当时我们直接选了redis(阿里云高可用实例)作为dubbo的注册中心。以上就是我们这次升级dubbo的背景情况

为什么升级到2.7.4.1?

  • 从2.5.6到2.7.x,中间修复非常多的bug,带来了非常多的新特性。
  • 2.5.x版本不在作为一个保留维护的版本,目前主力维护的就2.6.x和2.7.x版本,还有探索版本3.0.也就是说即使2.5.x以后有问题了,官方也不会在修复了。
  • 之所以选择2.7.4.1版本,是因为经过研究了官方issue和关注了dubbo群里的情况后,发现这个版本相对比较稳定,而且官方也推荐升级到这个版本。

为什么迁移注册中心到nacos?

  • 目前redis注册中心虽然经过了趟坑之后《dubbo使用redis注册中心的系列问题》,趋于稳定了,但是因为太小众,使用的人太少导致很多问题并没有暴露出来(在升级的过程中又发现了一个redis注册中心的问题), 如果继续使用redis注册中心,将会一直处在不断自我趟坑的过程中无法自拔。
  • nacos是dubbo官方主推的注册中心项目,虽然现在还在迭代磨合,但是一旦发现问题官方反应还是比较及时的。使用nacos人越来越多,相当于趟坑的人也多了,隐藏的bug就无处可藏了。而且nacos和dubbo有天生的血缘关系, 查看nacos近期的release情况,发现有几个特意修复dubbo注册的问题
  • nacos自带了web管理控制台,可以非常方便的查询dubbo的注册情况,可以作为一个简易的dubbo治理中心来使用

两种升级方案

由于我们目前维护了自己的spring-boot-dubbo-starter,所以在做升级时,我们产生了两种不同的升级方案,并且都做了完整的验证。

方案一:魔改官方的starter组件

为了做到开发侧基本无感知升级到2.7.4.1版本,我们做了两件事情

  • 注解兼容

在做注解兼容时也考虑过两个方案,一个是在自研的starter上做兼容dubbo2.7.4.1的处理,一个是在官方2.7.4.1的starter上兼容我们的处理。后面果断选择了后者,因为dubbo2.7.4.1版本对于我们来说是个黑盒子不知道有哪些改动,正向兼容难度比较大,反向兼容却要容易的多。 我们将原来自研组件里的自定义注解,保留包路径完整的拷贝到官方的starter项目中,然后将 ReferenceAnnotationBeanPostProcessor和ServiceAnnotationBeanPostProcessor从dubbo的spring模块中挪了出来,做了兼容自定义注解的处理。这个地方再次夸下 dubbo的设计,dubbo在捐赠给apache后,包名都改了,为了兼容老的alibaba包下的注解,服务暴露和服务引入都做了非常简易的注解兼容设计。 得益于此,我们在做自定义注解兼容处理时非常轻松就搞定了。

ReferenceAnnotationBeanPostProcessor的构造器传入自定义注解:

    public ReferenceAnnotationBeanPostProcessor() {
        super(AutowiredDubbo.class, Reference.class, com.alibaba.dubbo.config.annotation.Reference.class);
    }

ServiceAnnotationBeanPostProcessor扫描时添加自定义注解支持

        scanner.addIncludeFilter(new AnnotationTypeFilter(Service.class));

        /**
         * Add the compatibility for legacy Dubbo's @Service
         *
         * The issue : https://github.com/apache/dubbo/issues/4330
         * @since 2.7.3
         */
        scanner.addIncludeFilter(new AnnotationTypeFilter(com.alibaba.dubbo.config.annotation.Service.class));
        // 兼容@DubboService注解
        scanner.addIncludeFilter(new AnnotationTypeFilter(DubboService.class));

最后修改DubboAutoConfiguration中的服务暴露和服务引入处理器为我们魔改的实现即可

  • 配置兼容

自研的自定义配置加载以spring.dubbo.打头的,而官方是以dubbo.打头的,区别如下:

自研的配置:
spring.dubbo.application.name = xxx
spring.dubbo.registry.address = xxx
spring.dubbo.protocol.port = -1
官方starter配置
dubbo.application.name = xxx
dubbo.registry.address = xxx
dubbo.protocol.port = -1

为了做到配置兼容,修改了dubbo starter配置加载逻辑,去掉了spring.打头,修改DubboUtils中的filterDubboProperties,如:

    public static SortedMap<String, Object> filterDubboProperties(ConfigurableEnvironment environment) {
        SortedMap<String, Object> dubboProperties = new TreeMap<>();
        Map<String, Object> properties = EnvironmentUtils.extractProperties(environment);
        for (Map.Entry<String, Object> entry : properties.entrySet()) {
            String propertyName = entry.getKey();
            if (propertyName.startsWith(DUBBO_PREFIX + PROPERTY_NAME_SEPARATOR)
                    && entry.getValue() != null) {
                dubboProperties.put(propertyName, entry.getValue().toString());
            }
            if (propertyName.startsWith("spring." + DUBBO_PREFIX + PROPERTY_NAME_SEPARATOR)
                    && entry.getValue() != null) {
                propertyName = propertyName.substring(7);
                dubboProperties.put(propertyName, entry.getValue().toString());
            }
        }
        return Collections.unmodifiableSortedMap(dubboProperties);
    }

最后打包上传到私服,开发只需要升级下jar的版本,配置和代码都不用动就可以升级到2.7.4.1版本的dubbo,可能魔改的地方不止上面贴的这些代码,这里只是引出思路,这个方案到这里结束了,这个方案的优点是对开发比较透明 因为迁移到nacos的步骤是一样的,第二个方案会谈到

方案二:直接使用官方的starter组件-最终采用的方案

最终讨论下来,考虑到内部维护版本,当官方升级时联动升级会比较麻烦,不如,直接痛一次全线改造代码,改造配置,采用了官方的starter直接升级,这样,后面有版本升级不用在投入人力维护自研的和官方的一致。

第一步:引入maven依赖

官方dubbo starter依赖

<dependency>
    <groupId>org.apache.dubbo</groupId>
    <artifactId>dubbo-spring-boot-starter</artifactId>
    <version>2.7.4.1</version>
</dependency>
<dependency>
    <groupId>com.alibaba.nacos</groupId>
    <artifactId>nacos-client</artifactId>
    <version>1.1.3</version>
</dependency>
<dependency>
    <groupId>redis.clients</groupId>
    <artifactId>jedis</artifactId>
    <version>2.9.0</version>
</dependency>
<!-- 注意,引入dubbo官方依赖后,需要同时挪除我们维护的starter包-->

第二步:改造相关的注解

  • 启用dubbo时:@EnableDubbo 改成 @EnableDubbo【org.apache.dubbo.config.spring.context.annotation.EnableDubbo】,并建议添加scanBasePackages包路径,如:@EnableDubbo(scanBasePackages = "cn.keking.service")。提高dubbo暴露服务和引入服务时的扫描速度
  • 服务暴露时:@DubboService 改成 @Service 【org.apache.dubbo.config.annotation.Service】
  • 服务引入时:@AutowiredDubbo 改成 @Reference 【org.apache.dubbo.config.annotation.Reference】,这里需要注意三点:

1、官方的starter默认的服务引入会校验服务是否存在,不存在就抛异常,会影响应用启动,可添加全局的配置,覆盖默认行为,配置如下:dubbo.consumer.check=false

2、自研starter中@AutowiredDubbo 的timeout等参数的单位为秒,官方注解@Reference的参数单位为毫秒,如以前配置为timeout=30, 则在官方starter中只有30毫秒的超时时间。

3、在使用多注册中心时,dubbo会从两个注册中心同时引入服务,虽然你的URL是完全一样的,也会在本地产生两个服务实例,所以,当你的容错模式为广播模式(cluster="Broadcast")或者并行模式(cluster="Forking")时就会产生消费者一次触发,生产者收到两次的问题。而默认的集群策略为 Failover,会正常的走随机负载的方式调用,不会有这种问题。如果有广播模式、或者并行模式的使用,可以通过设置nacos注册中心,只注册不消费。配置方式如下,等所以服务都迁移到nacos上后及时移除这个配置: dubbo.registries.nacos.parameters.subscribe = false

第三步:修改dubbo的配置

去掉spring.前缀即可,注意,升级官方starter后,需要新增一个配置,用来设置redis的连接池大小,官方默认的8个, dubbo.registries.redis.parameters.max.total = 200

下面示例了升级后的dubbo配置:

dubbo.application.name = xxx
dubbo.protocol.port = -1
dubbo.provider.timeout = 300000
dubbo.consumer.check = false
dubbo.registries.nacos.address = nacos://xxx:80
dubbo.registries.redis.address = redis://xxx:6379
dubbo.registries.redis.parameters.max.total = 200

平滑迁移到nacos注册中心

利用dubbo支持多注册中心的功能,分两个阶段完成平滑的从redis迁移到nacos,第一阶段,全线升级修改配置为双注册中心,第二阶段,摘掉redis注册中心完成过渡,配置方式如下:

dubbo.registries.nacos.address=nacos://xxx:80
dubbo.registries.redis.address=redis://xx:6379

注意一些问题

  • 使用redis注册中心时,如果只有一个redis实例,区分环境是通过redis的db来控制的,比如如下配置:

dubbo.registry.parameters.db.index = 2

  • 而nacos注册中心通过命名空间来区分的,具体配置如下:

dubbo.registry.parameters.namespace = xxxxxx

  • 如果是多注册中心配置,注意使用相关注册中心前缀,比如: dubbo.registries.nacos.parameters.namespace=adefa98f-f4d9-4af8-9eb3-e0cab5a39cc7

结语

dubbo升级的方案虽然简单,但是真正升级平滑过渡不是一蹴而就的,期间还是遇到了很多问题,这是一个不断优化稳定的过程。截止目前我们还没全线铺开上生产,只是个别应用推上生产做验证,升级有风险,需要小心又谨慎

查看原文

赞 0 收藏 0 评论 0

认证与成就

  • 获得 17 次点赞
  • 获得 2 枚徽章 获得 0 枚金徽章, 获得 0 枚银徽章, 获得 2 枚铜徽章

擅长技能
编辑

开源项目 & 著作
编辑

  • springboot-mqrpc

    基于rabbitMQ通讯的RPC框架

  • spring-boot-klock-starter

    spring-boot-klock-starter是一个基于redis的分布式锁spring-boot starter组件,使得项目拥有分布式锁能力变得异常简单,支持spring boot,和spirng mvc等spring相关项目

  • kkFileView

    使用spring boot打造文件文档在线预览项目解决方案,支持doc、docx、ppt、pptx、xls、xlsx、zip、rar、mp4,mp3以及众多类文本如txt、html、xml、java、properties、sql、js、md、json、conf、ini、vue、php、py、bat、gitignore等文件在线预览

  • partitionjob

    spring boot上构建spring batch远程分区Step,分布式多机处理,提高spring batch处理时效 批处理是企业级业务系统不可或缺的一部分,spring batch是一个轻量级的综合性批处理框架,可用于开发企业信息系统中那些至关重要的数据批量处理业务.SpringBatch基于POJO和Spring框架,相当容易上手使用,让开发者很容易地访问和利用企业级服务.spring batch是具有高可扩展性的框架,简单的批处理,复杂的大数据批处理作业都可以通过SpringBatch框架来实现。

注册于 2019-08-28
个人主页被 712 人浏览