How to use exceptions correctly in microservice architecture

This article will introduce to you the correct use of exceptions in microservice architecture. It has certain reference value. Friends in need can refer to it. I hope it will be helpful to everyone.

The correct use of exceptions ranks among the top three in importance in the microservice architecture. No comments.

The correct use of exceptions It ranks among the top three in importance in the microservice architecture. No comments.

Curdboys, long time no see. I wish you all a happy Dragon Boat Festival. I want to talk about exceptions recently. My thinking seems to have formed a closed loop. I hope this combination can be helpful to your business code.

The following will only discuss the best languages ​​in the world and the most ecologically complete languages. I don’t have any opinions.

Similarities and Differences of Exceptions

PHP The design of exceptions in PHP7 is consistent with Java's Exception extends Throwable, but there are still some subtle differences in historical reasons and design concepts. . For example, exceptions in PHP have code attributes, so there are multiple exceptions clustered into the same exception, and then different business logic codes are written according to code in the catch block.

But Java exceptions have no code and cannot be designed like this. Different exceptions can only be used for different situations. Therefore, we are accustomed to encapsulating services through packaging classes when exposed to the outside world, instead of directly relying on the transparent transmission of exceptions.

Uniform exception handling

In Java code, the most criticized thing is the numerous try catches. I don’t have any objections. Just grab a piece of code

@Override
public DataResult<List<AdsDTO>> getAds(Integer liveId) {

    try {
        List<AdsDTO> adsDTO = new ArrayList<>();
        //...业务逻辑省略
        DataResult.success(adsDTO);
    } catch (Exception e) {
        log.error("getAds has Exception:{}", e.getMessage(), e);
        DataResult.failure(ResultCode.CODE_INTERNAL_ERROR, e.getMessage()); // 将异常信息返回给服务端调用方
    }

    return dataResult;
}

Many times I just write a try catch without thinking, regardless of whether there are non-runtime exceptions in it. A better way is to use aop to intercept all service method calls, uniformly take over exceptions and handle them.

@Around("recordLog()")
public Object record(ProceedingJoinPoint joinPoint) throws Throwable {
  //... 请求调用来源记录

  Object result;

  try {
    result = joinPoint.proceed(joinPoint.getArgs());
  } catch (Exception e) {
    //... 记录异常日志

    DataResult<Object> res = DataResult.failure(ResultCode.CODE_INTERNAL_ERROR, e.getMessage());
    result = res;
  }

    //... 返回值日志记录

  return result;
}

There is a small problem. If the exception information of service A is returned directly to caller B, there may be some potential risks. The caller can never be trusted, even if he is a third-generation poor peasant. . Because it is not certain how the caller will handle the error message, it may be returned directly to the front end as json.

RuntimeException

Exceptions in Java can be divided into runtime exceptions and non-runtime exceptions. Runtime exceptions do not need to be caught, nor do they need to be caught in methods. Mark throw Exception. For example, if we use the Preconditions tool class in the guava package in the method, the IllegalArgumentException thrown is also a runtime exception.

@Override
public DataResult<List<AdsDTO>> getAds(Integer liveId) {
  Preconditions.checkArgument(null != liveId, "liveIds not be null");

  List<AdsDTO> adsDTOS = new ArrayList<>();
  //...业务逻辑省略
  return DataResult.success(adsDTOS);
}

We can also use this feature to customize our own business exception class to inherit RuntimeException

XXServiceRuntimeException extends RuntimeException

For situations that do not comply with business logic, XXServiceRuntimeException will be thrown directly

@Override
public DataResult<List<AdsDTO>> getAds(Integer liveId) {

  if (null == liveId) {
    throw new XXServiceRuntimeException("liveId can&#39;t be null");
  }

  List<AdsDTO> adsDTOS = new ArrayList<>();
  //...业务逻辑省略
  return DataResult.success(adsDTOS);
}

and then in aop performs unified processing and makes corresponding optimizations. For the previous rough approach, exceptions other than XXServiceRuntimeException and IllegalArgumentException should be recorded internally and no longer exposed to the outside world. However, you must remember to string together distributed links through requestId. In DataResult Return in to facilitate troubleshooting.

@Around("recordLog()")
public Object record(ProceedingJoinPoint joinPoint) throws Throwable {
  //... 请求调用来源记录

  Object result;

  try {
    result = joinPoint.proceed(joinPoint.getArgs());
  } catch (Exception e) {
    //... 记录异常日志①
    log.error("{}#{}, exception:{}:", clazzSimpleName, methodName, e.getClass().getSimpleName(), e);

    DataResult<Object> res = DataResult.failure(ResultCode.CODE_INTERNAL_ERROR);
    if (e instanceof XXServiceRuntimeException || e instanceof IllegalArgumentException) {
       res.setMessage(e.getMessage());
    }

    result = res;
  }

  if (result instanceof DataResult) {
      ((DataResult) result).setRequestId(EagleEye.getTraceId()); // DMC
  }

    //... 返回值日志记录

  return result;
}

