DMicro 中的 drpc 组件的思想是参考 erpc 实现，甚至可以说是它的继承者。
drpc 组件是 DMicro 框架的一部分，为了适配 DMicro 框架，在 erpc 的基础上做了深入的扩展开发。
整个 DMicro 大量使用 goframe 中的组件，如果业务使用 goframe 框架，可以无缝接入。
DRpc 特性列表:
DServer 特性列表：
DMicro 已经内置组件：
对 DMicro 框架的设计，从设计之初就是在追求灵活性，适应性。在保证微服务的稳定性前提下，追求项目的开发效率。
无数个写 DMicro 的日夜，我都谨记开发三原则:
无论工作，还是做开源项目，都应该保持这三个原则，养成良好的习惯。
DMicro 秉承着万物皆接口的原则，提供框架无与伦比的扩展性.
下图展示的是消息的发送的流转流程，可以看到，所有的功能点都被抽象成了接口，每个功能点都提供了不同的实现.
大多数的 Rpc 框架并不强调会话 ( session ) 的概念，因其应用场景不需要用到会话 ( session ). 那么 drpc 为什么需要抽象出会话 ( session ) 呢？
Session 抽象了整个 drpc 框架的会话，把 Socket , Message , Context 都融合到一起。开发者只需要对 session 进行操作，就能实现大多数需求.
Session 接口可以细分为 4 个 interface{} , 分别是 EarlySession , BaseSession , CtxSession , Session . 对应的是应用的不同生命阶段会话 ( Session ) 拥有的不同属性.
正常情况下，开发者用到的都是 Session , CtxSession 这两个接口，其他 2 个接口是在插件中使用.
消息 Message 包含消息头 Header , 消息体 Body , 是客户端与服务端之间通信的实体.
Message interface{} 抽象了对通信实体的操作.
协议是对 消息Message 对象的序列化和反向序列化，框架提供 Proto 接口。只需要实现该接口，开发者就能定制符合业务需求的自定义协议，从而提升了框架的灵活性.
接口的定义如下:
type Proto interface {
Version() (byte, string)
Pack(Message) error
Unpack(Message) error}
目前框架已支持 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
}
目前框架已支持 Form , Json , plain , Protobuf , XML 这 5 个编解码.
Socket 扩展了 net.Conn , 并且抽象出接口，方便框架对底层网络协议的集成.
Socket 接口实现了一部分 Session 接口的功能， Session 接口调用的一些方法，实际上是转发调用了 Socket 中的方法.
这样的分层实现，让 Socket 拥有的集成其他协议的能力.
支持对连接的性能调优.
前面讲到， DMicro 框架万物皆接口，分层 + 接口的设计，让 DMicro 有了灵活的组成高效且符合业务实际情况的能力.
接下来我们要讲到实现这些能力的基础。插件系统.
插件系统给框架带来了极大的扩展性和灵活性，是整个框架的一个灵魂模块，有了它，框架就有了无限可能。
什么样的插件系统才能算是优雅呢？我能想到的有以下几点：
在 drpc 中，钩子贯穿与整个 Endpoint 的生命周期，是它不可或缺的重要一环。
通过这些 钩子 Hook 点，赋予了插件无限可能.
有了插件，就能通过插件的组合，编写综合功能的组件，目前框架提供一些内置的组件，
即将提供:
关注微信
