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
秉承着万物皆接口的原则,提供框架无与伦比的扩展性.
下图展示的是消息的发送的流转流程,可以看到,所有的功能点都被抽象成了接口,每个功能点都提供了不同的实现.
大多数的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
消息体协议是对消息 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
协议组成如下:
其他协议可以参考代码.
作为一个通用性的框架,支持的协议可以有多种,消息体的编解码也可以有多少种.
drpc
使用Codec
接口对消息体 Body 进行编解码.
接口的定义如下:
type Codec interface {
ID() byte
Name() string
Marshal(interface{}) ([]byte, error)
Unmarshal([]byte, interface{}) error
}
ID
返回编解码器的 idName
返回编解码器的名字,名字是为了开发者更容易识别.Marshal
对消息内容进行编码Unmarshal
对消息内容进行解码目前框架已支持Form
,Json
,plain
,Protobuf
,XML
这 5 个编解码.
Socket
扩展了net.Conn
,并且抽象出接口,方便框架对底层网络协议的集成.
Socket
接口实现了一部分Session
接口的功能,Session
接口调用的一些方法,实际上是转发调用了Socket
中的方法.
这样的分层实现,让Socket
拥有的集成其他协议的能力.
TCP V4
,TCP V6
Unix Socket
KCP
QUIC
支持对连接的性能调优.
SetKeepAlive
开启链接保活SetKeepAlivePeriod
链接保活间隔时间SetReadBuffer
设置链接读缓冲区长度SetWriteBuffer
获取链接写缓冲区长度SetNoDelay
开启关闭 no delay 算法ControlFD
支持操作链接的原始句柄前面讲到,DMicro
框架万物皆接口,分层+接口的设计,让DMicro
有了灵活的组成高效且符合业务实际情况的能力.
接下来我们要讲到实现这些能力的基础.插件系统.
插件系统给框架带来了极大的扩展性和灵活性,是整个框架的一个灵魂模块,有了它,框架就有了无限可能。
什么样的插件系统才能算是优雅呢?我能想到的有以下几点:
hook
位置,能够覆盖整个框架的生命周期,贯穿通讯的各个环节。hook
位置的入参和出参都是经过精心设计。hook
位置,每个hook
位置都能被多个插件使用。在drpc
中,钩子贯穿与整个Endpoint
的生命周期,是它不可或缺的重要一环。
通过这些钩子 Hook
点,赋予了插件无限可能.
有了插件,就能通过插件的组合,编写综合功能的组件,目前框架提供一些内置的组件,
服务端 Rpc Server
客户端 Rpc Client
服务注册 Registry
服务发现 Selector
事件总线 EventBus
进程管理 Supervisor
即将提供:
链路追踪 Tracing
统计告警 Metrics
限流熔断 Broker
.限于篇幅的原因,具体组件的实现,这里就不深入讲解,请关注后续的文章.
如果把DMicro
比作人生,现在成长的阶段还处在少年时期,只完成了基础的架构设计和一部分组件的开发.
接下来的方向主要是往易用性和可靠性方向发展.
易用性:
dmctl
工具的开发,包括代码生成,项目结构生成,打包,编译等等功能.可靠性:
希望DMicro
能在大家的呵护及鞭策下茁长成长.
开源不易,需要更多小伙伴加入,共创DMicro
.
如果你希望使用DMicro
,赶快引入代码,搭建你的第一个新项目吧!
如果你也想为DMicro
生态添砖加瓦,赶快Fork
代码,给我们提交pr
吧!
这是一个专为移动设备优化的页面(即为了让你能够在 Google 搜索结果里秒开这个页面),如果你希望参与 V2EX 社区的讨论,你可以继续到 V2EX 上打开本讨论主题的完整版本。
V2EX 是创意工作者们的社区,是一个分享自己正在做的有趣事物、交流想法,可以遇见新朋友甚至新机会的地方。
V2EX is a community of developers, designers and creative people.