写在前边
分布式架构是互联网应用的基础架构,很多新人入职以来就开始负责编写和调用阿里的各种远程1,接口。但如同结婚一般,用对一个正确的1,接口就如同嫁一个正确的人一样,往往难以那么顺利的实现,或多或少大家都会在这个上边吃亏。
每年双十一系统调用复盘的时候,我都会听到以下声音
你们调我的1,接口报错了竟然不会自己重试?我的返回值应该从这里取我返回isSuccess()==true,不代表业务成功,你还需要判断ERROR_CODE这个ERROR_CODE没说全部都要重试啊!这个ERROR_CODE必须要重试!
还有很多了,本文的目标就是帮助大家思考,如何设计自己的远程1,接口,让1,接口做到健壮、易用,节省大家在这块泥潭中所挣扎的时间。
一个日志服务LogService
PS:本例子的代码可以见Excavatore-DEMO
上课!大家好,我是你们的苍老师。今天就由我来给大家讲讲如何编写一个健壮的远程1,接口。老师将在这里给大家设计一个集中式的日志系统。 虽然这个系统的存在不合理,但这是能找到的最简单例子,所以不要在课堂上就系统的合理性展开讨论,否则老师会生气的哟~ |
系统架构
一个集中性的日志服务器,要求应用通过日志系统提供的日志服务,将所有日志集中统一的输出到固定的文件中。
系统架构
这很简单嘛,根据系统的要求和架构特性,我很快就能写出1,接口定义,老师你看。“如果方法顺利无异常返回,则说明日志已经被成功写入了日志文件” |
1,接口v0.1版
/**
* 日志服务
* @author : xiaoming.xm@cainiao.com
* @version: 0.1
*/
public interface LogService {
/**
* 记录INFO级别日志
*
* @param format 日志模版(同String.format())
* @param args 日志参数
*/
void info(String format, Serializable... args);
}
非常好,但这种1,接口只能用在单机版的程序中,如果遇到远程调用的场景就不适用了。 要了解这个事实,首先大家就要知道远程调用的大概实现原理。 |
RPC调用
什么是RPC调用
RPC远程过程调用,一种通过网络从远程计算机程序上请求服务,而不需要了解底层网络技术的技术实现。
RPC采用C/S模式。请求程序就是一个客户机,而服务提供程序就是一个服务器。客户机调用进程发送一个有进程参数的调用信息到服务进程,然后等待应答信息。在服务器端,进程保持睡眠状态直到调用信息的到达为止。当一个调用信息到达,服务器获得进程参数,计算结果,发送答复信息,然后等待下一个调用信息,客户端调用进程接收答复信息,获得进程结果,然后调用执行继续进行。
以上信息摘录自百度百科
一次完整的RPC调用过程
请求过程
客户端函数将参数传递到客户端句柄。客户端句柄将请求序号、远程方法、参数等信息封装到请求对象中,并完成请求对象序列化形成请求报文,通过网络客户端发送请求报文。请求报文通过网络客户端与网络服务端所约定的协议进行通讯。网络服务端收到请求报文之后,通过反序列化,从请求对象中解析出远程方法、参数等信息,并根据这些信息找到服务器句柄。通过服务器句柄完成服务器函数的本地调用过程自此,整个请求流程完成。
应答过程
服务器函数执行的过程将结果返回服务器句柄,返回的结果可能是正常返回,也可能是以抛异常的形式返回。服务器句柄根据返回的值与请求序号封装到应答对象中,并完成应答对象的序列化,形成应答报文,通过网络服务端发送应答报文。应答报文通过网络服户端与网络客务端所约定的协议进行通讯。网络客户端收到应答报文之后,通过反序列化,从应答对象中解析出请求序号所挂钩的客户端句柄客户端函数,以返回值或抛异常的形式将信息返回
自此,整个应答流程完成。
一次完整的RPC调用一共分10步,每一步都有可能出错,所以在设计一个远程1,接口的时候必须充分考虑到所有的出错可能,与客户端约定出错的应对方案。无论哪个环节出问题,都要求你的业务逻辑依旧保证不能错乱! |
不愧是苍老师,果然博大精深。我明白了,因为增加了远程访问的因素,所以原本单机中非常小的出错概率就被放大了,这也不得不让程序被迫感知和处理这些通讯错误。 那请问遇到这些错误都应该怎样进行归纳和处理呢? |
一次远程调用出错的可能
通讯框架错误
通讯框架错误根据发生环节分可以细分为
Marshell&UnMarshellC/S双方采用了不一致的序列化/反序列化算法,导致在通讯之前或之后无法正常取得通讯的对象。从而导致双方在编码、解码的过程中发生错误。如果你的通讯框架使用了Hessian那基本上你都有机会遇到过。至于序列化和反序列化的梗,都可以开个专题了。这里就不在啰嗦。网络通讯错误系统错误会导致无法预测的异常产生,具体取决于RPC的实现方式。对于这种错误,唯一的处理方式只有:另外找时间/机会重试。
业务系统错误
业务系统错误分两种情况
业务错误Client传递了违背业务规则的参数,导致业务逻辑处理失败。这种错误无论重复多少次都会得到一样结局。系统错误Server处理内部逻辑时出现了无法控制的错误,常见的有:
数据库访问失败文件写入失败网络通讯失败一般遇到这种错误,可以通过重试解决。
各种出错场景&解决方案梳理
通讯框架错误 | 抛出框架异常 | 重试 |
系统错误 | 抛出系统异 | 重试 |
业务错误 | 返回明确的错误码 | 禁止重试 |
嗯,我了解了,一个好的远程方法定义必须考虑到上边所罗列的异常场景,要求做到明确的错误处理约定 。那请问苍老师这个1,接口应该如何写呢? |
先别着急,要写出健壮的1,接口,你还有几个概念要理解。首先我们先来看这个1,接口的声明。我的比你多了两个重要的信息ResultDO<T> 与LogException ,接下来我会讲解这定义这两个类的作用 |
代码组织
如果你有机会重新搭建一个应用,推荐大家采用分包的策略来考虑自己的模块组织。
common:定义core和client所共用的内容业务1,接口声明LogServiceDomain对象ResultDO
正确处理返回值
这套RPC1,接口声明的理念在于:如何通过约定区分出系统异常与业务异常。区分的关键就在于ResultDO
ResultDO
客户端对返回值的处理总结
客户端处理逻辑表
框架错误 | / | / | / | true | 重试 |
系统错误 | / | / | true | / | 重试 |
业务错误 | false | true | / | / | 不重试 |
成功返回 | true | true | / | / | 不重试 |
所有情况也不是一层不变。比如业务错误返回错误码,但有时处于性能考虑,可以在1,接口声明中约定部分错误码也必须要进入重试。但这种场景越少越好,而且一旦做出约定,出于1,接口向下兼容的考虑,这种需要重试的错误码自声明以来,只能减少不能增加,否则会引起兼容问题。
老师也见过有系统在ResultDO中声明了 public boolean isReTry(); 方法,这样当系统发生业务错误的时候,是否重试的判断就交由 isReTry() 来进行判断,这也是不错的选择。 |
增加isReTry()后的客户端处理逻辑表
框架错误 | / | / | / | / | true | 重试 |
系统错误 | / | / | / | true | / | 重试 |
业务错误 | false | true | true | / | / | 重试 |
业务错误 | false | false | true | / | / | 不重试 |
成功返回 | true | / | true | / | / | 不重试 |
为什么要有Client层
老实说,这一层不是必须的,很多情况下客户端直接使用服务端声明的Service1,接口足矣。但若遇到在客户端容灾、增强的场景,则ServiceClient的优势就体现出来。
1,接口v0.2版
/**
* 日志服务
* @author : cangjingkong.cjk@cainiao.com
* @version: 0.2
*/
public interface LogService {
/**
* 记录INFO级别日志
*
* @param format 日志模版(同String.format())
* @param args 日志参数
* @return 记录日志是否成功
* @throws LogException 记录日志发生异常
*/
ResultDO info(String format, Serializable... args) throws LogException;
}
一个好的系统约定能减少很多不必要的错误,但毕竟不是所有系统都是新的系统,在面临各种先人的智慧 时,如何让不符合约定的远程1,接口也纳入约定来? |
在面对先人的智慧 时,改变现有被大量调用的1,接口声明是不可能的,在这种情况下存在即合理 ,哪怕明知1,接口声明或实现存在问题,你也不能去变更这个1,接口。1,接口维护原则请听下堂课《远程1,接口维护经验分享》。当遇到这种不在约定的1,接口时,需要用 装饰模式 将不规范的1,接口包装成为规范的1,接口。 |
1,接口的Wrapper
几乎可以肯定的,在公司中你肯定不是第一个声明1,接口的人。所以当你定出了远程1,接口设计规范之后,如何面对老1,接口则成了一个头疼的问题。
先人的智慧是无穷的,现在我们讨论的问题,我们的前辈都已经面临并解决了,只是解决的方法各种各样,没有形成约定。何解?
此时可以考虑使用装饰模式将不规范的1,接口重新包装成符合设计规范的1,接口,这样做有两个好处:
解决老1,接口不规范问题减小老1,接口暴露到业务代码中的概率这里需要解释下。外部1,接口的定义不受控制,如果此时一个Service需要升级,则改动、回归、代码REVIEW范围仅限于Wrapper类即可,若将所有业务代码直接引用外部的Service/ServiceClient类,则升级的回归面将被放大。
所以无论对方声明的1,接口是否符合约定,我都会建议客户端不要直接使用Service/ServiceClient,而是Wrapper一层。
太好了,经过老师提点,我终于写出了一个健壮的远程1,接口,并知道如何与客户端约定重试的关系。 不过我还是想问问,这种远程的日志系统存在是否不是太合理,老师你举这个例子是不是不太恰当? |
文章为作者独立观点,不代表 股票程序化软件自动交易接口观点