本文探讨了openAPI在分布式系统中的异常处理问题，强调了建立统一异常规范的重要性，以减少沟通成本和提高系统稳定性。文章通过实例展示了错误处理的不足，如堆栈信息、服务端吞没异常和格式不一致，提出了异常分类、目的、处理原则和编程方案。重点讲述了异常分类、处理目的，以及针对冰河和HTTP接口的不同异常处理策略，还提出了异常规范处理方案和异常定义，尤其是HTTP请求中的JSON和XML格式异常响应。
[size=xx-large]1 前言[/size]
[size=x-large]1.1 背景[/size]
openAPI一套分布式系统，他调用了诸多关联系统并对公司外部提供统一的接口服务。
openAPI的SOA架构图：
[img]http://dl2.iteye.com/upload/attachment/0093/9376/9ebc4ea4-34a8-362e-bc85-a71308e6f70a.jpg[/img]
目前各系统的异常规范没有建立，同时也没有特殊的处理，所以openapi无法把具体的异常状态反馈给客户端。只能反馈：“系统内部异常”。这样将导致：
[list]
[*]增加开放平台与关联系统的沟通成本
[*]增加第三方应用与开放平台沟通成本
[*]公司形象与品牌受损失
[*]后期系统维护困难
[*]追踪异常困难
[/list]
综上所述，在这样的情况下，我们应当提前“预防火灾”，而不是整天“到处救火”，从根本上提高openAPI的稳定性。
[size=x-large]1.2 问题举例[/size]
客户端、最终用户、R&D无法理解服务端的异常。
1.tomcat堆栈信息(http)
[img]http://dl2.iteye.com/upload/attachment/0093/9378/32be27d0-c6d7-3d6e-b00c-954b98400329.jpg[/img]
2 服务端吞掉了底层异常(ice)
3 格式不一致，http请求返回了不同的数据类型(http)
[size=xx-large]2 异常概述[/size]
[size=x-large]2.1 异常分类[/size]
按照Java（详细见附录4.1）异常机制分：
1 检查异常，即需要在接口中声明的异常
该类异常一般在业务层抛出，在展现层处理，如Struts2的Action、SpringMVC的Controller、Ice服务实现类；
2 非检查异常，也即Runtime异常
该类异常一般在进程或线程的入口处统一处理，如Struts2的异常拦截器。该类异常不需要告诉最终用户异常具体原因，但是要告诉开发人员具体原因。
按照异常产生的原因，大致可分为4种：
1 用户错误的操作（如输入了错误的数据，违反了业务逻辑等）；
2 客户端开发人员对服务端接口的错误调用；
3 服务端开发人员的错误（如bug）；
4 系统运行环境。
对于第一类异常用检查异常；后面三类用非检查异常。
[size=x-large]2.2 异常处理的目的[/size]
谁犯了错就清晰明确的告诉犯错者犯了什么错，以便改正。
[size=x-large]2.3 异常处理的原则[/size]
针对服务端端和客户端分布式系统的远程接口，客户端需要转译异常并根据api文档定义处理。
1运行时异常，客户端报警；
2检查异常，根据不同策略呈现给用户；
[size=x-large]2.4 异常编程方案[/size]
在接口中，检查异常与非检查异常的比例中，检查异常越大，说明系统的异常处理机制越健全。
下图描述了api的类型：
[img]http://dl2.iteye.com/upload/attachment/0093/9386/4384c57d-cdcb-3df5-b47a-4b41820d378e.jpg[/img]
针对不同的接口类型，我们给出了几种不同的异常声明及处理办法。
下图给出了各类型接口的异常的类型：
[img]http://dl2.iteye.com/upload/attachment/0093/9389/0d782aa6-28de-3b1f-99d6-930d5c8284be.jpg[/img]
当异常发生时，openAPI只能转译已知异常（异常码）和已知页面（URL和头信息），并根据开放策略提供异常提示和报警。对于其他异常，openAPI无法转译，甚至在http接口中，对于未定义格式的数据或者异常，根本无法获悉服务端的处理情况。
[size=large]2.4.1 Ice/rmi[/size]
此类接口，与客户端开发技术紧密相连(
[size=x-large]1.1 背景[/size]
openAPI一套分布式系统，他调用了诸多关联系统并对公司外部提供统一的接口服务。
openAPI的SOA架构图：
[img]http://dl2.iteye.com/upload/attachment/0093/9376/9ebc4ea4-34a8-362e-bc85-a71308e6f70a.jpg[/img]
目前各系统的异常规范没有建立，同时也没有特殊的处理，所以openapi无法把具体的异常状态反馈给客户端。只能反馈：“系统内部异常”。这样将导致：
[list]
[*]增加开放平台与关联系统的沟通成本
[*]增加第三方应用与开放平台沟通成本
[*]公司形象与品牌受损失
[*]后期系统维护困难
[*]追踪异常困难
[/list]
综上所述，在这样的情况下，我们应当提前“预防火灾”，而不是整天“到处救火”，从根本上提高openAPI的稳定性。
[size=x-large]1.2 问题举例[/size]
客户端、最终用户、R&D无法理解服务端的异常。
1.tomcat堆栈信息(http)
[img]http://dl2.iteye.com/upload/attachment/0093/9378/32be27d0-c6d7-3d6e-b00c-954b98400329.jpg[/img]
2 服务端吞掉了底层异常(ice)
3 格式不一致，http请求返回了不同的数据类型(http)
[size=xx-large]2 异常概述[/size]
[size=x-large]2.1 异常分类[/size]
按照Java（详细见附录4.1）异常机制分：
1 检查异常，即需要在接口中声明的异常
该类异常一般在业务层抛出，在展现层处理，如Struts2的Action、SpringMVC的Controller、Ice服务实现类；
2 非检查异常，也即Runtime异常
该类异常一般在进程或线程的入口处统一处理，如Struts2的异常拦截器。该类异常不需要告诉最终用户异常具体原因，但是要告诉开发人员具体原因。
按照异常产生的原因，大致可分为4种：
1 用户错误的操作（如输入了错误的数据，违反了业务逻辑等）；
2 客户端开发人员对服务端接口的错误调用；
3 服务端开发人员的错误（如bug）；
4 系统运行环境。
对于第一类异常用检查异常；后面三类用非检查异常。
[size=x-large]2.2 异常处理的目的[/size]
谁犯了错就清晰明确的告诉犯错者犯了什么错，以便改正。
[size=x-large]2.3 异常处理的原则[/size]
针对服务端端和客户端分布式系统的远程接口，客户端需要转译异常并根据api文档定义处理。
1运行时异常，客户端报警；
2检查异常，根据不同策略呈现给用户；
[size=x-large]2.4 异常编程方案[/size]
在接口中，检查异常与非检查异常的比例中，检查异常越大，说明系统的异常处理机制越健全。
下图描述了api的类型：
[img]http://dl2.iteye.com/upload/attachment/0093/9386/4384c57d-cdcb-3df5-b47a-4b41820d378e.jpg[/img]
针对不同的接口类型，我们给出了几种不同的异常声明及处理办法。
下图给出了各类型接口的异常的类型：
[img]http://dl2.iteye.com/upload/attachment/0093/9389/0d782aa6-28de-3b1f-99d6-930d5c8284be.jpg[/img]
当异常发生时，openAPI只能转译已知异常（异常码）和已知页面（URL和头信息），并根据开放策略提供异常提示和报警。对于其他异常，openAPI无法转译，甚至在http接口中，对于未定义格式的数据或者异常，根本无法获悉服务端的处理情况。
[size=large]2.4.1 Ice/rmi[/size]
此类接口，与客户端开发技术紧密相连(
最低0.47元/天 解锁文章
扫一扫
2211
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
