Shulou(Shulou.com)06/01 Report--

Most people do not understand the knowledge points of this article "nacos+springboot+dubbo2.7.3 unified approach to handling exceptions", so the editor summarizes the following, detailed content, clear steps, and has a certain reference value. I hope you can get something after reading this article. Let's take a look at this "nacos+springboot+dubbo2.7.3 unified approach to handling exceptions" article.

1. Why throw an exception?

It is easy to trace the source of the exception between different development teams and the need to locate the problem.

Often the architecture in actual development looks like this:

Dubbo micro-service architecture diagram

Different layers of developers are different people or different waves of people.

The stateless API layer (a set of Tomcat API exposures to the Nginx Web layer) is a group of development teams

The Dubbo layer of microservices is another group of development teams.

After debugging, testing, and launching, we often have all kinds of Exception. At this time, these different development teams will wrangle and fight with each other, and everyone will be busy locating the layer at which the Exception occurs, and even need to trace the point where the Exception occurs (stackTrace).

The problem of database transaction consistency in the Service layer must throw an exception

We all know that the Service layer in spring must throw Runtime Exception, otherwise the methods of the Service layer will not be rolled back if there are modifications involving the database.

two。 Give a solution

In fact, there are only two real solutions:

Provider can throw RuntimeException directly to the remote consumer layer.

The provider side uniformly packages all the Exception, returns json message like message:xxx,code:500,data {xxx:xxx,xxx:xxx} to the consumer side, and records "logger.error" on the provider side.

In this paper, both of these two implementations have been implemented, so let's talk about it in a direct show me the code way.

3. Illustration of two examples of throwing exceptions

Environment building

Nacos1.1.4

We don't use dubbo admin here because dubbo admin is too old and inconvenient to use and lacks many of the basic functions needed to manage microservices. And dubbo has separated dubbo admin from its main project since 2.6.At the same time dubbo2.6 has started to support nacos registry.

At present, nacos is the most convenient, efficient and powerful micro-service discovery component (and even supports spring cloud).

The download address is here (please mark): the latest download address of Ali nacos

Decompress directly after download, and then configure nacos

By editing the application.properties file, we connect the nacos automatic service discovery manager to the mysql on our development environment.

# springspring.datasource.platform=mysqlserver.contextPath=/nacosserver.servlet.contextPath=/nacosserver.port=8848db.num=1db.url.0=jdbc:mysql://192.168.56.101:3306/nacos?useUnicode=true&characterEncoding=utf-8&useSSL=falsedb.user=nacosdb.password=111111

Double-click directly after matching: startup.cmd to start nacos

You can log in using nacos/nacos in the login interface.

After logging in, seeing the nacos administration interface shows that the nacos configuration and startup are successful. Next we are going to start writing the provider side and the consumer side of dubbo.

Construction of dubbo project

Nacos-parent project

I have put the whole project on git. Please mark the address here: nacos-dubbo-demo

The dependency structure of the project is as follows:

As there are not many projects combining dubbo and springboot, and many online blogs are full of random copying and code without verification, most of the projects cobbled together by netizens through online words and phrases are very difficult to run locally, either maven package conflicts or lack of this and that package. The parent pom file of the project is given below.

4.0.0 org.sky.demo nacos-parent 0.0.1-SNAPSHOT pom Demo project for Spring Boot Dubbo Nacos 1.8 1.5.15.RELEASE 2.7.3 4.0.1 2.8.0 1.1.20 27.0.1-jre 1.2.59 2.7.3 1.1.4 5.1.46 3.4.2 1.8.13 0.0.1-SNAPSHOT 0.0.1 -SNAPSHOT ${java.version} ${java.version} 3.8.1 3.2.3 3.1.2 UTF-8 UTF-8 Org.springframework.boot spring-boot-starter-web ${spring-boot.version} org.springframework.boot spring -boot-dependencies ${spring-boot.version} pom import org.apache.dubbo dubbo -spring-boot-starter ${dubbo.version} org.slf4j slf4j-log4j12 Org.apache.dubbo dubbo ${dubbo.version} Org.apache.curator curator-framework ${curator-framework.version} org .apache.curator curator-recipes ${curator-recipes.version} mysql mysql-connector-java ${mysql-connector-java.version} com.alibaba druid ${druid.version} Com.lmax disruptor ${disruptor.version} com.google.guava guava ${guava.version} com.alibaba fastjson ${fastjson.version} Org.apache.dubbo dubbo-registry-nacos ${dubbo-registry-nacos.version} com.alibaba.nacos Nacos-client ${nacos-client.version} org.aspectj aspectjweaver ${aspectj.version} Org.apache.maven.plugins maven-compiler-plugin ${compiler.plugin.version} ${java.version} ${java.version} org.apache.maven.plugins Maven-war-plugin ${war.plugin.version} org.apache.maven.plugins maven-jar-plugin ${jar.plugin.version}

