Jump to Navigation

gRPC服务注册的建议

gRPC服务注册的建议

注册信息服务器

使用分布式配置服务etcd,解决配置信息的分布式存储与一致性保证。

服务的端口

建议尽量使用动态的服务端口,节省服务端口的配置的工作。

比如,给一个端口的范围,[5000,6000],服务启动时选择一个可用的端口并监听服务。

由于服务端口总是需要注册到etcd的,所以,手工指定配置的端口和动态选择的端口没有区别。

当然,初期可以不用实现的这么复杂,建议在程序中指定某个固定的服务端口。

心跳方式注册

为了能够保证etcd中存储的API信息的有效性,建议实现心跳机制定时刷新API的注册信息。

根据看到的一些说明,建议心跳时间在,10-30秒,初步使用20秒的心跳值。

并且,在心跳时刷新时,尽量能够根据实际服务运行状态。对于服务不响应的情况,也就不需要注册。

注册到etcd的API信息

存储在etcd中的key信息:

建议格式: /dorpc/service_name/version/

其中,dorpc为固定标识,该key下是一些gRPC服务API信息。

server_name为服务名称,与.proto中的package.message对应,如flyrun.FlyRun。

version为API的版本号,如1.0、2.0。并且建议版本号如无需要,不要太多级版本,像1.2.3.4。

API信息value值:

建议使用JSON格式,字段如下,

{
    "hosts" :["10.0.97.3:5000", "10.0.96.3:5000", "10.0.97.3:5001"],
    "desc": "run php code online",
}

该格式是最基本的API信息,格式上可能不完善,有可能将变化。

该注册格式的数据,建议应该由服务注册模块的封装库实现。

对于可能有多语言实现的服务的情况下,虽然需要由不同的编程语言实现,但最好保持机制上一致。

对于每种项目所用的开发语言,应该提供客户端的抽象封装,服务端的注册抽象封装,

以便保持编写服务时的简单性,一致性。

客户端封装功能点建议

建议封装本次gRPC请求所使用的host,即根据注册信息中的hosts值,

按照某算法,选择一个可用的当前有效的host,返回客户端使用。

其中包括注册信息的解析。

服务端封装功能点建议

建议封装注册信息的打包功能,使用etcd客户端写入etcd服务中。

建议参封装心跳机制的实现,供服务调用。

建议目前优先考虑golang与php两种语言的实现,实现机制以以上建议为基础吧。

如有建议可PR联系。

添加新评论

Plain text

  • 不允许HTML标记。
  • 自动将网址与电子邮件地址转变为链接。
  • 自动断行和分段。
CAPTCHA
This question is for testing whether or not you are a human visitor and to prevent automated spam submissions.
Image CAPTCHA
Enter the characters shown in the image.


Main menu 2

Story | by Dr. Radut