Dubbo: Dubbo走向Service mesh

[NameHaibinZhang]

Dubbo支持Service mesh讨论
当前微服务框架大体分为两代，第一代是以dubbo、spring cloud为主的入侵式的框架，第二代是以service mesh为主的非入侵式框架，官方推荐使用istio + envoy，当然也有很多其他的版本。
Dubbo作为第一代的RPC框架在中国java的圈子内有很高的地位，能够满足服务治理、远程调用、服务注册、服务发现等一系列的微服务使用场景，拥有众多的使用者。那么第二代service mesh相比于第一代有哪些好处呢？我们先看下Dubbo在目前在生产中遇到的问题：
1、Dubbo的SDK升级问题，这个问题相信很多的dubbo使用者都会遇到，比如如果你所在的公司在生产使用的是2.5.X版本，官方提供了2.6.X版本，你作为公司的dubbo开发者，希望升级版本能够使用更多的功能和特性，这时候你需要去推动公司所有的业务发升级版本，如果你的微服务个数不多，还比较快，如果你是几千个、上万、甚至几万个微服务，升级工作量大，推进难度更大。
2、多语言的问题，当前开发者使用的语言众多，比如nodejs、php、python、java、go、C++、rust等等，dubbo对于多语言的支持上目前不是很理想。
3、与k8s结合的问题，越来越多的企业的服务上云，k8s被认为是云时代的操作系统，k8s是以service + pod作为服务注册发现和服务调用的基本单元，而dubbo是以interface + method作为注册发现和调用的单元，无法更好的使用k8s的特性。
以上总结的三个问题应该是很多开发人员会遇到的问题，service mesh在上述三个问题上都有了自己的解决方案，首先升级问题，service mesh使用sidecar + istio的方式部署，sidecar的部署方式是与应用部署在同一个pod的不同容器中，所有的服务间通信的任务都交给sidecar处理，sidecar的升级对于业务而言无感知；其次，sidecar中目前支持了大部分的通用协议，能够满足不同的语言的互相调用，但是目前对dubbo这样的私有化协议暂时没有支持；最后service mesh原生支持k8s部署。
当然service mesh也有自己的缺点，比如调用系统更复杂，需要从consumer先到sidecar，然后sidecar到sidecar，最后是sidecar到provider，调用链路更长，会有性能的损耗，目前istio在积极的迭代，使其性能满足生产的需求。
Dubbo能不能成为service mesh中的sidecar呢，成为sidecar有以下几个关键点：首先，dubbo需要作为独立的应用能够部署在容器中，其次，支持Xds Api，最后支持服务治理的路由规则。前面两个点实现上不难，最后一点，由于dubbo是一个私有化的协议，设计之初就没有什么协议头的概念，服务调用的信息都是在payload中，istio中很多的服务治理的规则都是基于协议头部提供的数据，dubbo协议无法满足这样的要求，这里抛出两个思路：
1、 用grpc协议（http2协议）来包装dubbo协议。
2、 Dubbo支持http2的协议。

关于dubbo如何mesh的问题，欢迎大家讨论。

[Moriadry]

我认为 用gRpc协议（http2协议）来包装dubbo协议 是很好的选择，本身gRpc较为通用，同时有google在支持、迭代。相信会让dubbo在service mesh的道路上更稳步、快速的前进。
通过利用gRpc stub/channel layer层的协议转换，我认为可以实现您所说的这个转换为基于协议头的目标，本人对gRpc有些经验，希望有幸提供自己的一份力量~!

[NameHaibinZhang]

特别是当有跨语言调用的需求时候，grpc目前对主流的语言都有支持，java服务可以通过dubbo的grpc接口暴露自己的接口提供给不同语言的client端调用

[walter211]

什么时候整个rust-dubbo的啊

[kun-song]

个人认为，Dubbo 支持 Service Mesh 有两种方式：

1. 贡献 Istio，使其原生支持 Dubbo 协议；
2. 封装 Istio，在上面做二次开发，增强其功能，同时支持 Dubbo；

个人以为第二种方式更实际可行。

[NameHaibinZhang]

个人认为，Dubbo 支持 Service Mesh 有两种方式：

1. 贡献 Istio，使其原生支持 Dubbo 协议；
2. 封装 Istio，在上面做二次开发，增强其功能，同时支持 Dubbo；

个人以为第二种方式更实际可行。

istio本身是控制面板，不涉及协议方面的问题，是dubbo需要支持istio的XDS API接口，而且istio做二次开发不符合社区的发展，也不利于dubbo本身的推广

[NameHaibinZhang]

什么时候整个rust-dubbo的啊

如果有rust语言的developer可以做这个事情，可以出版本后贡献给社区，rust语言目前比较小众，go语言的dubbo版本在开发中，很快会支持go语言

[walter211]

什么时候整个rust-dubbo的啊

如果有rust语言的developer可以做这个事情，可以出版本后贡献给社区，rust语言目前比较小众，go语言的dubbo版本在开发中，很快会支持go语言

