DMicro
的设计思路DMicro
源码地址:
DMicro
诞生的背景,是因为我写了 10 来年的 PHP,想在公司内部推广 Go
, 公司内部的组件及 rpc 协议都是基于 swoole
定制化开发的。调研了市面上的各种框架,包括 beego
,goframe
,gin
,go-micro
,go-zero
,erpc
等等,可能是我当时技术能力有限,并不能让这些框架很好的适配我们的业务。
我们业务开发有几个痛点,在当时 golang
的生态中无法找到一整套解决方案。
tcp
,websocket
,quic
,unixsocket
.在对常用的开源框架做了简单的调研以后,发现并没有一款合适的框架能满足我的所有需求。在认真思考过后,发现 erpc
和 goframe
两个框架的结合体能满足我的需求,于是就诞生了自研 DMicro
.
DMicro
中的 drpc
组件的思想是参考 erpc
实现,甚至可以说是它的继承者。
drpc
组件是 DMicro
框架的一部分,为了适配 DMicro
框架,在 erpc
的基础上做了深入的扩展开发。
整个 DMicro
大量使用 goframe
中的组件,如果业务使用 goframe
框架,可以无缝接入。
DRpc
特性列表:
对等通信
, 对等Api
高性能
, 非阻塞异步IO
自定义Proto
,, 兼容http协议
, 自定义Codec
Hook点
, 插件系统
,Push消息
,session管理
,Socket抽象
,断线重连
, 过载保护
, 负载均衡
, 心跳机制
,平滑重启
...
DServer
特性列表:
快速构建
, 平滑重启
, 多进程支持
, 单/多进程一致
预定义命令行
,ctrl命令管理服务
可观测
, 可控制
, 应用沙盒
DMicro
已经内置组件:
Registry
服务注册Selector
服务发现Eventbus
事件总线Supervisor
进程管理Code gen
代码生成Tracing
链路追踪Metrics
统计告警Broker
限流熔断OpenAPI
文档自动生成对 DMicro
框架的设计,从设计之初就是在追求灵活性,适应性。在保证微服务的稳定性前提下,追求项目的开发效率。
无数个写 DMicro
的日夜,我都谨记开发三原则:
Clarity(清晰)
Simplicity(简单)
Productivity(生产力)
无论工作,还是做开源项目,都应该保持这三个原则,养成良好的习惯。
DMicro
秉承着万物皆接口的原则,提供框架无与伦比的扩展性.
下图展示的是消息的发送的流转流程,可以看到,所有的功能点都被抽象成了接口,每个功能点都提供了不同的实现.
会话 Session
大多数的 Rpc
框架并不强调会话 (session
) 的概念,因其应用场景不需要用到会话 (session
). 那么 drpc
为什么需要抽象出会话 (session
) 呢?
Endpoint
融合了 Client
和 Server
, 需要提供相同的 Api
.服务端
需要主动向客户端
发送消息,并且获取客户端的响应.服务端
支持对多个客户端
批量发送消息.一个
或多个
会话.文件描述符
, 对其进行性能调优.数据/属性
.Session
抽象了整个 drpc
框架的会话,把 Socket
,Message
,Context
都融合到一起。开发者只需要对 session
进行操作,就能实现大多数需求.
Session
接口可以细分为 4 个 interface{}
, 分别是 EarlySession
,BaseSession
,CtxSession
,Session
. 对应的是应用的不同生命阶段会话 (Session
) 拥有的不同属性.
EarlySession
表示刚生成会话,尚未启动 goroutine 读取数据的阶段.BaseSession
只有最基础的方法,用于关闭连接时候的插件参数.CtxSession
在处理程序上下文中传递的会话对象.Session
全功能的会话对象.正常情况下,开发者用到的都是 Session
,CtxSession
这两个接口,其他 2 个接口是在插件中使用.
消息 Message
消息 Message
包含消息头 Header
, 消息体 Body
, 是客户端与服务端之间通信的实体.
Message interface{}
抽象了对通信实体的操作.
Size
消息的长度Transfer-Filter-Pipeline
报文数据过滤处理管道Seq
序列号MType
消息类型ServiceMethod
资源标识符Meta
消息的元数据BodyCodec
消息体编码格式Body
消息体协议 Proto
协议是对消息Message
对象的序列化和反向序列化,框架提供 Proto
接口。只需要实现该接口,开发者就能定制符合业务需求的自定义协议,从而提升了框架的灵活性.
接口的定义如下:
type Proto interface {
Version() (byte, string)
Pack(Message) error
Unpack(Message) error
}
Version()
返回该协议的 id 和名字,两个组成唯一的版本号.Pack
对消息 Message
对象进行序列化.Unpack
对字节流反序列化,生成一个消息 Message
对象.目前框架已支持 Http
,Json
,Raw
,Protobuf
,JsonRpc
这 5 个协议.
RAW
协议组成如下:
其他协议可以参考代码.
编码 Codec
作为一个通用性的框架,支持的协议可以有多种,消息体的编解码也可以有多少种. drpc
使用 Codec
接口对消息体 Body 进行编解码.
接口的定义如下:
type Codec interface {
ID() byte
Name() string
Marshal(interface{}) ([]byte, error)
Unmarshal([]byte, interface{}) error
}
ID
返回编 Codec 的 idName
返回编 Codec 的名字,名字是为了开发者更容易识别.Marshal
对消息内容进行编码Unmarshal
对消息内容进行解码目前框架已支持 Form
,Json
,plain
,Protobuf
,XML
这 5 个编解码.
连接 Socket
Socket
扩展了 net.Conn
, 并且抽象出接口,方便框架对底层网络协议的集成.
Socket
接口实现了一部分 Session
接口的功能,Session
接口调用的一些方法,实际上是转发调用了 Socket
中的方法.
这样的分层实现,让 Socket
拥有的集成其他协议的能力.
TCP V4
,TCP V6
Unix Socket
KCP
QUIC
支持对连接的性能调优.
SetKeepAlive
开启链接保活SetKeepAlivePeriod
链接保活间隔时间SetReadBuffer
设置链接读缓冲区 sizeSetWriteBuffer
获取链接写缓冲区 sizeSetNoDelay
开启关闭 no delay 算法ControlFD
支持操作链接的原始句柄前面讲到,DMicro
框架万物皆接口,分层 + 接口的设计,让 DMicro
有了灵活的组成高效且符合业务实际情况的能力.
接下来我们要讲到实现这些能力的基础。插件系统.
插件 Plugin
插件系统给框架带来了极大的扩展性和灵活性,是整个框架的一个灵魂模块,有了它,框架就有了无限可能。
什么样的插件系统才能算是优雅呢?我能想到的有以下几点:
hook
位置,能够覆盖整个框架的生命周期,贯穿通讯的各个环节。hook
位置的入参和出参都是经过精心设计。hook
位置,每个 hook
位置都能被多个插件使用。在 drpc
中,钩子贯穿与整个 Endpoint
的生命周期,是它不可或缺的重要一环。
转存失败重新上传取消 通过这些钩子 Hook
点,赋予了插件无限可能.
组件
有了插件,就能通过插件的组合,编写综合功能的组件,目前框架提供一些内置的组件,
服务端 Rpc Server
客户端 Rpc Client
服务注册 Registry
服务发现 Selector
事件总线 EventBus
进程管理 Supervisor
即将提供:
链路追踪 Tracing
统计告警 Metrics
限流熔断 Broker
.限于篇幅的原因,具体组件的实现,这里就不深入讲解,请关注后续的文章.
如果把 DMicro
比作人生,现在成长的阶段还处在少年时期,只完成了基础的架构设计和一部分组件的开发.
接下来的方向主要是往易用性和可靠性方向发展.
易用性:
dmctl
工具的开发,包括代码生成,项目结构生成,打包,编译等等功能.可靠性:
希望 DMicro
能在大家的呵护及鞭策下茁长成长.