购物网站源码,查询网站备案进度,民营医院建设网站,四川大良网站建设简介#xff1a;Proxyless Service Mesh 能力将跟随 Dubbo-go 下一版本发布#xff0c;稳定的性能需要社区成员们共同的关注与建设。在此基础之上#xff0c;我们还会进一步探索轻量级 sdk sidecar的模型#xff1b;探索基于第三方流量治理组件的金丝雀发布能力#xff1…简介Proxyless Service Mesh 能力将跟随 Dubbo-go 下一版本发布稳定的性能需要社区成员们共同的关注与建设。在此基础之上我们还会进一步探索轻量级 sdk sidecar的模型探索基于第三方流量治理组件的金丝雀发布能力探索基于 dubbo 服务框架的多语言 sevice mesh、与更丰富的 mesh 生态组件兼容。 作者 | 李志信 来源 | 阿里开发者公众号
一 什么是 Proxyless Service-Mesh (无代理服务网格) ?
1 Service Mesh 简析
Istio 是当今最流行的开源服务网格。它由控制平面和数据平面构成其架构如下图片摘自 Istio官网。 位于图中下半部分的控制平面负责配置、服务信息、证书等资源的下发。位于上半部分的数据平面关注业务之间的通信流量传统服务网格通过代理的方式拦截所有的业务网络流量代理需要感知到控制平面下发的配置资源从而按照要求控制网络流量的走向。
在 Istio 环境中其控制平面是一个名为 istiod 的进程网络代理是 envoy 。istiod 通过监听 K8S 资源 例如Service、Endpoint 等获取服务信息并将这些资源统一通过 XDS 协议下发给位于数据平面的网络代理。envoy 是一个独立的进程以 sidecar边车的形式伴随业务应用 Pod 运行他与应用进程共用同一个主机网络并通过修改路由表的方式劫持业务应用的网络流量。
Service Mesh 可以解决微服务场景下的众多问题随着集群规模的扩大与业务复杂度的增长基于原生 k8s 的容器编排方案将会难以应付开发人员不得不面对巨大的服务治理挑战。而 Service Mesh 很好地解决了这一问题它将服务治理需求封装在了控制平面与代理中业务开发人员只需要关注于业务逻辑。在应用部署之后只需要运维人员通过修改配置即可实现例如故障恢复、负载均衡、灰度发布等功能这极大地提高了研发和迭代效率。
Istio 的 sidecar 通过容器注入的形式伴随业务应用进程的整个生命周期对于业务应用是毫无侵入的这解决了业务应用可迁移、多语言、基础架构耦合等问题。但这也带来了高资源消耗、请求时延增长的问题。
Service 为服务治理提供了一个很好的思路将基础架构与业务逻辑解耦让应用开发人员只需关注业务。另一方面由于 sidecar 的弊端我们可以考虑使用 sdk 的形式来替代 sidecar 支撑起数据平面。
2 Proxyless Service-Mesh
无代理服务网格是2018年谷歌提出的一个新的概念Isito、gRPC、brpc 等开源社区都在这一方向进行了探索和实践。无代理服务网格框架以 SDK 的形式被业务应用引入负责服务之间的通信、治理。来自控制平面的配置直接下发至服务框架由服务框架代替上述 sidecar 的功能。 在无代理服务网格场景下服务框架SDK的主要能力可以概括为以下三点
对接控制平面监听配置资源。对接应用为开发者提供方便的接口。对接网络根据资源变动响应流量规则。
3 Proxyless 的优缺点
我认为优点如下
性能无代理模式的网络调用为点对点的直接通信网络时延会比代理模式小很多。稳定性proxyless 的模式是单进程拓扑简单便于调试稳定性高。框架集成市面上已有众多 sdk 模式的服务框架切换至 mesh 后便于复用框架已有能力资源消耗没有 sidecar资源消耗低。
当然缺点也有很多
语言绑定需要开发多种语言的 sdk可迁移性低无法通过切换 sidecar 的形式来无侵入地升级基础设施。
总体来讲我认为 Proxyless 架构以其高性能、高稳定性的特点更适合与生产环境使用。
二 Dubbo-go 与 Proxyless Service-Mesh
1 Dubbo-go 的能力
Apache/Dubbo-go (github.com/apache/dubbo-go)是一款分布式 RPC 框架是 Apache/Dubbo 的 Go 语言实现。旨在为开发者提供便利的微服务应用开发体验。Dubbo-go 生态为 Go 开发者提供了敏捷的微服务编程接口、配置管理方案、服务治理方案、以及一系列工具与脚手架开发人员可以使用框架提供的能力快速开发自己的微服务应用。
2 Dubbo-go 在 Proxyless Service-Mesh 场景的设计
服务注册发现
Dubbo-go 本身拥有可扩展的服务注册发现能力我们为 service mesh 场景适配了注册中心的实现。开发人员可以将 dubbo-go 应用的信息注册在 istiod 控制平面上。客户端应用可以查询已经注册的接口数据完成服务发现过程。
归因于 Java 的编程习惯Dubbo-go 生态框架的服务注册方式都是接口级别的。即客户端只需要引入接口即可发起调用而无需关心下游的应用名、主机名、IP 地址等信息。与之相对的是应用级别的服务注册发现主流微服务框架更多这种形式的服务调用方式例如 gRPC、K8S、Istio应用级服务发现对应到 mesh 场景下我认为叫 “主机级别服务发现”更合适这种调用方式需要客户端在引入接口的同时还需引入下游的主机名和端口号。熟悉 gRPC-go 的同学一定很清楚除了引入 pb 接口还需要在创建客户端时调用 gRPC.Dial(xxx) 建立网络连接。而这里的 xxx 就是下游的主机名和端口号这种服务发现的类型和用户编程习惯导致了 gRPC 较为轻松地实践了 Proxyless Service Mesh。
关于应用级服务发现与接口级服务发现的区别和 dubbo 生态的解决方案本文中不多赘述可以参考刘军前辈写的文章文章《Dubbo 迈出云原生重要一步 应用级服务发现解析》 简单来说应用级服务发现需要开发者关心接口之外还要关心应用名注册中心的冗余信息较少接口级服务发现开发者只需要引入接口名但注册中心的冗余信息较多。
熟悉 Dubbo-go、Dubbo 生态的用户不习惯于在编程的过程中指定下游主机名更希望以接口引入的方式直接发起 RPC 调用而不需关心究竟这个接口被哪个应用实现运行在哪台主机、哪个虚拟集群上。
Dubbo-go 为了融入 Istio 体系将扩展出来的注册发现流程进行了特殊改造。在复用 Istio 提供的 EDS、CDS 主机发现的能力之外增加了接口名到主机名的映射作为源数据注册在了控制平面上。客户端在发起调用前持有接口名通过查询istiod 上的元数据信息拿到接口名到主机名到映射转换为主机名再通过EDS、CDS和路由完成主机名到下游端点实例的转换。完成服务发现流程。
下面用一个更详细的例子来说明服务发现过程 开发人员使用 dubbogo-cli 工具创建应用模板发布 Deployment / Service pair 到集群中。服务端拉取全量 CDS 和 EDS 数据比对本机 IP拿到当前应用的的主机名。并将本应用的所有接口名到主机名的映射注册在 Istiod 上面。客户端从 istiod 拉取全量接口名到主机名的映射缓存在本地。当需要发起调用时查询本地缓存将接口名转换为主机名再通过CDS 和 EDS 拉取到当前 cluster 所对应的全量端点。全量端点经过 Dubbo-go 内置的 Mesh Router筛选出最终的端点子集并按照配置的负载均衡策略进行请求。开发人员或者第三方组件通过操作 K8S 资源控制 Dubbo-go 流量。
纵观这一过程开发人员全程只需要关注接口即可完全无需关心主机名和端口信息。即服务端开发者只需要实现pb接口使用框架暴露出来客户端开发者只需要引入pb接口直接发起调用即可可以跟随本文第四部分的教程来动手实验一下。
流量治理
Dubbo-go 拥有路由能力通过 xds 协议客户端从 istiod 订阅路由配置并实时更新至本地路由规则从而实现服务的管理。Dubbo-go 兼容 Istio 生态的流量治理规则可以通过配置 Virtual Service 和 Destination Rule将打标的流量路由至指定子集也可以在灰度发布、切流等场景进行更深入地使用。
云原生脚手架
dubbogo-cli 是 Apach/dubbo-go 生态的子项目为开发者提供便利的应用模板创建、工具安装、接口调试等功能以提高用户的研发效率。
可以执行以下指令安装dubbogo-cli 至 $GOPATH/bin
go install github.com/dubbogo/dubbogo-clilatestdubbogo-cli 支持以下能力
应用模板创建Demo 创建编译、调试工具安装查看 dubbo-go 应用注册信息调试 dubbo-go 应用接口
使用应用模板的开发流程
通过 dubbogo-cli 生成模板修改api/api.protomake proto-gen开发接口修改 makefile 内镜像名和发布名打镜像并推送修改chart/app/values 内与部署相关的value配置make deploy, 使用 helm 发布应用。
详情可以参阅 dubbogo-cli 文档[1]。
三 Dubbo-go-Mesh 的优势
1 接口级服务发现
前文介绍到了通过接口级服务注册发现的优势即开发人员无需关心下游主机名和端口号只需要引入接口存根或实现接口通过框架启动即可。
2 高性能
我们在 k8s 集群内部署 Istio 环境分别测试了 sidecar 模式的 gRPC 服务调用和 Proxyless 模式的 dubbo-go 应用服务调用。发现 proxyless 在请求耗时方面比 sidecar 模式少一个数量级即性能提升十倍左右。
3 跨生态
Dubbo-go 是一个横跨多个生态的服务框架。 mesh 生态 开发人员可以使用 Dubbo-go 进行应用开发的同时使用 Istio 生态所提供的强大能力。 gRPC 生态 Dubbo-go 支持与 gRPC 服务互通HTTP2 协议栈。Dubbo-go 默认使用 pb 序列化方式高性能。 Dubbo 生态 多语言优势可以实现 go-java 应用互通。兼容 pixiu 网关方便地进行服务的暴露和协议转换。使用 Dubbo-go 生态组件。
四 动手体验 Dubbo-go-Mesh
Dubbo-go 目前已支持兼容 Istio 的服务治理能力。支持基于 Istio 的接口级服务发现能力兼容 Istio 生态的流量控制和管理能力并且提供了脚手架和应用模板以提高 Go 应用开发效率。
您可参考文档 【Dubbo-go 文档 - Mesh 任务】[2]动手搭建一组 Dubbo-go Mesh 应用。
在这组任务中开发者会从部署 Istio 环境开始到创建应用模板、构建应用、发布应用、实现服务发现和 RPC、到最终完成流量规则动态配置观察流量切换。对框架用户有较高的参考意义。
五 展望
Proxyless Service Mesh 能力将跟随 Dubbo-go 下一版本发布稳定的性能需要社区成员们共同的关注与建设。在此基础之上我们还会进一步探索轻量级 sdk sidecar的模型探索基于第三方流量治理组件的金丝雀发布能力探索基于 dubbo 服务框架的多语言 sevice mesh、与更丰富的 mesh 生态组件兼容。
Dubbo-go 也将继续在云原生的方向前进继续发掘云计算时代技术红利与开发者同在。原文链接
本文为阿里云原创内容未经允许不得转载。
