.NETASP.NET Core见识录dotNET

基于Asp.Net Core打造轻量级内部服务治理RPC(一)

2018-12-16  本文已影响5人  _科长_

      继之前的《Asp.Net Core + Docker 搭建》文章末尾说过的,将陆续编写基于asp.net core 打造一个内部服务治理的rpc框架。不过前端时间较忙,所以搁置了一段时间。闲话不多说,下面就来讲讲为什么需要去做一个该框架,以及想法的来源和设计思路。

一、产生背景

      公司是做教育行业,目前技术栈是以微软栈为主。整个平台的业务并不复制,都是以查询为主。因此先前搭建每个子系统的时候都是以最简单的方式入手(时间较紧)。但是随着时间的推移,各个子系统之间的交互也是越来越多,当然,我们的做法也是很简单,就是通过暴露rest api ,然后客户端通过http调用进行交互,以至于现在很多系统都会配置其他系统的调用信息。日积月累,感觉系统越来月凌乱(有洁癖,遇到这种乱,就必须要去重构^_^,当然也是为后面维护减少成本),于是就产生了编写一个内部服务调用的框架。

二、想法来源

      本着遇到问题解决问题的目的,最开始也想直接使用开源的系统,如:sugring,orleans等.net 界非常著名的项目。但考虑到我的需求很简单(以及我的想法也是做一个非常简单,尽量不依赖其他重量级的框架,开发人员都认真阅读代码后,都能轻易维护的东西),且对上述的框架目前应用到生产环境的案例不是很知晓的情况下,于是还是忍痛割爱,最终放弃了。在这里,我想表达我的目标就是我需要像dubbo一样,调用方只需要引用服务提供者定义的相关接口库(.Net 中定义的接口eg:IUserService),就能直接调用。服务的调用方和提供方都注册的一个统一的注册中心(我以consul为注册中心,无需安装其他运行时,非常方便)。这样就不需要关心服务的具体地方。(该实现方式的想法在我今天(2018-12-16)看到的doteasy.rpc中的文章和我的想法几乎一致,但是我的实现还是略有不同,它是基于pb进行传输实现的,我是完全基于asp.net core 中的webapi进行实现)。

三、设计思路

      其实,asp.net core 已经是一个完善且高效的rpc框架,我们在调用每一个实现的web api实际就是一个rpc调用,只是它是基于http协议,大多数情况下,数据是通过json序列化和反序列化而已。(其他开源的优秀框架eg:surgin,oreans,dubbo...实现了自己高效的通信方式以及协议)。所以,基于asp.net core来实现,其实就是基于它来扩展,并且满足大多数公司的业务需求的性能要求应该不是问题(何况我们的spring boot实现微服务也是走rest方式^_^)。下面是我的整个想法构思图。

图 1

      场景:比如我有一个Service A的集群,依赖了Service B集群(可运行多个Service B的进程实例)的一个接口(IUserService,当然该接口在Service B中进行了实现UserService)进行数据获取(或操作)。就可以通过启动每个Service B实例时就将Service B要提供的服务发布出来(或叫导出),注册到Consul注册集群中,同样,Service A的实例也需要注册到注册中心(即使不发布供其他服务调用的接口)。此时,Service A要调用Service B的服务,首先,通过HttpServiceProxyFactory服务代理类生成IUserSerivice的代理实现类UserSeriviceImpl(通过Emit进行动态代理),再从注册中心获取到Service B的集群信息,根据一定的负载算法(负载是客户端进行负载实现,目前只实现了简单的循环负载),选择一个Service B的实例进行远程调用。其中UserSeriviceImpl代理实现类中核心的代码就是通过HttpClient进行数据的包装,然后请求到Service B中的UserService(其实就是一个Controller)实现类中。然后在解析UserService处理后返回过来的数据。

      以上就是我整个Rpc调用的总体思路。具体每个模块的详细设计与实现,接下来我会继续写出来,有兴趣的朋友可以留言交流也可以加qq:418237014交流。

上一篇下一篇

猜你喜欢

热点阅读