Demonstration database (mySQL5.7) table statement

CREATE TABLE `t_ product` (`product_ id` int (11) NOT NULL AUTO_INCREMENT, `product_ name` varchar (45) DEFAULT NULL, PRIMARY KEY (`product_ id`)); CREATE TABLE `tstock` (`stock_ id` int (11) NOT NULL AUTO_INCREMENT, `stock`int (11) DEFAULT NULL, `product_ id` int (11) NOT NULL, PRIMARY KEY (`stock_ id`))

It creates two tables, the t _ produce table and the t _ stock table. These two tables will be used to demonstrate how to handle rollback scenarios in dubbo provider when you encounter Exception for database consistency inserts.

Construction instructions for nacos-service Project

Go to pom.xml first (it's important that the dependency here is the complete configuration of the correct springboot+dubbo+nacos client)

4.0.0 org.sky.demo nacos-service 0.0.1-SNAPSHOT nacos-service Servicer Demo project for Spring Boot dubbo nacos org.sky.demo nacos-parent 0.0.1-SNAPSHOT org.springframework .boot spring-boot-starter-jdbc org.springframework.boot spring-boot-starter-logging Org.apache.dubbo dubbo org.apache.curator curator-framework Org.apache.curator curator-recipes mysql mysql-connector-java com.alibaba druid Org.springframework.boot spring-boot-starter-test test org.spockframework spock-core test Org.spockframework spock-spring org.springframework.boot spring-boot-configuration-processor true org .springframework.boot spring-boot-starter-data-redis org.springframework.boot spring-boot-starter-log4j2 org.springframework.boot spring-boot -starter-web org.springframework.boot spring-boot-starter-logging Org.springframework.boot spring-boot-starter-tomcat org.aspectj aspectjweaver Com.lmax disruptor redis.clients jedis com.google.guava guava Com.alibaba fastjson org.apache.dubbo dubbo-registry-nacos com.alibaba.nacos Nacos-client org.sky.demo skycommon ${skycommon.version} src/main/java src/test/java Org.springframework.boot spring-boot-maven-plugin src/main/resources Src/main/webapp META-INF/resources * / * * Src/main/resources true application.properties application-$ {profileActive} .properties

Then we set the contents of the application.properties file

Part of the configuration of dubbo here is set relative to the 4C CPU,4GB memory of my virtual simulation environment. For more parameters, please refer to the official dubbo documentation.

Spring.datasource.type=com.alibaba.druid.pool.DruidDataSourcespring.datasource.driverClassName=com.mysql.jdbc.Driverspring.datasource.url=jdbc:mysql://192.168.56.101:3306/mk?useUnicode=true&characterEncoding=utf-8&useSSL=falsespring.datasource.username=mkspring.datasource.password=111111 server.port=8080server.tomcat.max-connections=300server.tomcat.max-threads=300server.tomcat.uri-encoding=UTF-8server.tomcat.max-http-post-size=0 # Dubbo provider configurationdubbo.application.name=nacos-service-demodubbo.registry.protocol=dubbodubbo.registry.address=nacos://127.0.0 .1: 8848dubbo.protocol.name=dubbodubbo.protocol.port=20880dubbo.protocol.threads=200dubbo.protocol.queues=100dubbo.protocol.threadpool=cacheddubbo.provider.retries = 3dubbo.provider.threadpool = cacheddubbo.provider.threads = 200dubbo.provider.connections = 100dubbo.scan.base-packages=org.sky.service logging.config=classpath:log4j2.xml

We can see that to connect dubbo to nacos, you only need to introduce the

Org.apache.dubbo dubbo-registry-nacos com.alibaba.nacos nacos-client org.apache.dubbo dubbo

And in the application.properties file, the corresponding dubbo protocol still uses dubbo, this is because nacos-registry has been brought into dubbo2.6, so you must set dubbo.registry.address to point to your local nacos startup instance (default is port 8848).

Dubbo.registry.protocol=dubbodubbo.registry.address=nacos://127.0.0.1:8848

Startup code for springboot, Application.java

Package org.sky; import org.apache.dubbo.config.spring.context.annotation.EnableDubbo;import org.springframework.boot.SpringApplication;import org.springframework.boot.autoconfigure.EnableAutoConfiguration;import org.springframework.boot.autoconfigure.SpringBootApplication;import org.springframework.context.annotation.ComponentScan;import org.springframework.transaction.annotation.EnableTransactionManagement EnableDubbo@EnableAutoConfiguration@ComponentScan (basePackages = {"org.sky"}) @ EnableTransactionManagement public class Application {public static void main (String [] args) {SpringApplication.run (Application.class, args);}}

There are two important notes

@ EnableDubbo declares that automatic annotations for dubbo are enabled for this project

@ EnableTransactionManagement declares that the project will use database transactions

Connect the project to the database

We use druid as the connection pool for the database.

Package org.sky.config; import javax.sql.DataSource; import org.springframework.beans.factory.annotation.Value;import org.springframework.boot.autoconfigure.EnableAutoConfiguration;import org.springframework.boot.context.properties.ConfigurationProperties;import org.springframework.boot.web.servlet.FilterRegistrationBean;import org.springframework.boot.web.servlet.ServletRegistrationBean;import org.springframework.context.annotation.Bean;import org.springframework.context.annotation.Configuration;import org.springframework.context.annotation.Primary; import com.alibaba.druid.pool.DruidDataSource Import com.alibaba.druid.support.http.StatViewServlet;import com.alibaba.druid.support.http.WebStatFilter; @ Configuration@EnableAutoConfigurationpublic class DruidConfig {@ ConfigurationProperties (prefix = "spring.datasource") @ Bean public DruidDataSource dataSource () {return new DruidDataSource ()}}

Make a custom global Exception,DemoRpcRunTimeException

Place it in the common project

Package org.sky.exception; import java.io.Serializable; public class DemoRpcRunTimeException extends RuntimeException implements Serializable {public DemoRpcRunTimeException () {} public DemoRpcRunTimeException (String msg) {super (msg);} public DemoRpcRunTimeException (Throwable cause) {super (cause);} public DemoRpcRunTimeException (String message, Throwable cause) {super (message, cause) }}

Make an AOP, DemoRpcRuntimeExceptionHandler

Used to wrap custom exceptions, which are located in the nacos-service project, and will be injected in the form of AOP when done.

Package org.sky.config; import org.apache.logging.log4j.LogManager;import org.apache.logging.log4j.Logger;import org.aspectj.lang.annotation.AfterThrowing;import org.aspectj.lang.annotation.Aspect;import org.sky.exception.DemoRpcRunTimeException;import org.springframework.stereotype.Component; @ Aspect@Componentpublic class DemoRpcRuntimeExceptionHandler {protected Logger logger = LogManager.getLogger (this.getClass ()) / * * RuntimeException Unified processor at service layer * can subpackage RuntimeException as RpcRuntimeException to the caller for processing or self-processing * * @ param exception * / @ AfterThrowing (throwing = "exception", pointcut = "execution (* org.sky.service.*.* (..)") Public void afterThrow (Throwable exception) {if (exception instanceof RuntimeException) {logger.error ("DemoRpcRuntimeExceptionHandler side- > exception occured:" + exception.getMessage (), exception); throw new DemoRpcRunTimeException (exception) } / / logger.error ("DemoRpcRuntimeExceptionHandler side- > exception occured:" + / / exception.getMessage (), exception);}

Start to enter the core provider Service side of the production.

ProductService interface

We put it in the common project so that the consumer project can find the interface name through the nacos registry and then call the remote xxxServiceImpl class that implements the service logic through spring's invoke.

Package org.sky.service; import org.sky.exception.DemoRpcRunTimeException;import org.sky.platform.util.DubboResponse;import org.sky.vo.ProductVO; public interface ProductService {public DubboResponse addProductAndStock (ProductVO prod) throws DemoRpcRunTimeException;}

Specific business logic implementation class, ProductServiceImpl

This class does one thing:

1) insert t _ product table data

2) insert t _ stocktable data

