gateway动态调用soa服务

thrift文件是soa服务之间交流的协议,调用方提前生成sdk用于访问soa服务,sdk除了针对struct的定义生成go的结构体外,还包含了send和recv两大部分。

  • send。序列化thrift中的struct,通过与soa服务建立的长连接发送出去。在sdk中的表现主要是write开头的一些方法。

  • recv。反序列化thrift中的struct,由于代码时提前生成的,且[]byte数组中的各field都是类型已知的,直接调用read的方法即可。

为什么会产生动态调用的问题?由于之前引入gateway这层,作为http请求的统一入口,gateway存在调用soa服务的可能性,又不能引入大量的sdk,希望gateway尽量少的上线和改动。逻辑尽量是通用的,不针对具体业务。所以才有了动态调用soa服务这个方案。

当然,通过在gateway和soa服务之间增加一层代理,将大量的sdk引入分散在多个中间层服务上也是可以的,我们也恰恰要采用这个方案。

但是,动态调用soa服务这件事还是有必要阐述下,为了动态,将sdk中的针对具体thrift做的操作,用通用的方法替换,因为通用的sdk通过gateway是可以得到thrift文件的具体内容的,所以send和recv的时候当然也知道如何序列化和反序列化网络请求的内容。当然带来的代价就是代码复杂度和程序多做类型判断这两个开销。

同事实现的通用sdk,为了保证send的准确,通过reflect比对了参数值的实际类型和thrift中定义的类型,这件事考虑到性能,可以完全不做,当然代价就是,需要在监控和程序容错上做的完善一些。不能因为一些错误的解析就panic。

通用sdk还有一些插曲,就是解析thrift类库的选择,已经内部针对解析后结果的cache。都是因为动态带来的代价。只能尽量减小损耗。

gateway动态调用soa服务
Share this