微服务的设计原则

调用链中的异常处理

假设微服务serviceA的接口interfaceA被微服务serviceB调用，如果interfaceA在调用过程中会抛出异常，那么是否该将该异常以状态码传给serviceB呢？

对于RPC来说（如Feign），会自动将被调用的远程接口的异常在调用方以异常抛出；对于Rest Api来说，可以将异常包装到response的out中。

我建议serviceB在调用interfaceA时，判断interfaceA是否出现异常应该尽量不要依赖于判断interfaceA返回的状态码。因为读取状态码是要获取response对象，而这样会造成代码不必要的拖沓。
尽量不要这么写：

@GetMapping(path = "/interfaceA")
public String methodA(@RequestParam String input)throw SomeException{
    ...
    return res;
}

应该这么写：

@GetMapping(path = "/interfaceA")
public String methodA(@RequestParam String input){
    try{
        ...
    }catch(SomeException e){
        logger.error("error reason", e);
        return "error reason";
    }
    return res;
}

这样，出现异常时候，可以在serviceA记录异常原因，同时将异常原因返回给serviceB，这样serviceB可以通过返回字符串来判断是否执行成功。
而对于返回对象的接口，则可以在出现异常时通过返回null来告诉serviceB调用出现异常。

另外：

- 接口能返回String尽量不要返回Boolean，应该让serviceB尽可能知悉异常原因。（返回对象就没办法了）
- 如果interfaceA只有前端调用，interfaceA抛出异常返回状态码也是可以的（不过谁能保证interfaceA以后不被其他微服务调用呢？）

接口路径定义原则

接口路径

应该尽量将传递的变量input放在RequestParam：

@GetMapping(path = "/interfaceA")
public String methodA(@RequestParam String input){
    ...
    return res;
}

即使要放在path也应该这样：

@GetMapping(path = "/interfaceA/{input}")
public String methodA(@PathVariable("input") String input){
    ...
    return res;
}

而不应该这样放在path：

@GetMapping(path = "/{input}/interfaceA")

我们应该尽可能保证可以通过某种方式形成路径命名子空间，从而隔离开各个接口，方便dispatcher分派request。第三种方式容易造成路径命名子空间污染。