When inserting two tables, the entire insert transaction will be rolled back as long as there is a little error, otherwise it will succeed. What we need to pay attention to here is:

Springboot service will not roll back until it receives the RuntimeException.

To pass RuntimeException remotely from provider to the consumer side, including stackTrace to the consumer side, the exception must be serializable

The service method exposed as dubbo provider service must be annotated with @ Service, which is not the service of spring annotation but the service of ali dubbo, and has become the org.apache.dubbo package since 2.7.3. It cooperates with @ EnableDubbo in springboot's main startup file to start. After startup, it will search all classes under this path for @ Service annotations through the path indicated in dubbo.scan.base-packages in application.properties, and if so, register it in nacos through nacos-registry.

ProductServiceImpl.java

Package org.sky.service; import java.sql.Connection;import java.sql.PreparedStatement;import java.sql.SQLException; import org.apache.dubbo.config.annotation.Service;import org.sky.exception.DemoRpcRunTimeException;import org.sky.platform.util.DubboResponse;import org.sky.vo.ProductVO;import org.springframework.beans.factory.annotation.Autowired;import org.springframework.http.HttpStatus;import org.springframework.jdbc.core.JdbcTemplate;import org.springframework.jdbc.core.PreparedStatementCreator;import org.springframework.jdbc.support.GeneratedKeyHolder Import org.springframework.jdbc.support.KeyHolder;import org.springframework.transaction.annotation.Transactional; @ Service (version = "1.0.0", interfaceClass = ProductService.class, timeout = 120000) public class ProductServiceImpl extends BaseService implements ProductService {@ Autowired JdbcTemplate jdbcTemplate; @ Override @ Transactional public DubboResponse addProductAndStock (ProductVO prod) throws DemoRpcRunTimeException {DubboResponse response = null; int newProdId = 0 String prodSql = "insert into t_product (product_name) values (?)"; String stockSql = "insert into t_stock (product_id,stock) values"; try {if (prod! = null) {KeyHolder keyHolder = new GeneratedKeyHolder () JdbcTemplate.update (new PreparedStatementCreator () {@ Override public PreparedStatement createPreparedStatement (Connection connection) throws SQLException {PreparedStatement ps = connection.prepareStatement (prodSql, new String [] {"id"}) Ps.setString (1, prod.getProductName ()); return ps;}}, keyHolder) NewProdId = keyHolder.getKey (). IntValue (); logger.info ("= > insert into t_product with product_id:" + newProdId); if (newProdId > 0) {jdbcTemplate.update (stockSql, newProdId, prod.getStock ()) Logger.info ("= > insert into t_stock with successful"); ProductVO returnData = new ProductVO (); returnData.setProductId (newProdId); returnData.setProductName (prod.getProductName ()) ReturnData.setStock (prod.getStock ()); response = new DubboResponse (HttpStatus.OK.value (), "success", returnData); / / throw new Exception ("Mk throwed exception to enforce rollback [insert into t_stock]") Return response;}} else {throw new DemoRpcRunTimeException ("error occured on ProductVO is null") } catch (Exception e) {logger.error ("error occured on Dubbo Service Side:" + e.getMessage (), e); throw new DemoRpcRunTimeException ("error occured on Dubbo Service Side:" + e.getMessage (), e);} return response;}}

This class is currently in a normal state, so let's first call a normal provider to the service side and then demonstrate how to pass the exception remotely to the server side.

Construction instructions for nacos-consumer Project

Go to pom.xml first.

4.0.0 org.sky.demo nacos-consumer 0.0.1-SNAPSHOT nacos-service Consumer Demo project for Spring Boot dubbo nacos org.sky.demo nacos-parent 0.0.1-SNAPSHOT org.apache .dubbo dubbo org.apache.curator curator-framework org.apache.curator curator-recipes Org.springframework.boot spring-boot-starter-test test org.spockframework spock-core test Org.spockframework spock-spring org.springframework.boot spring-boot-configuration-processor true org.springframework .boot spring-boot-starter-log4j2 org.springframework.boot spring-boot-starter-web org.springframework .boot spring-boot-starter-logging com.lmax disruptor Com.google.guava guava com.alibaba fastjson org.apache.dubbo dubbo-registry-nacos Com.alibaba.nacos nacos-client org.aspectj aspectjweaver Org.sky.demo skycommon ${skycommon.version} src/main/java src/test/java org.springframework.boot Spring-boot-maven-plugin src/main/resources src / main/webapp META-INF/resources * / * Src/main/resources true application.properties application-$ {profileActive} .properties

Application.properties on the nacos-consumer side

Server.port=8082server.tomcat.max-connections=50server.tomcat.max-threads=50server.tomcat.uri-encoding=UTF-8server.tomcat.max-http-post-size=0 # Dubbo provider configurationdubbo.application.name=nacos-consumerdubbo.registry.address=nacos://127.0.0.1:8848#dubbo.consumer.time=120000 logging.config=classpath:log4j2.xml

Similarly, the server side also needs to connect to the local nacos instance.

Another thing to say is not to do something like dubbo communication timeout or personalized dubbo parameter settings on the consumer side. Because dubbo has three core parameter sets, provider, protocol, and consumer. The settings made in consumer will override the provider settings due to the priority of these three. If each consumer makes its own personalized settings in a large-scale micro-service development scenario, it is not conducive to centralized and unified control of system performance globally, so it requires the company's architects to provide unified control over these specifications, and be sure to avoid setting some parameters that should belong to the central (provider) side on the consumer side.

Application.java on the consumer side

Package org.sky; import org.apache.dubbo.config.spring.context.annotation.EnableDubbo;import org.springframework.boot.SpringApplication;import org.springframework.boot.autoconfigure.EnableAutoConfiguration;import org.springframework.boot.autoconfigure.SpringBootApplication;import org.springframework.context.annotation.ComponentScan; @ EnableDubbo@ComponentScan (basePackages = {"org.sky"}) @ EnableAutoConfigurationpublic class Application {public static void main (String [] args) {SpringApplication.run (Application.class, args);}}

It is not much different from the naco-service on the provider side, pay attention to @ EnableDubbo, otherwise spring will not register the consumer with the nacos registry when the project starts.

Controller on the consumer side

This consumer is exactly the stateless API layer in my first picture, and there's going to be a bunch of tomcat/netty/jboss things like that, and all they do is route API and return it to clients (mobile phones, web pages, Mini Program) in json format. This layer is not going to deal with DB, NOSQL, caching, and so on. What they need to do is to call the dubbo service of the "back-end" microservice, so we basically focus on the controller in spring on this side.

In order for the provider side to call the service method on the provider side, the @ Reference annotation must be added to the injection, so that the consumer of the dubbos will know which provider's service (residual root-stub) (addressing function) when registering in the "registry", such as nacos.

Package org.sky.controller; import org.springframework.web.bind.annotation.RestController; import com.alibaba.fastjson.JSON;import com.alibaba.fastjson.JSONObject; import org.springframework.web.bind.annotation.RequestMapping; import java.util.ArrayList;import java.util.HashMap;import java.util.List;import java.util.Map; import javax.annotation.Resource; import org.apache.dubbo.config.annotation.Reference;import org.apache.logging.log4j.LogManager;import org.apache.logging.log4j.Logger;import org.sky.platform.util.AppConstants Import org.sky.platform.util.DubboResponse;import org.sky.platform.util.ResponseResult;import org.sky.platform.util.ResponseStatusEnum;import org.sky.platform.util.ResponseUtil;import org.sky.service.HelloNacosService;import org.sky.service.ProductService;import org.sky.vo.ProductVO;import org.springframework.http.HttpHeaders;import org.springframework.http.HttpStatus;import org.springframework.http.MediaType;import org.springframework.http.ResponseEntity;import org.springframework.web.bind.annotation.PostMapping Import org.springframework.web.bind.annotation.RequestBody; @ RestController@RequestMapping ("nacosconsumer") public class DemoDubboConsumer extends BaseController {@ Reference (version = "1.0.0", loadbalance= "roundrobin") private HelloNacosService helloNacosService; @ Reference (version = "1.0.0") private ProductService productService @ PostMapping (value = "/ sayHello", produces = "application/json") public ResponseEntity sayHello (@ RequestBody String params) throws Exception {ResponseEntity response; HttpHeaders headers = new HttpHeaders (); headers.setContentType (MediaType.APPLICATION_JSON_UTF8); Map resultMap = new HashMap (); JSONObject requestJsonObj = JSON.parseObject (params) Try {String name = getHelloNameFromJson (requestJsonObj); String answer= helloNacosService.sayHello (name); logger.info ("answer= >" + answer); Map result = new HashMap (); result.put ("result", answer) String resultStr = JSON.toJSONString (result); response = new ResponseEntity (resultStr, headers, HttpStatus.OK);} catch (Exception e) {logger.error ("dubbo-clinet has an exception occured:" + e.getMessage (), e); String resultStr = e.getMessage () Response = new ResponseEntity (resultStr, headers, HttpStatus.EXPECTATION_FAILED);} return response;} @ PostMapping (value = "/ addProductAndStock", produces = "application/json") public ResponseEntity addProduct (@ RequestBody String params) throws Exception {ResponseEntity response = null; DubboResponse dubboResponse; String returnResultStr HttpHeaders headers = new HttpHeaders (); headers.setContentType (MediaType.APPLICATION_JSON_UTF8); JSONObject requestJsonObj = JSON.parseObject (params); Map result = new HashMap (); try {ProductVO inputProductPara = getProductFromJson (requestJsonObj); dubboResponse = productService.addProductAndStock (inputProductPara) ProductVO returnData = dubboResponse.getData (); if (returnData! = null & & dubboResponse.getCode () = HttpStatus.OK.value ()) {result.put ("code", HttpStatus.OK.value ()); result.put ("message", "add a new product successfully") Result.put ("productid", returnData.getProductId ()); result.put ("productname", returnData.getProductName ()); result.put ("stock", returnData.getStock ()); returnResultStr = JSON.toJSONString (result) Response = new ResponseEntity (returnResultStr, headers, HttpStatus.OK);} else {result.put ("message", "dubbo service ProductService get nullpoint exception"); returnResultStr = JSON.toJSONString (result) Response = new ResponseEntity (returnResultStr, headers, HttpStatus.EXPECTATION_FAILED);}} catch (Exception e) {logger.error ("add a new product with error:" + e.getMessage (), e) Result.put ("message", "add a new product with error:" + e.getMessage ()); returnResultStr = JSON.toJSONString (result); response = new ResponseEntity (returnResultStr, headers, HttpStatus.EXPECTATION_FAILED);} return response } private String getHelloNameFromJson (JSONObject requestObj) {String helloName = requestObj.getString ("name"); return helloName;} private ProductVO getProductFromJson (JSONObject requestObj) {String productName = requestObj.getString ("productname"); int stock = requestObj.getIntValue ("stock"); ProductVO prod = new ProductVO () Prod.setProductName (productName); prod.setStock (stock); return prod;}}

This consumer is quite simple, directly calling dubbo through the remote interface to get a return.

Running example

Make sure our nacos1.1.4 is running there.

Then run nacos-service 's Application.java and then nacos-consumer 's Application.java

Nacos-service running example:

Nacos-consumer running example:

Then we go to the nacos management interface to check, and we can see that both provider and consumer have registered successfully.

Then we use postman to make a json request to consumer

The result is returned as follows

Take a look at the database.

This shows that our dubbo+nacos build is fully operational, and then we will demonstrate the throwing of two kinds of Exception.

Type 1: throw RuntimeException directly from the provider side to the processor side

On the provider side, we make a small modification to ProductServiceImpl as follows:

We wrote a sentence:

Throw new Exception ("Mk throwed exception to enforce rollback [insert into t_stock]")

As we said earlier, the RuntimeException must be thrown in the service on the provider side to make the database transaction rollback, but we don't have to worry. Remember that we have injected an aop interceptor called "DemoRpcRuntimeExceptionHandler" into the nacos-service?

Its function is to stop all Exception and turn it into RuntimeException.

OK, let's add this sentence and re-run nacose-service and nacos-consumer in turn. Then we also access http://localhost:8082/nacosconsumer/addProductAndStock through postman, and then we use the new product name, and the message in the post request body is as follows:

{"productname": "coffee", "stock": 10000}

Look, what appears directly in response after our request has passed?

Let's take a look at the log on the nacos-service side. This is a log we manually threw on the provider side:

Looking at the log on the nacos-consumer side, we can see that the exception on the provider side and even its stackTrace information have been passed to the provider side:

In this way, the developer on the client side will see the error and go to the dubbo development team to yell, "Hey, there is a bug in production. You see, this is what your provider side threw out. Change it!"

To ensure that our ExceptionHandler interception is successful, let's look at the database side:

The t_product table does not have a record inserted into coffee

The t_stock table also does not insert the inventory of the relevant coffee.

This shows that Exception is indeed converted to RuntimeException and captured by the spring framework and then rolled back.

Type 2: pack all the Exception into a json return message without outputting specific exception information to the client.

We want to wrap the Exception on the provider side into a json message like this:

{"message": "exception", "code": "500,000", "add new product failed", "productid": xxx, "productname": xxx, "stock": xxx}

Turn to:

The abnormal stackTrace is recorded on the provider side in log mode, and if something goes wrong, the developers on the provider side can query and locate the problem through the log.

Why do you still do this?

Very simple, because stackTrace is an exception traceability, the call to the jvm stack information, this is a "very heavy" task. We throw a bunch of exception Exception back and forth through provider and consumer. Originally, we use dubbo to do micro-services, to deal with large-scale concurrent requests, and to make the system flexible and highly redundant. You are still using such a large amount of stackTrace to pass around at both ends, plus time serialization and deserialization, which increases the overhead of the system, doesn't it?

Next, directly show me the code, add an aop called "ServiceExceptionHandler" at the org.sky.config of nacos-service. The code is as follows:

Package org.sky.config; import org.apache.logging.log4j.LogManager;import org.apache.logging.log4j.Logger;import org.aspectj.lang.ProceedingJoinPoint;import org.aspectj.lang.annotation.Around;import org.aspectj.lang.annotation.Aspect;import org.aspectj.lang.annotation.Pointcut;import org.sky.platform.util.DubboResponse;import org.springframework.stereotype.Component; import com.google.common.base.Throwables; @ Component@Aspectpublic class ServiceExceptionHandler {protected Logger logger = LogManager.getLogger (this.getClass ()) / * * return Service * / @ Pointcut of type Response (value = "execution (* org.sky.service.*.* (..)") Private void servicePointcut () {} / * * any method that holds @ Transactional annotations * / @ Pointcut (value = "@ annotation (org.springframework.transaction.annotation.Transactional)") private void transactionalPointcut () {} / * exception handling section wraps the exception as Response Avoid dubbo packaging * * @ param pjp processing point * @ return Object * / @ Around ("servicePointcut () & &! transactionalPointcut ()") public Object doAround (ProceedingJoinPoint pjp) {Object [] args = pjp.getArgs () Try {return pjp.proceed ();} catch (Exception e) {processException (pjp, args, e); return DubboResponse.error ("exception occured on dubbo service side:" + e.getMessage ()) } catch (Throwable throwable) {processException (pjp, args, throwable); return DubboResponse.error ("exception occured on dubbo service side:" + throwable.getMessage ()) }} / * * any method exception handling aspect that holds @ Transactional annotation converts the custom business exception to RuntimeException: * 1. Avoid the packaging of dubbo, so that customer can get message 2. Throw RuntimeException so that the transaction can roll back other exceptions correctly without handling * * @ param pjp processing point * @ return Object * / @ Around ("servicePointcut () & & transactionalPointcut ()") public Object doTransactionalAround (ProceedingJoinPoint pjp) throws Throwable {try {return pjp.proceed () } catch (Exception e) {Object [] args = pjp.getArgs (); / / dubbo prints the exception catch, so processException (pjp, args, e) is not printed here. / / logger.error ("service with @ Transactional exception occured on dubbo service / / side:" + e.getMessage (), e); throw new RuntimeException (e.getMessage (), e) }} / * handle exception * * @ param joinPoint pointcut * @ param args parameter * @ param throwable exception * / private void processException (final ProceedingJoinPoint joinPoint, final Object [] args, Throwable throwable) {String inputParam = "" If (args! = null & & args.length > 0) {StringBuilder sb = new StringBuilder (); for (Object arg: args) {sb.append (","); sb.append (arg) } inputParam = sb.toString (). Substring (1);} logger.error ("\ nmethod: {}\ ninput parameter: {}\ nError message: {}", joinPoint.toLongString (), inputParam, Throwables.getStackTraceAsString (throwable));}}

Its function is:

Use a request body called DubboResponse to return all Exception to the service message on the provider side.

If there is an error on the provider side, the wrong system code and system message are also "packaged" in the DubboResponse.

Wait, wait. Something's wrong! It's not all over here. Why?

Everything Exception? In this way, isn't there no Exception thrown in the Service layer after the package? If the Service method involves how the database transaction is rolled back when the database operation does not throw RuntimeException?

So we have a paragraph in this handler class that is used to throw "RuntimeException" to all Service methods with @ Transactional annotations when they go wrong, and return them to the caller as DubboResponse for the rest (such as the uniform wrapper for exceptions to non-transactional Service methods):

@ Around ("servicePointcut () & &! transactionalPointcut ()") public Object doAround (ProceedingJoinPoint pjp) {Object [] args = pjp.getArgs (); try {return pjp.proceed ();} catch (Exception e) {processException (pjp, args, e) Return DubboResponse.error ("exception occured on dubbo service side:" + e.getMessage ());} catch (Throwable throwable) {processException (pjp, args, throwable); return DubboResponse.error ("exception occured on dubbo service side:" + throwable.getMessage ());}}

All right, then let's restart our system now, and let's look at the following running example.

Wait!

Forget one thing, below I give the structure of ProductVO and DubboResponse in the "common" project. I don't like to "hide" when I write a blog post.

ProductVO.java

Package org.sky.vo; import java.io.Serializable; public class ProductVO implements Serializable {private int stock = 0; public int getStock () {return stock;} public void setStock (int stock) {this.stock = stock;} public String getProductName () {return productName } public int getProductId () {return productId;} public void setProductId (int productId) {this.productId = productId;} public void setProductName (String productName) {this.productName = productName;} private int productId = 0; private String productName = "";}

DubboResponse.java

Package org.sky.platform.util; import java.io.Serializable; import org.springframework.http.HttpStatus; import com.alibaba.fastjson.JSON; public class DubboResponse implements Serializable {/ * / private static final long serialVersionUID = 1L; / * * status code * / private int code / * * return information * / private String message; / * * return json object * / private T data; public DubboResponse (int code, String message) {this.code = code; this.message = message } public DubboResponse (int code, String message, T data) {this.code = code; this.message = message; this.data = data;} public T getData () {return data;} public void setData (T data) {this.data = data } public static DubboResponse success (String message, T data) {String resultStr = JSON.toJSONString (data); return new DubboResponse (HttpStatus.OK.value (), message, data);} public static DubboResponse success (String message) {return success (message, null) } public static DubboResponse error (String message) {return new DubboResponse (HttpStatus.INTERNAL_SERVER_ERROR.value (), message, null);} public static DubboResponse error (int code, String message) {return new DubboResponse (code, message, null);} public int getCode () {return code } public void setCode (int code) {this.code = code;} public String getMessage () {return message;} public void setMessage (String message) {this.message = message;}}

"normal" has a demonstration of @ Transactional's Service method throwing an exception:

Now let's run nacose-service and nacos-consumer to see the effect, trying to insert a new prouct:

Get returned:

Let's take a look at nacos-service side, nacos-consumer side and database.

You can see that both provider and consumer are thrown correctly and there are no values inserted in the database.

An "abnormal" (normal) Service method that does not contain Transactional is encapsulated to demonstrate:

Let's tamper with it now. Let's take the @ Transactional from the "addProductAndStock (ProductVO prod)" method on the provider side to see the effect.

@ Override public DubboResponse addProductAndStock (ProductVO prod) throws DemoRpcRunTimeException {DubboResponse response = null; int newProdId = 0; String prodSql = "insert into t_product (product_name) values (?)"; String stockSql = "insert into t_stock (product_id,stock) values (?)" Try {if (prod! = null) {KeyHolder keyHolder = new GeneratedKeyHolder (); jdbcTemplate.update (new PreparedStatementCreator () {@ Override

Please use a code chip like the one above

Let's make a small change on the nacos-consume side, as shown below, so that the server side directly displays the {"message": "xxxx..."} assembled on the provider side in the "front end" (everything accesses the consumer,consumer through the nginx side and then invokes the database through provider, where we use postman).

Then let's run it and see the effect:

We can see that after removing the @ Transactional annotation this time, when the Service method is thrown wrong, the requester gets what is in our packaged DubboResponse.

The provider side wraps the core code of the exception thrown by ordinary Service:

@ Around ("servicePointcut () & &! transactionalPointcut ()") public Object doAround (ProceedingJoinPoint pjp) {Object [] args = pjp.getArgs (); try {return pjp.proceed ();} catch (Exception e) {processException (pjp, args, e) Return DubboResponse.error ("exception occured on dubbo service side:" + e.getMessage ());} catch (Throwable throwable) {processException (pjp, args, throwable); return DubboResponse.error ("exception occured on dubbo service side:" + throwable.getMessage ());}}

Let's take a look at our provider side, which uses this paragraph in the above code catch (Exception e) to record errors in the server log and return the errors to the server side after wrapping them. These two sentences are as follows:

ProcessException (pjp, args, e); return DubboResponse.error ("exception occured on dubbo service side:" + e.getMessage ())

Take a look at the log output on the nacos-service side:

Take a look at the log output on the nacos-consumer side:

Haha, there is nothing wrong with the nacos-consumer side this time, because the error has been packaged by the provider side.

Of course, when we look at our DB side, it is certain that there is a successful data insertion.

Because as mentioned earlier, for methods without @ Transactional annotations, our aop handler class will "eat" all errors, only record them in the background and package the normal return results to the server, so the provider-side Service method has no RuntimeException thrown, how can it be rolled back?

Of course the insertion was successful!

T _ product table

T _ stocktable

The above is the content of this article on "nacos+springboot+dubbo2.7.3 unified methods for handling exceptions". I believe we all have a certain understanding. I hope the content shared by the editor will be helpful to you. If you want to know more about the relevant knowledge, please follow the industry information channel.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.