NET Core微服务之路：自己动手实现Rpc服务框架，基于DotEasy.Rpc服务框架的介绍和集成...

最新推荐文章于 2024-04-05 09:34:29 发布
转载 最新推荐文章于 2024-04-05 09:34:29 发布 · 140 阅读 · 0 ·
CC 4.0 BY-SA版权
原文链接：http://www.cnblogs.com/lonelyxmas/p/10173061.html
文章标签：

#json #大数据 #c#

本文详细介绍基于.NET Core的RPC框架DotEasy.Rpc的设计与实现，包括服务注册、路由转发、客户端代理生成等关键技术点。并通过整合Consul，演示了如何在ASP.NET Core应用中快速搭建RPC服务。
NET Core微服务之路：自己动手实现Rpc服务框架，基于DotEasy.Rpc服务框架的介绍和集成
原文: NET Core微服务之路：自己动手实现Rpc服务框架，基于DotEasy.Rpc服务框架的介绍和集成

本篇内容属于非实用性（拿来即用）介绍，如对框架设计没兴趣的朋友，请略过。

 

快一个月没有写博文了，最近忙着两件事;
   一：阅读刘墉先生的《说话的魅力》，以一种微妙的，你我大家都会经常遇见的事物，来建议说话的“艺术和魅力”，对于我们从事软件开发、不太善于沟通和表达的朋友来说，也算是一项软技能了，推荐喜欢阅读的朋友有时间阅读，给你不一样的阅读体验。
二：编写基于Net Core的Rpc框架。之前有朋友说如何将Rpc等整个体系集成到dotnet框架中，我想这篇博文会给你一个答案。
哦，对了，我不建议直接将代码直接复制下来然后去运行的朋友，因为这样你达不到学习的目的，也违背了笔者的初衷。谢谢理解。

 

一：简单回顾一下之前的介绍

继续贴上之前的一张图片

 

 

根据上面图，服务化原理可以分为3步：
  1. 服务端启动并且向注册中心发送服务信息，注册中心收到后会定时监控服务状态（常见心跳检测）；
  2. 客户端需要开始调用服务的时候，首先去注册中心获取服务信息；
  3. 客户端创建远程调用连接，连接后服务端返回处理信息；
 
　　第3步又可以细分，下面说说远程过程调用的原理：
目标：客户端怎么调用远程机器上的公开方法
  1. 服务发现，向注册中心获取服务(这里需要做的有很多：拿到多个服务时需要做负载均衡，同机房过滤、版本过滤、服务路由过滤、统一网关等)；
  2. 客户端发起调用，将需要调用的服务、方法、参数进行组装；
  3. 序列化编码组装的消息，这里可以使用json，也可以使用xml，也可以使用protobuf，也可以使用hessian，几种方案的序列化速度还有序列化后占用字节大小都是选择的重要指标，对内笔者建议使用高效的protobuf，它基于TCP/IP二进制进行序列化，体积小，速度快。
  4. 传输协议，可以使用传统的IO阻塞传输，也可以使用高效的nio传输(Netty)；
  5. 服务端收到后进行反序列化，然后进行相应的处理；
  6. 服务端序列化response信息并且返回；
  7. 客户端收到response信息并且反序列化；
 
　　至于C类和S类之间的通信方式，是采用RPC还是采用RESTful，读者可以参考之前的介绍，根据实际业务进行决定 https://www.cnblogs.com/SteveLee/p/service_discovery_and_service_governance.html
 

二：DotEasy.Rpc框架介绍

　　单论Rpc框架市场，且不论Java上的Spring Boot和Spring Cloud这样大名鼎鼎的开源框架，目前Net上的Rpc整合性框架确实并不多，我们Net程序员也要混口饭吃，不能总被Java甩掉好几条街吧。
　　言归正传，一个远程过程调用，会涉及到如下几个方面的技术点（功能）：
  1. 路由转发：当服务部署在多个节点上时，调用方需要知道自己的目标服务在什么地方。
  2. 通信协议：当管道存在，还需要在管道的两端建立处理程序（宿主），以处理管道中的数据包。DotEasy.Rpc基于DotNetty进行通信处理和协议实现。
  3. 动态生成：我们知道，基于二进制的RPC传输，每当新增接口，或修改接口，都需要生成相关协议的protobuf文件（或 thrift 文件），本框架基于protobuf-net的传输框架和Rosyln的预生成，动态生成相关的CS文件。
  4. 运行时代理：本框架采用一次请求创建一个客户端的模式，进行S端的服务请求，本框架基于Rosyln运行时创建客户端代理。
  5. 接口扫描：需要实现多个接口的添加和注册，本框架采用Attribute特性来扫描接口，并添加到相关的注册中心，比如consul或etcd。

 

