标签：博客 odm lan data ring 目的 策略 rem 方式
Redola.Rpc 是一个使用 C# 开发的 RPC 框架，代码开源在 GitHub 上。目前版本仅支持 .NET Framework 4.6 以上版本，未来待系统稳健后再考虑移植 .NET Standard 和 .NET Core。
Redola.Rpc 在 0.3.2 版本中，尝试解决几个 RPC 设计问题：
Redola 定义的 Actor 模型代表着一个通信节点，使用 ActorIdentity 描述，包括节点类型 Type、节点名称 Name、节点地址 Address、节点端口 Port。
Actor 与 Actor 之间是基于 TCP Socket 通信的，Actor 并不区分 TCP 的 Server/Client 端，它将 Server 和 Client 封装在底层，为上层应用提供更便捷的传输定义和调用接口。Actor 模型提供了面向通道 Channel 的双工通道，可以接收来自对端的消息，也可以发送消息给对端。
Actor 收发的消息是面向二进制数组的，它不关心具体发送的是什么消息，也不关心序列化格式。Actor 使用 ActorFrameHeader 定义传输消息头，Header 携带消息体长度。
Actor 一旦建立连接，生成的 Channel 通道会自动进行 KeepAlive 双向保活机制。通过 Actor 服务发现，可以与任意的 Actor 进行通信，无需再配置对端节点地址和端口。并且，针对相同 Type 的 Actor，还可以实现消息分发的负载均衡功能。
Redola.Rpc 是基于契约模型通信的，使用 Protobuf 2 格式定义 IDL，并通过自动生成工具生成 Contract 契约定义。
例如，下面是定义 ICalcService 服务的 IDL 定义。
package Redola.Rpc.TestContracts; message AddRequest { required int32 X = 10; required int32 Y = 20; } message AddResponse { required int32 Result = 10; } service CalcService { rpc Add (AddRequest) returns (AddResponse); }
上述 IDL 生成的 ICalcService 接口定义为：
public interface ICalcService { AddResponse Add(AddRequest request); }
Redola.Rpc 选择使用 Protobuf 2 进行消息序列化，默认集成 protobuf-net 类库，稳定使用 protobuf-net v2.0.0.668 版本。
使用 ActorMessageEnvelope 封装消息信封，携带如下信息：
RPC 消息分为 2 类：
通常 RPC 消息会包含如下属性信息：
例如，对于 ICalcService 中的 Add 方法：
鉴于 protobuf 本身是面向契约设计的，而 object[] 中的 object 是有不确定性的，并不能具体描述一个契约，则要求每一个 Argument 都需要支持 protobuf 的序列化，传输时系统会携带该 Argument 类型的 AssemblyQualifiedName，在对端通过反射进行反序列化。
Actor Directory 负责注册本地 Local Actor 到注册中心，Local Actor 也可以在 Shutdown 时将自己从注册中心移除掉。
通过 Actor Directory，Local Actor 可以使用 Type 和 Name 进行 Remote Actor 的检索，进而进行 Channel 的建立和通信。
Actor Directory 通过 IActorDirectory 的抽象定义，可以与不同的目录方案进行集成。例如，自实现基于 Actor 的 CenterActorDirectory，使用 XML 配置文件的 LocalXmlFileActorDirectory，使用 Consul 进行中心注册的 ConsulActorDirectory。
使用 Consul 时，实际上是调用了 Consul HTTP API 中的 Agent Register Service 接口 ‘/v1/agent/service/register‘，通过指定 ServiceID 和 ServiceName 进行注册。
通过如下 cmd 启动 Consul Server 和 Consul Agent。
consul.exe agent -config-dir "C:\Consul\config\server-01" -bootstrap -ui consul.exe agent -config-dir "C:\Consul\config\client-01" -join 192.168.1.133:7774 -ui
下面为启动本地 Consul 进行测试的配置文件。
server-01.json
{ "datacenter": "dc1", "data_dir": "C:\\Consul\\data\\server-01", "log_level": "INFO", "node_name": "server-01", "server": true, "ports": { "http": 7771, "rpc": 7772, "dns": 7773, "serf_lan": 7774, "serf_wan": 7775, "server": 7776 } }
client-01.json
{ "datacenter": "dc1", "data_dir": "C:\\Consul\\data\\client-01", "log_level": "INFO", "node_name": "client-01", "ports": { "http": 8881, "rpc": 8882, "dns": 8883, "serf_lan": 8884, "serf_wan": 8885, "server": 8886 } }
作为 RPC Service 的 Provider 提供方，需要显式定义指定 Contract 的服务实例。例如，下面将不同的服务契约与服务实例进行了注册。
var serviceCatalog = new ServiceCatalogProvider(); serviceCatalog.RegisterService<IHelloService>(new HelloService()); serviceCatalog.RegisterService<ICalcService>(new CalcService()); serviceCatalog.RegisterService<IOrderService>(new OrderService());
实际上，可以通过对于 IServiceCatalogProvider 接口的不同实现，进行不同方式的本地服务发现和注册。例如，可以使用 Attribute 标记服务，通过对 Assembly 进行反射进行服务的实例化。
本地服务聚集到 Catalog 中后，系统会将服务逐个注册到 Service Directory 服务目录中，使得其他节点可以检索服务进行使用。
通过 IServiceDirectory 的抽象定义，可以与不同的目录方案进行集成。例如，使用 XML 配置文件的 LocalXmlFileServiceDirectory，使用 Consul 进行中心注册的 ConsulServiceDirectory。
使用 Consul 时，注册服务的 log 如下所示。
当 Redola 将服务注册至 Consul 中后，可通过 Consul 内置的 UI 进行查看。
http://localhost:8881/ui/#/dc1/services
通过 ConsulServiceDiscovery 实现 IServiceDiscovery 服务发现接口，从 Consul 检索指定服务类型的服务。
通过 Postman 测试 GET /v1/catalog/services，得到如下 JSON 数据。
http://localhost:8881/v1/catalog/services
{ "Redola.Rpc.TestContracts.ICalcService": [], "Redola.Rpc.TestContracts.IHelloService": [], "Redola.Rpc.TestContracts.IOrderService": [], "consul": [], "server": [] }
通过 Postman 测试 GET /v1/catalog/service，得到如下 JSON 数据。
http://localhost:8881/v1/catalog/service/Redola.Rpc.TestContracts.ICalcService
[ { "ID": "359e8dfe-262d-6eb7-260c-e6e3ad208a14", "Node": "client-01", "Address": "192.168.1.133", "Datacenter": "dc1", "TaggedAddresses": { "lan": "192.168.1.133", "wan": "192.168.1.133" }, "NodeMeta": {}, "ServiceID": "redola/server/server-33333/Redola.Rpc.TestContracts.ICalcService", "ServiceName": "Redola.Rpc.TestContracts.ICalcService", "ServiceTags": [], "ServiceAddress": "localhost", "ServicePort": 33333, "ServiceEnableTagOverride": true, "CreateIndex": 2147, "ModifyIndex": 2151 } ]
服务检索方，可通过指定 IServiceLoadBalancingStrategy 的具体实现实施不同的负载均衡策略，默认指定的是 IServiceLoadBalancingStrategy 随机选择。
为简化 RPC 调用发起方的封装，通常会使用 Dynamic Proxy 动态代理技术来动态生成给定契约的服务实例，将整体 RPC 的过程透明化。
例如，通过下面的代码来动态生成 ICalcService 的动态代理。
var calcClient = rpcNode.Resolve<ICalcService>();
目前 Redola.Rpc 默认集成了 Castle.Core 中的 Dynamic Proxy 模块，通过对实例方法的 Intercept 拦截进行 RPC 消息的收发处理。
当然，如需集成其他 Dynamic Proxy 类库，可通过 ISeviceProxyGenerator 接口进行方案实现。
Redola.Rpc 当前实现依赖了如下开源类库。
<?xml version="1.0" encoding="utf-8"?> <packages> <package id="Consul" version="0.7.2.3" targetFramework="net46" /> <package id="Cowboy.Sockets" version="1.3.14.0" targetFramework="net46" /> <package id="protobuf-net" version="2.0.0.668" targetFramework="net46" /> <package id="Castle.Core" version="4.1.0" targetFramework="net46" /> <package id="Logrila.Logging" version="1.0.3.0" targetFramework="net46" /> <package id="Logrila.Logging.NLogIntegration" version="1.0.3.0" targetFramework="net46" /> <package id="NLog" version="4.2.3" targetFramework="net46" /> </packages>
版权声明：本篇文章《Redola 集成 Consul 服务发现》由作者 Dennis Gao 发表自博客园个人技术博客，未经作者本人同意禁止以任何的形式转载，任何自动的或人为的爬虫转载行为均为耍流氓。
标签：博客 odm lan data ring 目的 策略 rem 方式
原文地址：http://www.cnblogs.com/gaochundong/p/redola_rpc_consul_integration.html
