Open vagabond1-1983 opened 8 years ago
在进行产品测试时,我们会碰到下面几种情况:
可能大家想到用Mock的方式,去模拟一个网络的接口。过程是这样的。我想要得到的是被测系统的输出。Tesla是被测系统。数据输入后经过Tesla,Tesla要调用Stub接口,然后返回数据。也就像之前咱们举的例子:商品系统调用商家接口。如果Stub接口挂了,我们用Mock服务代替这个接口,返回定制好的数据,然后得到输出,完成数据的正常流动。
那是不是有Mock服务就完全解决了开头提到的三个问题呢?我觉得并没有。我们研究了业界众多的Mock方案,比方说,支持HTTP协议的WireMock,支持WebService的SoapUI里面的MockService,Dubbo需要自己写接口实现再打成jar包中并需要同接口在一个jar包中。我们从中看到这样的缺点:不同协议的方案从属于不同的平台,多个Mock服务无法有效管理。
Mock服务的平台管理部分,其实各家有个家的方案,主要看是不是便利了。而对于Mock方案,不同方案其实千差万别。看起来都是对于接口的模拟,如果不是从协议底层出发,可能它的扩展性不会很大。
现代RPC的本质其实就是在网络上传输数据包,而这个数据包的特点是header+body。Header就是协议头,分为定长或者变长,这个取决于协议的设计者。比方dubbo协议就是定长的。而有些协议是变长的。Body就是消息体,其实就是对象的序列化过程,把序列化好的数据放入到body里面。现在流行的序列化方案有:hessian,java,json,msgpack等。
有了这个本质了,咱们看一下,用什么样的方式从网络中传输这个数据包。 底层框架用NIO/Netty框架。因为是异步通信,高性能,高并发的支持,Netty框架就可以做到。 建立通信之后,客户端发起请求,发送数据包到服务端。服务端拿到数据包之后进行解码操作。 服务端构造响应结果,序列化完成后,加上协议头信息,返回给客户端。 过程虽然简单,但是在实际开发过程中可能碰到一些问题。下面就是我在实践的时候碰到过的一些坑,列出来供大家参考。
综上,对于接口的Mock,从协议底层下手扩展性好,处理较方便,能够协助剥离依赖关系,更便捷、专注于自身系统的测试工作,达到事半功倍的效果。
在进行产品测试时,我们会碰到下面几种情况:
可能大家想到用Mock的方式,去模拟一个网络的接口。过程是这样的。我想要得到的是被测系统的输出。Tesla是被测系统。数据输入后经过Tesla,Tesla要调用Stub接口,然后返回数据。也就像之前咱们举的例子:商品系统调用商家接口。如果Stub接口挂了,我们用Mock服务代替这个接口,返回定制好的数据,然后得到输出,完成数据的正常流动。
那是不是有Mock服务就完全解决了开头提到的三个问题呢?我觉得并没有。我们研究了业界众多的Mock方案,比方说,支持HTTP协议的WireMock,支持WebService的SoapUI里面的MockService,Dubbo需要自己写接口实现再打成jar包中并需要同接口在一个jar包中。我们从中看到这样的缺点:不同协议的方案从属于不同的平台,多个Mock服务无法有效管理。
Mock服务的平台管理部分,其实各家有个家的方案,主要看是不是便利了。而对于Mock方案,不同方案其实千差万别。看起来都是对于接口的模拟,如果不是从协议底层出发,可能它的扩展性不会很大。
现代RPC的本质其实就是在网络上传输数据包,而这个数据包的特点是header+body。Header就是协议头,分为定长或者变长,这个取决于协议的设计者。比方dubbo协议就是定长的。而有些协议是变长的。Body就是消息体,其实就是对象的序列化过程,把序列化好的数据放入到body里面。现在流行的序列化方案有:hessian,java,json,msgpack等。
有了这个本质了,咱们看一下,用什么样的方式从网络中传输这个数据包。 底层框架用NIO/Netty框架。因为是异步通信,高性能,高并发的支持,Netty框架就可以做到。 建立通信之后,客户端发起请求,发送数据包到服务端。服务端拿到数据包之后进行解码操作。 服务端构造响应结果,序列化完成后,加上协议头信息,返回给客户端。 过程虽然简单,但是在实际开发过程中可能碰到一些问题。下面就是我在实践的时候碰到过的一些坑,列出来供大家参考。
综上,对于接口的Mock,从协议底层下手扩展性好,处理较方便,能够协助剥离依赖关系,更便捷、专注于自身系统的测试工作,达到事半功倍的效果。