2.1 解决方案介绍：

　　整体解决方案不做过多介绍，相信单词的词义已经表达了这个项目的作用。
　　小插曲：笔者曾用Easy.Rpc做为项目的主库名称，但上传到nuget后才发现，原来也有名为easy.rpc的包，不过笔者并没找到这个开源作者的网站，无赖之下，想到“点”这个词，也是dotnet的dot开头部分，索性干脆也叫DotEasy了吧。
　　笔者的目的，是想通过这个框架（或类库集），来简化微服务的部署和开发，让希望从事微服务NET开发的朋友不再找不到从何入手的窘境。
在Nuget.org上能直接下载编译过的包，地址： https://www.nuget.org/packages/DotEasy.Rpc/，推荐使用这种方式进行安装。
　　如果喜欢研究源码，笔者同样也贴上地址： https://github.com/steveleeCN87/doteasy.rpc，不过源码不包含任何依赖，如果编译中出现版本问题，可联系笔者。目前Github和Nuget上就放上了DotEasy.Rpc核心库和DotEasy.Rpc.Consul扩展包，etcd和entry还在测试阶段，就不方便拿出来献丑了。o(∩_∩)o 哈哈
　　当然，也欢迎广大爱好开源的朋友加入，共同为NET开源项目做贡献。

 

2.2 主项目介绍：

Attributes：用于标注该接口为某一特性的方法体，当系统通过Microsoft.Extensions.DependencyInjection自动构建成功后，框架将自动扫描接口上标注过[RpcTagBundle]的接口，形成目标接口列表，以供下面的方法调用。

Core：该核心分为Server和Client以及核心通用三个部分组成：

  Client：主要用于通过Ip地址远程调用的方法Invoke实现，以及远程服务端的检查检查实现。

  Communally：通用方法库，包括唯一ID生成器（用于标识每次请求所产生的唯一客户端）、通用对象转换器（将复杂对象转换为喜欢默认对象）、异常处理器、序列化生成器。

  Server：提供服务宿主，服务执行者、服务入口处理、服务管理、服务定位、服务管理工厂的接口及默认实现。

Proxy：运行时预生成及客户端动态代理模组的接口和方法实现。

Routing：提供地址定位、服务描述、服务路由的接口和方法实现。

Transport：基于protobuf-net和dotnettey构建的二进制序列化、和通信管道和宿主的接口和实现。

所有主要类均已接口的形式提供接口名称，和已默认实现的具体方法体（虚方法），方便在这个基础上进行扩展和重写。

 

2.3 主项目接口

本节简单介绍一下DotEasy.Rpc主框架的接口的作用。

Attribute:
|---RpcTagBundleAttribute.cs
Core:
|---Client:
|-------Address:
|-----------IAddressResolver.cs
|-------IRemoteInvokeService.cs
|---Server:
|-------IServiceEntryFactory.cs
|-------IServiceEntryLocate.cs
|-------IServiceEntryManager.cs
|-------IServiceEntryProvider.cs
|-------IServiceExecutor.cs
|-------IServiceHost.cs
Proxy:
|---IServiceProxyFactory.cs
|---IServiceProxyGenerater.cs
Routing:
|---IServiceRouteFactory.cs
|---IServiceRouteManager.cs
Transport:
|-------Codec:
|-----------ITransportMessageCodecFactory.cs
|-----------ITransportMessageDecoder.cs
|-----------ITransportMessageEncoder.cs
|---IMessageListener.cs
|---IMessageSender.cs
RpcTagBundleAttribute.cs：所有标记过[RpcTagBundle]特性的接口均会被扫描至doteasy.rpc框架中；
IAddressResolver.cs：地址解析器，提供IPv4地址解析作用，用于IServiceRouteFactory和IRemoteInvokeService定位操作；
IRemoteInvokeService.cs：远程调用服务接口，提供远程服务调用的关键接口，通过IServiceProxyFactory接口代理调用；
IServiceEntryFactory.cs：服务入口工厂接口，对全局服务入口的统一的工厂操作，例如添加，监听，移除，修改服务入口等；
IServiceEntryLocate.cs：服务入口定位接口，通过IAddressResolver过滤和解析，实现服务入口的定位；
IServiceEntryManager.cs：服务入口管理全局管理接口，功能同IServiceEntryFactory相似，但提供更多的服务管理操作，比如负载均衡（采用轮询实现）；
IServiceEntryProvider.cs：服务入口提供者接口，一个简单的服务入口提供者程序；
IServiceExecutor.cs：执行服务方法接口，执行远程服务的IRemoteInvokeService；
IServiceHost.cs：服务宿主接口，DotNetty的服务宿主，类似own框架的自宿主程序，提供请求和响应操作；
IServiceProxyFactory.cs：服务代理工厂接口，客户端代理（预编译）的所有操作实现；
IServiceProxyGenerater.cs：服务代理生成接口，客户端代理（预编译）生成器；
IServiceRouteFactory.cs：服务路由工厂接口；
IServiceRouteManager.cs：服务路由全局管理接口；
ITransportMessageCodecFactory.cs：管道消息传输工厂接口；
ITransportMessageDecoder.cs：管道消息解码器接口；
ITransportMessageEncoder.cs：管道消息编码器接口；
IMessageListener.cs：管道消息监听接口，可实现一个消息的接受者和处理程序；
IMessageSender.cs：管道消息发送接口，可实现一个消息的发送者；
 
