微服务的设计原则
来源:互联网 发布:同步带设计软件下载 编辑:程序博客网 时间:2024/05/16 17:18
调用链中的异常处理
假设微服务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。第三种方式容易造成路径命名子空间污染。
- 微服务的设计原则
- 微服务的4个设计原则
- 微服务学习-设计原则
- 微服务化系统拆分设计的原则
- 微服务架构 (七): 微服务粒度设计上的核心设计原则与思考的面向
- 微服务的4个设计原则和19个解决方案
- 微服务的4大设计原则和19个解决方案
- 微服务的4大设计原则和19个解决方案
- 微服务的4个设计原则和19个解决方案
- 微服务原则
- 微服务的概念——《微服务设计》读书笔记
- 【微服务】【概念】【原则】【连接】
- DevOps监控微服务的五条原则
- 管理微服务的5个关键原则
- 微服务架构的设计模式
- 微服务架构的设计模式
- 微服务架构的设计模式
- 微服务设计的几点思考
- Git高频命令(长期更新)
- C语言指针学习笔记
- 数据结构编程笔记十七:第六章 树和二叉树 赫夫曼树的实现
- 史上最科学!Swift 3 UITableView最佳实践 XIB极速实现UITableViewCell,UITableViewHeaderFooterView
- requests库入门-5-带参数的请求类型
- 微服务的设计原则
- JVM笔记
- 冒泡排序法
- 狄克斯特拉算法(入门)
- Java 割圆术球π
- Linux(64位)下OpenBabel 2.4.1、python2.7和Ipython实战(三)
- MATLAB 视角调整
- 基于注解的DI
- [PTA] 7-22 龟兔赛跑