Abnormal monitoring

As for the closed loop, after using the custom exception class, the threshold for monitoring and alarming the abnormal log can be reduced a lot, and the alarm To be more precise, take the monitoring of Alibaba Cloud SLS as an example

* and ERROR not XXServiceRuntimeException not IllegalArgumentException|SELECT COUNT(*) AS count

What is monitored here is the log recording exception log ①

Exception in PHP

The problems mentioned above in Java also exist in PHP. If you don't use 3 methods to simulate aop, you can't reflect that PHP is the best language in the world.

//1. call_user_func_array
//2. 反射
//3. 直接 new
try {
  $class = new $className();
  $result = $class->$methodName();
} catch (\Throwable $e) {
    //...略
}

Similar to the above architectural logic, we will not repeat the pseudo code. , basically consistent. It is also possible to customize your own business exception class to inherit RuntimeException, and then perform external output processing.

However, there is some historical baggage in PHP. When originally designed, many runtime exceptions were output as Notice and Warning errors, but the error output lacked a call stack, which was not conducive to troubleshooting

function foo(){
  return boo("xxx");
}

function boo($a){
  return explode($a);
}

foo();

Warning: explode() expects at least 2 parameters, 1 given in /Users/mengkang/Downloads/ab.php on line 8

You can't see the specific parameters, nor can you see the call stack. If you use set_error_handler ErrorException, it will be very clear.

set_error_handler(function ($severity, $message, $file, $line) {
    throw new ErrorException($message, 10001, $severity, $file, $line);
});

function foo(){
  return boo("xxx");
}

function boo($a){
  return explode($a);
}

try{
  foo();
}catch(Exception $e){
  echo $e->getTraceAsString();
}

The last printed information is

Fatal error: Uncaught ErrorException: explode() expects at least 2 parameters, 1 given in /Users/mengkang/Downloads/ab.php:12
Stack trace:
#0 [internal function]: {closure}(2, 'explode() expec...', '/Users/mengkang...', 12, Array)
#1 /Users/mengkang/Downloads/ab.php(12): explode('xxx')
#2 /Users/mengkang/Downloads/ab.php(8): boo('xxx')
#3 /Users/mengkang/Downloads/ab.php(15): foo()
#4 {main}
  thrown in /Users/mengkang/Downloads/ab.php on line 12

Modify the above function

function boo(array $a){
  return implode(",", $a);
}

and it will not be captured, because the PHP Fatal error: Uncaught TypeError is thrown, PHP7 With the new
class Error implements Throwable, there will be Stack in the PHP system error log, but it cannot be connected in series with the entire business system. Here we have to talk about the design of the log. We expect to use a traceId like Java. All logs are concatenated, from Nginx logs to normal info level logs in PHP and these Uncaught TypeErrors, so the default output is taken over to the system error log and recorded to a unified place in the catch code block. Then simply modify it here to

set_error_handler(function ($severity, $message, $file, $line) {
    throw new ErrorException($message, 10001, $severity, $file, $line);
});

function foo(){
  return boo("xxx");
}

function boo(array $a){
  return implode(",", $a);
}

try{
  foo();
}catch(Throwable $e){
  echo $e->getTraceAsString();
}

catch Throwable to accept Error and Exception.

But set_error_handler cannot handle some errors, such as E_PARSE errors. You can use register_shutdown_function to cover up.

值得注意的是register_shutdown_function的用意是在脚本正常退出或显示调用exit时，执行注册的函数。
是脚本运行(run-time not parse-time)出错退出时，才能使用。如果在调用register_shutdown_function的同一文件的里面有语法错误，是无法注册的，但是我们项目一般都是分多个文件的，这样就其他文件里有语法错误，也能捕获了

register_shutdown_function(function(){
    $e = error_get_last();
    if ($e){
        throw new \ErrorException($e["message"], 10002, E_ERROR, $e["file"], $e["line"]);
    }
});

如果你想直接使用这些代码（PHP的）直接到项目可能会有很多坑，因为我们习惯了系统中有很多  notice 了，可以将 notice 的错误转成异常之后主动记录，但是不对外抛出异常即可。

推荐学习：php视频教程

The above is the detailed content of How to use exceptions correctly in microservice architecture. For more information, please follow other related articles on the PHP Chinese website!