　　通过上面的框架和㢟就能实现客户端到服务端的RPC通信了吗？当然不是，还需要服务注册中心（例如Consul，etcd，zookeeper）来实现。上面只是提供了路由转发，服务定位，客户端预编译的实现等等功能而已，而服务的注册并没提供，因为它不属于基础框架的范畴，笔者对zookeeper的笨重太反感（当然不是说它不好），而consul和etcd十分轻量级，特此又专门新增了两个项目：DotEasy.Rpc.Consul和DotEasy.Rpc.Etcd，用于实现不同注册中心的注册（获取）方法，和健康检测机制。
 
　　当然，介绍Consul和Etcd如何实现不是本节的重点，DotEasy.Rpc这个框架的完全剖析也将在日后新开篇章中专门介绍如何去实现一个框架，想必大部分朋友关心的是这个框架能做什么，有什么样的功能，那么，接下来开始吧。

 

三：如何使用

本系列一直重复的那张图片，噼里啪啦噼里啪啦......此处省略三百字。绕来绕去，难以入手，正如上一篇有朋友推荐如何在Asp.net core中集成、等等。
功能和特性如下：
  1. Apache许可证2协议开放源代码；
  2. 统一组件装配和构造；
  3. 基于protobuf-net实现字节流序列化；
  4. 基于Rosyln的运行时客户端代理生成；
  5. 基于Rosyln的预生成的客户端代理；
  6. 基于DotNetty的传输信道；
  7. 支持客户端以轮询的方式实现负载平衡；
  8. Net Core结构及跨平台；
就这么点，不啰嗦，让我们开始做DEMO。
 
3.1 建立服务接口和服务实现
既然是服务，那么肯定需要以接口interface的方式实现对外暴露，并且， 接口的实现不能和接口封装在同一个DLL中，不然还叫什么远程过程调用呢（RPC）呢，如果不了解什么叫接口，去翻一翻C#语言规范。
先定义一个接口，接口方法签名如下： 
namespace doteasy.rpc.interfaces
{
    [RpcTagBundle]
    public interface IUserService
    {
        Task<string> GetUserName(int id);
        Task<bool> Exists(int id);
        Task<int> GetUserId(string userName);
        Task<DateTime> GetUserLastSignInTime(int id);
        Task<IDictionary<string, string>> GetDictionary();
        Task TryThrowException();
    }
}

 

很简单，不解释。
其中接口上有个重要特性叫[RpcTagBundle]，该特性只允许标记在interface接口上，用于启动时方便框架扫描所有标有该特性的接口。
 
在看实现类 
namespace doteasy.rpc.implement
{
    public class UserService : IUserService
    {
        public Task<string> GetUserName(int id)
        {
            return Task.FromResult($"我传了一个int数字{id}.");
        }

        public Task<bool> Exists(int id)
        {
            return Task.FromResult(true);
        }

        public Task<int> GetUserId(string userName)
        {
            return Task.FromResult(1);
        }

        public Task<DateTime> GetUserLastSignInTime(int id)
        {
            return Task.FromResult(DateTime.Now);
        }

        public Task<IDictionary<string, string>> GetDictionary()
        {
            return Task.FromResult<IDictionary<string, string>>(new Dictionary<string, string> { { "key", "value" } });
        }

        public Task TryThrowException()
        {
            throw new Exception("尝试抛出异常！");
        }
    }
}

 

再次重申：注意两篇代码中的命名空间，就是两个不同的程序集（两个项目），千万不能以为笔者仅仅是为了区分而已。
 
3.2 建立asp.net core mvc应用程序
新建一个asp.net core mvc应用程序，模版默认webapi，添加一个控制器HeathController，当然，控制器名称你也可以自由发挥，键入如下代码： 
namespace doteasy.rpc.webserver.Controllers
{
    [Produces("application/json")]
    [Route("api/Health")]
    public class HealthController : Controller
    {
        [HttpGet]
        public IActionResult Get() => Ok("ok");
    }
}

 

也十分简单，对外暴露一个路由地址为"api/Health"的API接口，提供GET方法，返回OK信息。
这个接口的作用是用于Consul对服务的健康状态检查回调地址，Consul可以基于HTTP做健康检查，也可以通过gRPC验证服务健康状态。
至此，一个WebApi就建立完成，对外不在通过HTTP做任何接口暴露。
接下来我们添加一个IApplicationBuilder的扩展，用于启动Rpc服务端，代码如下： 
using System;
using doteasy.rpc.implement;
using doteasy.rpc.interfaces;
using DotEasy.Rpc.Entry;
using Microsoft.AspNetCore.Builder;
using Microsoft.Extensions.Configuration;
using Microsoft.Extensions.DependencyInjection;

namespace doteasy.rpc.webserver
{
    public static class ConsulServerExtensions
    {
        public static IApplicationBuilder UseConsulServerExtensions(this IApplicationBuilder app, IConfiguration configuration)
        {
            if (app == null) throw new ArgumentNullException(nameof(app));
            BaseServer baseServer = new BaseServer(configuration); //(1)
            baseServer.RegisterEvent += collection => collection.AddTransient<IUserService, UserService>(); //(2)
            baseServer.Start(); //(3)
            return app;
        }
    }
}
（1）：实例化一个BaseServer的服务类型，并使用 IConfiguration作为参数。该BaseServer类是封装太DotEasy.Rpc.Entry中的一个实现，主要是简化调用者的代码构建能力，不然，截图一个部分源码瞧瞧
框架的目的是简化编码工作，构建RPC实例也不例外，100多行的构建代码只用3行实现，偷懒者必备。
（2）：调用一次 RegisterEvent委托事件，用于将接口和实现注册到ServiceCollection容器中。
（3）：启动这个RPC服务，其实方法内还有构建ServiceCollection容器等等一大堆方法，你可以自己实现，也可以问笔者要源码。
 
配置文件在哪儿，难道这样就可以了？
当然不是，我们还需要一个appsettings.json的默认配置文件，代码如下： 
{
  "Hosting.urls": "http://127.0.0.1:5000",
  "Hosting.And.Rpc.Health.Check": "http://127.0.0.1:5000/api/health",
  "Rpc": {
    "IP": "127.0.0.1",
    "Port": 9881
  },
  "ServiceDescriptor": {
    "Name": "LZZ.DEV.ServerService"
  },
  "ConsulRegister": {
    "IP": "127.0.0.1",
    "Port": 8500,
    "Timeout": 5
  }
}
这篇配置文件很容易理解，这里不再重复啰嗦的解释。
 
至此，一个寄宿于Asp.net core的rpc服务就这样搭建完成，可以启动随Consul启动看看。
友情提示：建议将Asp.net core的默认日志功能关闭，否则Consul会5秒发送一个健康检查请求过来，日志会慢慢的变得十分臃肿，ConfigureLogging((context, logging) => { logging.ClearProviders(); })即可移除Logging日志功能。当然，你也可以做其他修改，毕竟日志在项目中非常重要。
 
3.3 测试启动Consul和Asp.net core
consul如何启动这个，笔者就不再复述了吧，想必看过之前的文章，应该都会启动和使用consul了，截个图，喜悦一下
3.1中的六个接口全被注册到consul服务中，不信，我们访问一个具体接口，看看meta信息。
路由和服务均通过这个信息进行定位，我们可以知道，在127.0.0.1的9881端口上，可以访问名为“doteasy.rpc.interfaces.IUserService.Exists_id”的接口。当然，目前是没有任何验证机制的，下一篇会介绍RPC中的统一验证机制。
 
3.4 建立一个客户端
废话不多说，直接上代码： 
using System;
using System.Threading.Tasks;
using doteasy.rpc.interfaces;
using DotEasy.Rpc.Entry;

namespace DotEasy.Client
{
    class Program : BaseClient
    {
        static void Main()
        {
            new TestClient();
        }
    }

    public class TestClient : BaseClient
    {
        public TestClient()
        {
            Task.Run(async () =>
            {
                var userService = Proxy<IUserService>();
                Console.WriteLine($"UserService.GetUserName:{await userService.GetUserName(1)}");
                Console.WriteLine($"UserService.GetUserId:{await userService.GetUserId("rabbit")}");
                Console.WriteLine($"UserService.GetUserLastSignInTime:{await userService.GetUserLastSignInTime(1)}");
                Console.WriteLine($"UserService.Exists:{await userService.Exists(1)}");
                Console.WriteLine($"UserService.GetDictionary:{(await userService.GetDictionary())["key"]}");
            }).Wait();
        }
    }
}

 

