Overview
In the microservice system built by Spring Cloud, most developers use Feign components that are officially provided for internal service communication. This declarative HTTP client is very simple, convenient and elegant to use, but there is a little When using Feign consumer services, the performance is poorer than Dubbo RPC framework.
Although in the microservice architecture, microservices divided by business are deployed independently and run in their own processes. Communication between microservices is more inclined to use HTTP as a short-answer communication mechanism, and REST APIs are used in most cases. This communication method is very simple and efficient, and has nothing to do with the development platform and language, but under normal circumstances, HTTP does not enable the KeepAlive function, that is, the current connection is a short connection. The shortcoming of the short connection is that each request requires a TCP connection. , Which makes its efficiency quite low.
It is a very good thing to provide REST API services externally, but if the internal calls are also using HTTP calls, the performance will appear to be low. The Feign component that Spring Cloud uses by default for internal service calls is the HTTP protocol used for calls. At this time, if we use RPC calls for internal services and REST API externally, it will be a very good choice. It just so happens that Dubbo Spring Cloud gave us this choice.
The above content is taken from the official website.
Here I think there is another point that needs to be considered. Many companies have built a lot of low-level microservices based on dubbo in the early days. It is relatively troublesome to use the cloud architecture for migration. It is much easier if you can directly integrate dubbo in the cloud. Up.
In the previous article, we have implemented the use of feign to call Account-Serviice from Order-service. In this chapter, we will implement the use of dubbo to call Account-Dubbo, and finally use JMeter to perform performance testing on the interface to see the performance gap between the two.
Realize Dubbo producer
-
Establish service module in the project
account-dubbo, theaccount-dubbore-establishment of two modulesdubbo-apianddubbo-providermodules. -
In
dubbo-providerthe pom file, add the key-dependent Dubbo Spring Cloud's.
<dependency>
<groupId>com.alibaba.cloud</groupId>
<artifactId>spring-cloud-starter-dubbo</artifactId>
</dependency>
<dependency>
<groupId>com.alibaba.cloud</groupId>
<artifactId>spring-cloud-starter-alibaba-nacos-discovery</artifactId>
</dependency>
"Note: Dubbo's native jar cannot be used directly here, and the nacos registry needs to be introduced, and dubbo needs to be registered to the springcloud registry"
-
Modify
dubbo-providerthe configuration file of the projectapplication.properties
spring.cloud.nacos.discovery.server-addr = 10.0.23.48:8848
dubbo.application.id = account-dubbo
dubbo.protocol.name = dubbo
dubbo.protocol.port = 20881
dubbo.scan.base-packages = com.javadaily.dubbo.service
dubbo.registry.address = spring-cloud://localhost
spring.application.name = account-dubbo
dubbo.registry.check = false
dubbo.consumer.check = false
dubbo.cloud.subscribed-services = order-service
As used herein dubbo.registry.addressthe dubbo registered to the registry of springcloud.
-
In the
dubbo-apiAdd service interface, to the back of the performance tests using us as Account-Service interfaces.
public interface AccountService {
AccountDTO getByCode(String accountCode);
}
-
In
dubbo-providerrealization of this interface (mybatis the configuration a little ...)
@Service
public class AccountServiceImpl implements AccountService {
@Autowired
private AccountMapper accountMapper;
@Override
public AccountDTO getByCode(String accountCode) {
AccountDTO accountDTO = new AccountDTO();
Account account = accountMapper.selectByCode(accountCode);
BeanUtils.copyProperties(account,accountDTO);
return accountDTO;
}
}
Note that the @Serviceannotation using org.apache.dubbo.config.annotation.Servicenot Spring Service Notes native.
-
In
dubbo-provideradding the main startup class, and add aEnableDubbocomment
@SpringBootApplication
@EnableDubbo
public class AccountDubboApplication {
public static void main(String[] args) {
SpringApplication.run(AccountDubboApplication.class, args);
}
}
-
Start the dubbo service and check whether the registration is normal in the registry.
Order-Service consumer modification
-
Introduce dubbo related dependencies
<!--dubbo-->
<dependency>
<groupId>com.alibaba.cloud</groupId>
<artifactId>spring-cloud-starter-dubbo</artifactId>
</dependency>
<dependency>
<groupId>com.jianzh5.cloud</groupId>
<artifactId>dubbo-api</artifactId>
<version>1.0.0</version>
</dependency>
-
Modify the consumer configuration file and increase the configuration parameters of dubbo
dubbo:
registry:
address: spring-cloud://localhost
cloud:
subscribed-services: account-dubbo
consumer:
check: false
Because Order-Servicedo not need to provide external RPC service so there is only need to configure the registry to dubbo.
By dubbo.cloud.subscribed-servicesthe configuration of the service creator id, default is * that is registered in all, this option is the recommended configuration.
-
Modify the consumption logic and use dubbo to call.
@Slf4j
@RestController
public class FeignController {
@Reference
private AccountService accountService;
@GetMapping("/order/getAccount/{accountCode}")
public ResultData<AccountDTO> getAccount(@PathVariable String accountCode){
AccountDTO accountDTO = accountService.getByCode(accountCode);
return ResultData.success(accountDTO);
}
}
By org.apache.dubbo.config.annotation.Referenceintroducing dubbo the service.
Through the above steps, we have completed the integration of SpringCloud and Dubbo. You can test it yourself. Next we look at the performance difference between the two.
Performance Testing
The test effect is tested on the original poster's laptop, the effect difference will be more obvious on the high configuration.
Configuration: Intel Core i5-7200U CPU @ 2.50GHz 2.70GHz 6-core 16G memory
Test tool: JMeter5.1
Number of threads: 1000
Ramp-Up: 10
dubbo call effect
| Average response time | Throughput | Minimum response time | Maximum response time |
|---|---|---|---|
| 488ms | 95.8/sec | 16ms | 2970ms |
feign call effect
| Average response time | Throughput | Minimum response time | Maximum response time |
|---|---|---|---|
| 3213ms | 75.1/sec | 108ms | 6097ms |
From the above test results, we can see the performance gap between the two. Feign's performance is significantly behind dubbo. For applications that pursue performance, it is recommended to use dubbo for RPC calls.
If this article is helpful to you,
Don't forget to come up with a triple link: like, repost, and comment. See you next time!
Summary of SpringCloud aliabab series: