作者|李志新1.什么是ProxylessService-Mesh？一、服务网格简析Istio是当今最流行的开源服务网格网格。它由控制平面和数据平面组成，其架构如下（图片来自Istio官网）。位于图中下半部分的控制平面负责配置、服务信息、证书等资源的下发。位于上部的数据平面关注服务间的通信流量；传统的服务网格通过代理拦截所有业务网络流量，代理需要感知控制平面下发的配置资源，从而按需控制网络流量的走向。在Istio环境中，它的控制平面是一个名为istiod的进程，网络代理是envoy。istiod通过监听Service、Endpoint等K8S资源获取服务信息，并将这些资源通过XDS协议发送给数据平面的网络代理。Envoy是一个独立的进程，以边车（sidecar）的形式与业务应用Pod一起运行。它与应用进程共享同一个主机网络，通过修改路由表劫持业务应用的网络流量。ServiceMesh可以解决微服务场景下的很多问题。随着集群规模的扩大和业务复杂度的增长，基于原生k8s的容器编排方案将难以应对，开发者不得不面临巨大的服务治理挑战。ServiceMesh很好的解决了这个问题。它将服务治理需求封装在控制面和代理中，业务开发者只需要关注业务逻辑。应用部署完成后，运维人员只需修改配置即可实现故障恢复、负载均衡、灰度发布等功能，大大提升研发迭代效率。Istio的sidecar通过容器注入的方式陪伴在业务应用流程的整个生命周期，对业务应用无侵入，解决了业务应用迁移、多语言、基础设施耦合等问题。但这也带来了资源消耗高、请求延迟增加的问题。Service为服务治理提供了一个很好的思路，将基础设施与业务逻辑解耦，让应用开发者只需要专注于业务。另一方面，由于sidecar的缺点，我们可以考虑用sdk代替sidecar来支持数据面。2、ProxylessService-MeshProxyless服务网格是Google在2018年提出的新概念，Isito、gRPC、brpc等开源社区都在这个方向进行了探索和实践。无代理服务网格框架由业务应用以SDK的形式引入，负责服务之间的通信和治理。来自控制面的配置直接下发给服务框架，服务框架替代了上面sidecar的功能。在无代理服务网格场景下，服务框架（SDK）的主要能力可以归纳为以下三点：与控制面对接、监控和配置资源。对接应用程序为开发者提供了方便的接口。连接到网络并根据资源变化响应流量规则。3、Proxyless的优缺点我觉得优点如下：性能：proxyless模式下的网络调用是点对点的直接通信，网络延迟会比proxy模式小很多。稳定性：proxyless模式是单进程，拓扑简单，调试方便，稳定性高。框架集成：市面上已经有很多sdk风格的服务框架。切换到mesh后，很容易复用框架已有的能力。资源消耗：没有sidecar，资源消耗低。当然缺点也很多：语言绑定：需要多语言开发的sdk可移植性低：无法通过切换sidecar的形式实现无入侵升级基础设施。总的来说，我觉得Proxyless架构更适合在生产环境中使用，因为它具有高性能和高稳定性。二、Dubbo-go和ProxylessService-Mesh1.Dubbo-go能力Apache/Dubbo-go(github.com/apache/dubbo-go)是一个分布式RPC框架，是Apache/Dubbo的Go语言实现。旨在为开发者提供便捷的微服务应用开发体验。Dubbo-go生态为Go开发者提供了敏捷的微服务编程接口、配置管理方案、服务治理方案等一系列工具和脚手架。开发者可以利用框架提供的能力快速开发自己的微服务应用。2、Dubbo-go在ProxylessService-Mesh场景下设计服务注册发现Dubbo-go本身具有可扩展的服务注册发现能力，我们针对ServiceMesh场景适配了注册中心的实现。开发者可以在istiod控制面注册du??bbo-go应用信息。客户端应用程序可以查询注册的接口数据来完成服务发现过程。由于Java的编程习惯，Dubbo-go生态框架的服务注册方式都是接口层面的。即客户端只需要导入接口即可发起调用，无需关心下游应用名称、主机名、IP地址等信息。相比之下，应用级服务注册发现，主流的微服务框架更多的是这种形式的服务调用方式，比如gRPC、K8S、Istio，应用级服务发现对应的是mesh场景，我觉得叫做“host”-级服务“Discovery”比较合适，这种调用方式需要客户端在导入接口的同时导入下游主机名和端口号，熟悉gRPC-go的同学一定很清楚，除了引入pb接口，在创建客户端时也需要调用gRPC.Dial("xxx")建立网络连接，这里xxx是下游主机名和端口号，这种服务发现和用户编程习惯导致了gRPC的ProxylessServiceMesh比较简单的实践，关于应用级服务发现和接口级服务发现的区别和dubbo生态的解决方案，就不赘述了不适于本文。可以参考刘军前辈写的文章《Dubbo 迈出云原生重要一步 应用级服务发现解析》简单来说，应用级服务发现需要开发者关心接口，除了应用名，注册中心冗余信息少；接口级服务发现的开发者只需要引入接口名称，而注册中心的冗余信息较多。熟悉Dubbo-go和Dubbo生态的用户在编程过程中不习惯指定下游主机名，更喜欢通过接口的引入直接发起RPC调用，而不管是哪个应用实现了接口。哪个主机，哪个虚拟集群。为了融入Istio系统，Dubbo-go对扩展的注册发现流程进行了特殊改造。除了复用Istio提供的EDS和CDS主机发现能力外，还增加了接口名到主机名的映射，并作为源数据注册在控制平面上。客户端在发起调用之前持有接口名称。客户端通过查询istiod上的元数据信息，得到接口名到主机名的映射，并转化为主机名；然后通过EDS、CDS和路由完成主机名到下游端点实例。转换。完成服务发现过程。下面用一个更详细的例子来说明服务发现的过程：开发者使用dubbogo-cli工具创建应用模板，发布Deployment/Service对到集群。服务器拉取全量的CDS和EDS数据，比对本地IP，得到当前应用的主机名。并在Istiod上注册此应用程序的所有接口名称到主机名的映射。客户端从istiod中拉取从完整接口名称到主机名的映射，并将其缓存在本地。当需要调用时，查询本地缓存，将接口名转换为主机名，然后通过CDS和EDS拉取到当前集群对应的全端点。所有端点都经过Dubbo-go内置的MeshRouter过滤出最终的端点子集，并根据配置的负载均衡策略进行请求。开发者或第三方组件通过操作K8S资源来控制Dubbo-go流量。在整个过程中，开发者全程只需要关注接口，完全不需要关心主机名和端口信息。即服务端开发者只需要实现pb接口，使用框架暴露即可；客户端开发者只需要引入pb接口，直接发起调用即可。大家可以按照本文第四部分的教程进行实验。流量管理Dubbo-go具备路由能力，通过xds协议客户端向istiod订阅路由配置，实时更新本地路由规则，实现服务管理。Dubbo-go兼容Istio生态的流量治理规则。通过配置VirtualService和DestinationRules，可以将标记后的流量路由到指定的子集，也可以在灰度发布、流量切换等场景中更深入的使用。云原生脚手架dubbogo-cli是Apache/dubbo-go生态的子项目，为开发者提供应用模板创建、工具安装、接口调试等便捷功能，提高用户研发效率。可以执行以下命令安装dubbogo-cli到$GOPATH/bingoinstallgithub.com/dubbogo/dubbogo-cli@latestdubbogo-cli支持以下能力：应用模板创建Demo创建编译、调试工具安装查看dubbo-go应用注册信息调试dubbo-go应用接口使用应用模板开发流程通过dubbogo-cli生成模板修改api/api.protomakeproto-gen开发接口修改makefile中的镜像名称和发布名称制作镜像推送修改在chart/app/values中部署相关的值配置makedeploy，使用helm发布应用。详情请参考dubbogo-cli文档[1]。三、Dubbo-go-Mesh的优势1.接口级服务发现上一篇介绍了通过接口级服务注册发现的优势，即开发者无需关心下游主机名和端口号，只需要需要引入接口存根，或者实现接口，通过框架启动即可。2.高性能我们在k8s集群中部署了Istio环境，测试了sidecar模式下的gRPC服务调用和Proxyless模式下的dubbo-go应用服务调用。发现proxyless在请求耗时上比sidecar模式少了一个数量级，也就是性能提升了十倍左右。3、跨生态Dubbo-go是一个跨多个生态的服务框架。Mesh生态开发者可以在使用Istio生态提供的强大能力的同时，使用Dubbo-go进行应用开发。gRPC生态Dubbo-go支持与gRPC服务互通，HTTP2协议栈。dubbo-go默认使用pb序列化方式，性能较高。Dubbo生态多语言优势，可实现go-java应用互通。兼容pixiu网关，方便服务暴露和协议转换。使用Dubbo-go生态组件。4、上手体验Dubbo-go-MeshDubbo-go目前支持兼容Istio的服务治理能力。支持基于Istio的接口级服务发现能力，兼容Istio生态流控和管理能力，提供脚手架和应用模板，提升Go应用开发效率。可以参考文档【Dubbo-go文档-Mesh任务】[2]搭建一套Dubbo-goMesh应用。在这组任务中，开发者将从部署Istio环境开始，创建应用模板，构建应用，发布应用，实现服务发现和RPC，最后完成流量规则的动态配置和观察流量切换。对框架用户具有很高的参考意义。五、展望下个版本的Dubbo-go会发布ProxylessServiceMesh能力。稳定的性能需要社区成员的共同关注和建设。在此基础上进一步探索轻量级sdk+sidecar模式；探索基于第三方流量治理组件的金丝雀发布能力；基于dubbo服务框架探索多语言服务网格和更丰富的网格生态组件兼容。Dubbo-go也将继续朝着云原生的方向前进，继续探索云计算时代的技术红利，与开发者同行。[1]:https://dubbogo.github.io/zh-cn/docs/user/refer/use_dubbogo_cli.html[2]:https://dubbogo.github.io/zh-cn/docs/user/tasks/网格/app.html
