Thrift接口网关设计

Posted 2021-04-24 金大师科技部落

背景

近半年来，工作任务中充斥着各种各样的接口，实时交易查询接口、历史交易查询接口、数据报表查询接口...由于业务逻辑和相关资源的限制，导致一些接口查询的入口较为分散，造成客户端的调用不便，服务端的维护不便，因此计划对其进行改造。

设计思路

设计过程中，Google了许多当前流行的微服务架构，如Netflix、Spring Cloud等，结合目前的业务、请求量和维护成本的评估后，发现上述重量级的框架并不适合我们，有点牛刀杀鸡的感觉。经过对Thrift源码的研读和相关资料的查看，设计出了一套适合我们的轻量级Thrift网关。话不多说，先看图。

优化前，客户端自主进行业务区分，接口调用：

优化后，由网关进行客户端请求的路由：

优化后，对于客户端来说只有一个查询服务入口，从而降低了自身的调用复杂度，这样可以把更多精力集中在业务逻辑的处理上；对于服务端来说，对服务进行集中管理，统一调度，降低了维护成本，在没有增加过多业务耦合的基础上，增强了服务的健壮性。

设计要素

l  ZooKeeper集群

该体系架构的载体，负责各个子服务的注册、发现及服务健康检查（ZooKeeper自身的优点和强大功能我就不在这里赘述了）。简而言之，各个子服务通过ZooKeeper进行统一管理和维护，ZooKeeper可提供服务端内存、带宽、磁盘IO、客户端请求调用频次等重要指标，为之后诸如业务及性能的相关监控打下了坚实的基础；

l  Thrift网关

该体系架构中的大脑，负责获取服务（ZooKeeper注册上的所有服务），接收客户端的所有请求，对请求进行认证、解析（获取请求的具体service及方法），动态服务路由；

l  各个子服务

该体系的根本，启动时自动注册至ZooKeeper，各司其职，进行各自的业务处理；

网关核心实现

网关由Netty实现，核心在于通过Netty的ByteArrayEncoder字节编解码器将Thrift请求解析为字节数组，每次请求解析后的结构如下图所示

其中与业务有关的分两部分，一部分为请求签名验证部分，另一部分为请求体部分，验签通过后，通过请求体即可获取本次请求的服务名称和方法名称，并根据上述服务名称去匹配ZooKeeper中注册的的服务，待获得对于服务后，动态调用方法即可，并将返回的结果原路返回给客户端，核心代码如下：

参考资料

https://www.ibm.com/developerworks/cn/java/j-lo-apachethrift/

http://developerblog.info/2015/09/14/thrift-api-gateway-part-1-bloody-core/

结束语

此次没有贴上大段代码进行复述，主旨在于与大家分享构思的过程和对核心逻辑的把控，文章如果有叙述不正确的地方，请大家雅正，望和大家共同提高、进步。

苹果阻止不了你对原创文章的支持