如你所见，我们就像在调用接口一样的去调用了RPC远程服务，中间的所有操作都是透明的，不需要关心的，唯一多了一句是 Proxy<IUserService>();使用代理模式动态生成了RPC远程客户端，该操作又被笔者封装在了BaseClient中，一切都为了使用者简单。
 
3.5 跑跑客户端看看结果 
info: DotEasy.Rpc.Core.Communally.Convertibles.Impl.DefaultTypeConvertibleService[0]
      发现了以下类型转换提供程序：DotEasy.Rpc.Core.Communally.Convertibles.Impl.DefaultTypeConvertibleProvider
info: DotEasy.Rpc.Core.Communally.IdGenerator.Impl.DefaultServiceIdGenerator[0]
      方法：System.Threading.Tasks.Task`1[System.String] GetUserName(Int32) 生成服务Id：doteasy.rpc.interfaces.IUserService.GetUserName_id
info: DotEasy.Rpc.Core.Communally.IdGenerator.Impl.DefaultServiceIdGenerator[0]
      方法：System.Threading.Tasks.Task`1[System.Boolean] Exists(Int32) 生成服务Id：doteasy.rpc.interfaces.IUserService.Exists_id
info: DotEasy.Rpc.Core.Communally.IdGenerator.Impl.DefaultServiceIdGenerator[0]
      方法：System.Threading.Tasks.Task`1[System.Int32] GetUserId(System.String) 生成服务Id：doteasy.rpc.interfaces.IUserService.GetUserId_userName
info: DotEasy.Rpc.Core.Communally.IdGenerator.Impl.DefaultServiceIdGenerator[0]
      方法：System.Threading.Tasks.Task`1[System.DateTime] GetUserLastSignInTime(Int32) 生成服务Id：doteasy.rpc.interfaces.IUserService.GetUserLastSignInTime_id
info: DotEasy.Rpc.Core.Communally.IdGenerator.Impl.DefaultServiceIdGenerator[0]
      方法：System.Threading.Tasks.Task`1[System.Collections.Generic.IDictionary`2[System.String,System.String]] GetDictionary() 生成服务Id：doteasy.rpc.interfaces.IUserService.GetDictionary
info: DotEasy.Rpc.Core.Communally.IdGenerator.Impl.DefaultServiceIdGenerator[0]
      方法：System.Threading.Tasks.Task TryThrowException() 生成服务Id：doteasy.rpc.interfaces.IUserService.TryThrowException
info: DotEasy.Rpc.Core.Client.Address.Resolvers.Implementation.DefaultAddressResolver[0]
      准备为服务id：doteasy.rpc.interfaces.IUserService.GetUserName_id，解析可用地址
info: DotEasy.Rpc.Consul.ConsulServiceRouteManager[0]
      准备获取所有路由配置。
info: DotEasy.Rpc.Core.Client.Address.Resolvers.Implementation.DefaultAddressResolver[0]
      根据服务id：doteasy.rpc.interfaces.IUserService.GetUserName_id，找到以下可用地址：127.0.0.1:9881
info: DotEasy.Rpc.Core.Client.Implementation.RemoteInvokeService[0]
      使用地址：'127.0.0.1:9881'进行调用
info: DotEasy.Rpc.Transport.Impl.DefaultDotNettyTransportClientFactory[0]
      准备为服务端地址：127.0.0.1:9881创建客户端。
info: DotEasy.Rpc.Transport.Impl.DefaultDotNettyTransportClientFactory[0]
      准备发送消息。
info: DotEasy.Rpc.Transport.Impl.DefaultDotNettyTransportClientFactory[0]
      准备获取Id为：0b720018feda4e4192937dfbb76eeb66的响应内容。
info: DotEasy.Rpc.Transport.Impl.DefaultDotNettyTransportClientFactory[0]
      消息发送成功。
UserService.GetUserName:我传了一个int数字1.
info: DotEasy.Rpc.Core.Client.Address.Resolvers.Implementation.DefaultAddressResolver[0]
      准备为服务id：doteasy.rpc.interfaces.IUserService.GetUserId_userName，解析可用地址
info: DotEasy.Rpc.Consul.ConsulServiceRouteManager[0]
      准备获取所有路由配置。
info: DotEasy.Rpc.Core.Client.Address.Resolvers.Implementation.DefaultAddressResolver[0]
      根据服务id：doteasy.rpc.interfaces.IUserService.GetUserId_userName，找到以下可用地址：127.0.0.1:9881
info: DotEasy.Rpc.Core.Client.Implementation.RemoteInvokeService[0]
      使用地址：'127.0.0.1:9881'进行调用
