继之前的《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交流。
网友评论