https://github.com/dubbo/go-for-apache-dubbo 是这个么

[kun-song]

个人认为，Dubbo 支持 Service Mesh 有两种方式：

1. 贡献 Istio，使其原生支持 Dubbo 协议；
2. 封装 Istio，在上面做二次开发，增强其功能，同时支持 Dubbo；

个人以为第二种方式更实际可行。

istio本身是控制面板，不涉及协议方面的问题，是dubbo需要支持istio的XDS API接口，而且istio做二次开发不符合社区的发展，也不利于dubbo本身的推广

Dubbo 本身作为服务化框架不适合作为单纯的 proxy，首先 proxy 对性能、内存使用等方面要求较高，为每个 Pod 部署一个 JVM proxy 的开销太大，而且 Linkerd 教训在前，最重要的是 Dubbo 本身也不是专注做该功能的，需要完全重新开发，因此实现 xDS API 可能并不合理，个人认为合理的方式是数据平面采用成熟的 Envoy，并向 Envoy 贡献 Dubbo 协议的解析支持（类似 Envoy 已经支持的 HTTP1.1/2 和 gRPC）。

控制平面直接采用 or 部分采用 Istio，如果做二次开发的确面临一些问题，不过现在 Istio 也并不成熟，所不定可以走出一条独特的套路。

以上均为个人观点。

[Jeff-Lv]

Envoy is almost support Dubbo protocol, please check this pr from Envoy:
https://github.com/envoyproxy/envoy/issues/3998
It seems that this is a better choice for Dubbo with Service Mesh

Kun Song [e-mail] 于2019年5月10日周五 下午3:17写道：

个人认为，Dubbo 支持 Service Mesh 有两种方式：

1. 贡献 Istio，使其原生支持 Dubbo 协议；
2. 封装 Istio，在上面做二次开发，增强其功能，同时支持 Dubbo；

个人以为第二种方式更实际可行。

istio本身是控制面板，不涉及协议方面的问题，是dubbo需要支持istio的XDS
API接口，而且istio做二次开发不符合社区的发展，也不利于dubbo本身的推广

Dubbo 本身作为服务化框架不适合作为单纯的 proxy 的，因为 proxy 对性能、内存使用等方面要求较高，而且 Dubbo
本身也不是专注做该功能的，需要完全重新开发，因此实现 xDS API 可能并不合理，个人认为合理的方式是数据平面采用成熟的 Envoy，并向
Envoy 贡献 Dubbo 协议的解析支持（类似 Envoy 已经支持的 HTTP1.1/2 和 gRPC）。

控制平面直接采用 or 部分采用 Istio，如果做二次开发的确面临一些问题，不过现在 Istio 也并不成熟，所不定可以走出一条独特的套路。

以上均为个人观点。

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/apache/incubator-dubbo/issues/3905#issuecomment-491184729,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ABNZCEYRULP7ENH2BSL2EA3PUUOQ7ANCNFSM4HHOB6DQ
.

[kun-song]

Envoy is almost support Dubbo protocol, please check this pr from Envoy: envoyproxy/envoy#3998 It seems that this is a better choice for Dubbo with Service Mesh Kun Song [e-mail] 于2019年5月10日周五 下午3:17写道：
…
个人认为，Dubbo 支持 Service Mesh 有两种方式： 1. 贡献 Istio，使其原生支持 Dubbo 协议； 2. 封装 Istio，在上面做二次开发，增强其功能，同时支持 Dubbo； 个人以为第二种方式更实际可行。 istio本身是控制面板，不涉及协议方面的问题，是dubbo需要支持istio的XDS API接口，而且istio做二次开发不符合社区的发展，也不利于dubbo本身的推广 Dubbo 本身作为服务化框架不适合作为单纯的 proxy 的，因为 proxy 对性能、内存使用等方面要求较高，而且 Dubbo 本身也不是专注做该功能的，需要完全重新开发，因此实现 xDS API 可能并不合理，个人认为合理的方式是数据平面采用成熟的 Envoy，并向 Envoy 贡献 Dubbo 协议的解析支持（类似 Envoy 已经支持的 HTTP1.1/2 和 gRPC）。 控制平面直接采用 or 部分采用 Istio，如果做二次开发的确面临一些问题，不过现在 Istio 也并不成熟，所不定可以走出一条独特的套路。 以上均为个人观点。 — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#3905 (comment)>, or mute the thread https://github.com/notifications/unsubscribe-auth/ABNZCEYRULP7ENH2BSL2EA3PUUOQ7ANCNFSM4HHOB6DQ .

Thank you Jeff, so the Envoy is already supporting Dubbo protocol now, bravo!

[walter211]

beg for a rust lib

[linruibo]

lstio作为云原生，拥有数据面板和控制面板，以及3各组件来实现分布式服务的路由，负载，熔断等，那么与dubbo的rpc私有协议能怎样的集成呢？？？