info: DotEasy.Rpc.Transport.Impl.DefaultDotNettyTransportClientFactory[0]
      准备为服务端地址：127.0.0.1:9881创建客户端。
info: DotEasy.Rpc.Transport.Impl.DefaultDotNettyTransportClientFactory[0]
      准备发送消息。
info: DotEasy.Rpc.Transport.Impl.DefaultDotNettyTransportClientFactory[0]
      准备获取Id为：e14b7606b4d54a66af81bfe3c7df46d4的响应内容。
info: DotEasy.Rpc.Transport.Impl.DefaultDotNettyTransportClientFactory[0]
      消息发送成功。
info: DotEasy.Rpc.Core.Communally.Convertibles.Impl.DefaultTypeConvertibleService[0]
      准备将 System.Int64 转换为：System.Int32
UserService.GetUserId:1
info: DotEasy.Rpc.Core.Client.Address.Resolvers.Implementation.DefaultAddressResolver[0]
      准备为服务id：doteasy.rpc.interfaces.IUserService.GetUserLastSignInTime_id，解析可用地址
info: DotEasy.Rpc.Consul.ConsulServiceRouteManager[0]
      准备获取所有路由配置。
info: DotEasy.Rpc.Core.Client.Address.Resolvers.Implementation.DefaultAddressResolver[0]
      根据服务id：doteasy.rpc.interfaces.IUserService.GetUserLastSignInTime_id，找到以下可用地址：127.0.0.1:9881
info: DotEasy.Rpc.Core.Client.Implementation.RemoteInvokeService[0]
      使用地址：'127.0.0.1:9881'进行调用
info: DotEasy.Rpc.Transport.Impl.DefaultDotNettyTransportClientFactory[0]
      准备为服务端地址：127.0.0.1:9881创建客户端。
info: DotEasy.Rpc.Transport.Impl.DefaultDotNettyTransportClientFactory[0]
      准备发送消息。
info: DotEasy.Rpc.Transport.Impl.DefaultDotNettyTransportClientFactory[0]
      准备获取Id为：d0452b16caeb48ba877da5f69a31b2f8的响应内容。
info: DotEasy.Rpc.Transport.Impl.DefaultDotNettyTransportClientFactory[0]
      消息发送成功。
UserService.GetUserLastSignInTime:2018/12/11 22:31:41
info: DotEasy.Rpc.Core.Client.Address.Resolvers.Implementation.DefaultAddressResolver[0]
      准备为服务id：doteasy.rpc.interfaces.IUserService.Exists_id，解析可用地址
info: DotEasy.Rpc.Consul.ConsulServiceRouteManager[0]
      准备获取所有路由配置。
info: DotEasy.Rpc.Core.Client.Address.Resolvers.Implementation.DefaultAddressResolver[0]
      根据服务id：doteasy.rpc.interfaces.IUserService.Exists_id，找到以下可用地址：127.0.0.1:9881
info: DotEasy.Rpc.Core.Client.Implementation.RemoteInvokeService[0]
      使用地址：'127.0.0.1:9881'进行调用
info: DotEasy.Rpc.Transport.Impl.DefaultDotNettyTransportClientFactory[0]
      准备为服务端地址：127.0.0.1:9881创建客户端。
info: DotEasy.Rpc.Transport.Impl.DefaultDotNettyTransportClientFactory[0]
      准备发送消息。
info: DotEasy.Rpc.Transport.Impl.DefaultDotNettyTransportClientFactory[0]
      准备获取Id为：4e9a218c4abd4551845008d9bc23c31f的响应内容。
info: DotEasy.Rpc.Transport.Impl.DefaultDotNettyTransportClientFactory[0]
      消息发送成功。
UserService.Exists:True
info: DotEasy.Rpc.Core.Client.Address.Resolvers.Implementation.DefaultAddressResolver[0]
      准备为服务id：doteasy.rpc.interfaces.IUserService.GetDictionary，解析可用地址
info: DotEasy.Rpc.Consul.ConsulServiceRouteManager[0]
      准备获取所有路由配置。
info: DotEasy.Rpc.Core.Client.Address.Resolvers.Implementation.DefaultAddressResolver[0]
      根据服务id：doteasy.rpc.interfaces.IUserService.GetDictionary，找到以下可用地址：127.0.0.1:9881
info: DotEasy.Rpc.Core.Client.Implementation.RemoteInvokeService[0]
      使用地址：'127.0.0.1:9881'进行调用
info: DotEasy.Rpc.Transport.Impl.DefaultDotNettyTransportClientFactory[0]
      准备为服务端地址：127.0.0.1:9881创建客户端。
info: DotEasy.Rpc.Transport.Impl.DefaultDotNettyTransportClientFactory[0]
      准备发送消息。
