Dubbo2.0 协议直接定义在 TCP 传输层协议上,为协议功能定义提供了最大的灵活 性,但同时也正是因为这样明显的灵活性优势,RPC 协议普遍都是定制化的私有协议。Dubbo 协议体 Body 中有一个可扩展的 attachments 部分,这给 RPC 方法之外 额外传递附加属性提供了可能,是一个很好的设计。但是类似的 Header 部分,却缺少类 似的可扩展 attachments,这点可参考 HTTP 定义的 Ascii Header 设计,将 Body Attachments 和 Header Attachments 做职责划分。 Body 协议体中的一些 RPC 请求定位符如 Service Name、Method Name、 Version 等,可以提到 Header 中,和具体的序列化协议解耦,以更好的被网络基础 设施识别或用于流量管控。 扩展性不够好,欠缺协议升级方面的设计,如 Header 头中没有预留的状态标识位, 或者像 HTTP 有专为协议升级或协商设计的特殊 packet。 在 Java 版本的代码实现上,不够精简和通用。如在链路传输中,存在一些语言绑定 的内容;消息体中存在冗余内容,如 Service Name 在 Body 和 Attachments 中 都存在。
Dubbo是一个分布式服务框架,致力于提供高性能和透明化的RPC远程服务调用方案,以及SOA服务治理方案。简单的说,dubbo就是个服务框架,如果没有分布式的需求,其实是不需要用的,只有在分布式的时候,才有dubbo这样的分布式服务框架的需求,并且本质上是个服务调用的东东,说白了就是个远程服务调用的分布式框架(告别Web Service模式中的WSdl,以服务者与消费者的方式在dubbo上注册)
版权声明:本文内容由阿里云实名注册用户自发贡献,版权归原作者所有,阿里云开发者社区不拥有其著作权,亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容,填写侵权投诉表单进行举报,一经查实,本社区将立刻删除涉嫌侵权内容。
阿里云拥有国内全面的云原生产品技术以及大规模的云原生应用实践,通过全面容器化、核心技术互联网化、应用 Serverless 化三大范式,助力制造业企业高效上云,实现系统稳定、应用敏捷智能。拥抱云原生,让创新无处不在。