info: DotEasy.Rpc.Transport.Impl.DefaultDotNettyTransportClientFactory[0]
      准备获取Id为：a625fd4a6bd24e6b82983272b8894562的响应内容。
info: DotEasy.Rpc.Transport.Impl.DefaultDotNettyTransportClientFactory[0]
      消息发送成功。
info: DotEasy.Rpc.Core.Communally.Convertibles.Impl.DefaultTypeConvertibleService[0]
      准备将 Newtonsoft.Json.Linq.JObject 转换为：System.Collections.Generic.IDictionary`2[System.String,System.String]
UserService.GetDictionary:value

 

注意加粗的文字，是否跟调用接口一样的结果呢，其他的调试日志目前请忽略。
 

四：总结

这样，通过asp.net core + consul + doteasy.rpc便实现了一个简单的远程服务调用，你可以尝试部署到外网，看看是否是远程调用，当然，目前并没有任何的统一网关验证，所以，任何人的机器都可以调用。
 
码字不易，你的推荐是我最大的动力，谢谢。
感谢阅读！
posted on 2018-12-25 11:46 NET未来之路 阅读( ...) 评论( ...) 编辑 收藏

转载于:https://www.cnblogs.com/lonelyxmas/p/10173061.html

C#微服务架构实战：从零构建、深度解析与最佳实践
java专栏
04-24 2601
我们首先概述了微服务的概念与优势，接着重点讲解了使用ASP.NET Core作为微服务框架，实现服务接口、控制器以及微服务间的通信（RESTful API与gRPC）。接着，我们探讨了服务发现与负载均衡（Consul）、安全性（认证与授权）、监控与日志（Application Insights与Serilog），以及持续集成与部署（GitHub Actions）。：微服务是一种软件架构风格，将大型复杂应用拆分为一系列小型、独立、可独立部署的服务，每个服务负责一个特定业务领域。
NET Core微服务之路：基于Ocelot的API网关Relay实现--RPC篇
linnek的专栏
02-11 290
前言 我们都知道，API网关是工作在应用层上网关程序，为何要这样设计呢，而不是将网关程序直接工作在传输层、或者网络层等等更底层的环境呢？让我们先来简单的了解一下TCP/IP的五层模型。 （图片出自http://www.cnblogs.com/qishui/p/5428938.html） 具体的每一层的工作...
基于.NetCore的RPC框架DotNetCoreRpc
c13_tianming的专栏
01-06 1450
一直以来都想实现一个简单的RPC框架。.net core不断完善之后借助其自身的便利实现一个RPC框架。框架分Server端和Client端两部分。Client端可在Console或Web端等，能运行.net core的host上运行，Server端依赖Asp.Net Core。
微信core service服务器,.NET Core微服务之服务间的调用方式（REST and RPC）
weixin_34191434的博客
08-10 1440
一、REST or RPC ?1.1 REST & RPC微服务之间的接口调用通常包含两个部分，序列化和通信协议。常见的序列化协议包括json、xml、hession、protobuf、thrift、text、bytes等；通信比较流行的是http、soap、websockect，RPC通常基于TCP实现，常用框架例如dubbo，netty、mina、thrift。REST：严格意义上说接...
探索 DotNetCoreRpc：一个高效的 .NET Core RPC 框架
最新发布
gitblog_00013的博客
04-05 520
探索 DotNetCoreRpc：一个高效的 .NET Core RPC 框架 在当今软件开发中，远程过程调用（RPC）框架扮演着至关重要的角色，尤其对于分布式系统和微服务架构而言。今天，我们将深入探讨一款名为 的开源项目，它是一个专为 .NET Core 平台设计的轻量级、高性能的 RPC 框架。 项目简介 DotNetCoreRpc 是由开发者 softlgl 制作的一个基于 .NET Co...
受微服务启发，长得像兔子的轻量级框架，基于NETCore2.0Standard2核心库-C#-下载
01-10
此外，通过阅读源码，可以学习到如何利用.NET Core构建高性能的服务框架，以及如何设计和实现微服务间的通信协议。 总的来说，Doteasy.RPC是一个为开发者提供便捷的微服务通信方案的框架，它利用.NET Core 2.0 ...
微服务风格的轻量级C#框架DoteasyRPC发布
资源摘要信息: "受微服务启发，长得像兔子的轻量级框架，基于NETCore2.0Standard2核心库-C#-下载" 知识点： 1. 微服务架构模式： 微服务是一种设计思想，将单一应用程序划分成一组小服务。每个服务运行在其独立的...
【稳定性保障大作战】：Ollama服务重启前后的健康检查策略
因此，确保服务状态始终处于健康模式是每个IT组织的核心目标之一。 ## 1.2 健康检查减少宕机时间 通过实施定期的服务健康检查，可以提前识别和解决潜在问题，从而降低服务宕机的风险。健康检查有助于及
基于.netcore 开发的轻量Rpc框架
aitui8236的博客
01-22 383
Rpc原理详解 博客上已经有人解释的很详细了，我就不在解释了。传送门 项目简介 项目是依赖于.net core2.0版本，内部都是依靠IOC来实现的，方便做自定义扩展。底层的通信是采用socket，sokcet的代码参考Enode的socket代码。类的序列化目前只支持自带的BinarySerializer和Json.net，也可以自定义，扩展也很方便。也支持zookeeper的服...
NetStitch:NetStitch是基于.NetFramework.NETCore构建的Http RPC框架
05-15
NetStitch NetStitch是基于.NetFramework / .NETCore构建的Http RPC框架。 它为C＃提供了简单易用的Http WebApi调用。 该框架由两个项目NetStitch.Server和NetStitch.Client组成。 NetStitch服务器 NetStitch.Server是ASP.NET Core的中间件。 安装 PM>Install-Package NetStitch.Server 包装结构 NetStitch.Server Packages ├─build │ └NetStitch.Server.targets └─lib └DLLs NetStitch.Server.targets <? xml version = " 1.0 " encoding = " utf-8 " ?> < Project x
net RPC 架构选型
06-13
netcore Rpc框架选型，值得拥有，微服务架构必看书籍。。
.NET-surging是一个分布式微服务框架提供高性能RPC远程服务调用
08-14
surging 是一个分布式微服务框架,提供高性能RPC远程服务调用，采用Zookeeper作为surging服务的注册中心，集成了哈希，随机，轮询作为负载均衡的算法，RPC集成采用的是netty框架，采用异步传输
NetCore版RPC框架NewLife.ApiServer
weixin_34209851的博客
05-14 316
微服务和消息队列的基础都是RPC框架，比较有名的有WCF、gRPC、Dubbo等，我们的NewLife.ApiServer建立在网络库NewLife.Net之上，支持.Net Core，追求轻量级和高性能，只有最简单的远程调用功能。 现在是网络系列文章的第五篇，前面四篇快速过了一遍网络库基本用法，也做了压力测试并给出数字 2266万tps。 本章正式进入应用层面，并且采用.Net Core作为...
拥抱.NET Core，跨平台的轻量级RPC：Rabbit.Rpc
dotNET跨平台
07-09 609
不久前发布了一篇博文“.NET轻量级RPC框架：Rabbit.Rpc”，当初只实现了非常简单的功能，也罗列了之后的计划，经过几天的不断努力又为Rabbit.Rpc增加了一大波新特性，今天主要介绍下项目近况
.net core高并发_高可用可拓展的RPC框架 koalas-RPC
weixin_30303839的博客
12-04 1501
企业生产级百亿日PV高可用可拓展的RPC框架。理论上并发数量接近服务器带宽，客户端采用thrift协议，服务端支持netty和thrift的TThreadedSelectorServer半同步半异步线程模型，支持动态扩容，服务上下线，权重动态，可用性配置，泛化调用，页面流量统计，泛化调用等，支持trace跟踪等，天然接入cat支持数据大盘展示等1：为什么要写这个RPC市面上常见的RPC框架很多，g...
.NetCore框架Surging系列（四）RPC客户端过程
杨义权的博客
09-11 769
.NetCore框架Surging系列（一）介绍 .NetCore框架Surging系列（二）HTTP .NetCore框架Surging系列（三）HTTP本地路由发现过程 .NetCore框架Surging系列（四）RPC客户端过程 Rpc使用的是DotNetty，RPC客户端分层比较清晰 代理层 这层是Rpc的第一层，负责寻址、重发。寻址是将Rpc的请求地址转为远程服务器信息，重发是超时、熔断等调用不通进行重试机制； 熔断层 这层处理降级、阈值判定、熔断等，根据远程接口设定的值进行熔断； 注意：远程接
.NET Core 使用 grpc 实现微服务
dotNET跨平台
11-03 2478
GRPC 是Google发布的一个开源、高性能、通用RPC（Remote Procedure Call）框架。提供跨语言、跨平台支持。以下以一个.NET Core Console项目演示如何使用GRPC框架。
Web后台快速开发框架
weixin_30845171的博客
09-11 3242
Web后台快速开发框架 Coldairarrow 目录 目录 第1章目录1 第2章简介3 第3章基础准备4 3.1开发环境要求4 3.2基础数据库构建4 3.3运行5 第4章详细教程6 4.1代码架构6 4.1.1总体架构6 ...
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值