Proxyless Mesh 在 Dubbo 中的实践-六虎

作者：王程铭

布景

跟着 Dubbo 3.1 的 release，Dubbo 在云原生的路上又迈出了重要的一步。在这个版别中添加了 Proxyless Mesh 的新特性，Dubbo Proxyless Mesh 直接完成 xDS 协议解析，完成 Dubbo 与 Control Plane 的直接通讯，然后完成操控面对流量管控、服务办理、可观测性、安全等的统一管控，规避 Sidecar 形式带来的功能损耗与布置架构杂乱性。

什么是 Service Mesh

Service Mesh 又译作 “服务网格”，作为服务间通讯的根底设施层。Buoyant 公司的 CEO Willian Morgan 在他的文章《WHAT’S A Service Mesh? AND WHY DO I NEED ONE? 》中解释了什么是 Service Mesh，为什么云原生运用需求 Service Mesh。

下面是 Willian Morgan 对 Service Mesh 的解释：

A Service Mesh is a dedicated infrastructure layer for handling service-to-service communication. It’s responsible for the reliable delivery of requests through the complex topology of services that comprise a modern, cloud native application. In practice, the Service Mesh is typically implemented as an array of lightweight network proxies that are deployed alongside application code, without the application needing to be aware.

翻译成中文是：

服务网格（Service Mesh）是处理服务间通讯的根底设施层。它担任构成现代云原生运用程序的杂乱服务拓扑来可靠地交给恳求。在实践中，Service Mesh 通常以轻量级网络署理阵列的方式完成，这些署理与运用程序代码布置在一起，对运用程序来说无需感知署理的存在。

说到 Service Mesh 一定离不开 Sidecar 经典架构形式。它经过在事务 Pod 中注入 Sidecar 容器，接收事务容器的通讯流量，同时 Sidecar 容器与网格渠道的操控平面对接，根据操控平面下发的战略，对署理流量施行办理和管控，将原有服务框架的办理才能基层到 Sidecar 容器中，然后完成了根底框架才能的下沉，与事务体系解耦。

经典的 Sidecar Mesh 布置架构有很多优势，如滑润晋级、多语言、事务侵入小等，但也带来了一些额定的问题，比如：

Proxy 带来的功能损耗，在杂乱拓扑的网络调用中将变得特别明显
流量拦截带来的架构杂乱性
Sidecar 生命周期办理
布置环境受限，并不是一切环境都满意 Sidecar 流量拦截条件

针对 Sidecar Mesh 模型的问题，Dubbo 社区自很早之前就做了 Dubbo 直接对接到操控面的设想与考虑，并在国内开源社区率先提出了 Proxyless Mesh 的概念，当然就 Proxyless 概念的说法而言，最开端是谷歌提出来的。

Dubbo Proxyless Mesh

Dubbo Proxyless 形式是指 Dubbo 直接与 Istiod 通讯，经过 xDS 协议完成服务发现和服务办理等才能。

Proxyless 形式使得微服务又回到了 2.x 年代的布置架构，同 Dubbo 经典服务办理形式十分类似，所以说这个形式并不新鲜， Dubbo 从最开端便是这样的规划形式。这样做能够极大的提升运用功能，下降网络推迟。有人说这种做法又回答了原始的根据 SDK 的微服务形式，其实非也，它仍然运用了 Envoy 的 xDS API，可是因为不再需求向运用程序中注入 Sidecar 署理，因此能够削减运用程序功能的损耗。

Tips：对应的发现服务及其相应的 API 被称作 xDS

但比较于 Mesh 架构，Dubbo 经典服务办理形式并没有着重操控面的统一管控，而这点恰好是 Service Mesh 所着重的，着重对流量、可观测性、证书等的标准化管控与办理，也是 Mesh 理念先进的当地。

在 Dubbo Proxyless 架构形式下，Dubbo 进程将直接与操控面通讯，Dubbo 进程之间也持续保持直连通讯形式，咱们能够看出 Proxyless 架构的优势：

没有额定的 Proxy 中转损耗，因此更适用于功能敏感运用
更有利于遗留体系的滑润搬迁
架构简略，简单运维布置
适用于几乎一切的布置环境

服务发现

xDS 接入以注册中心的形式对接，节点发现同其他注册中心的服务自省模型相同，对于 xDS 的负载均衡和路由装备经过 ServiceInstance 的动态运行时装备传出，在构建 Invoker 的时分将装备参数传入装备地址。

证书办理

零信任架构下，需求严厉区分作业负载的辨认和信任，而签发 X.509 证书是推荐的一种认证方式。在 Kubernetes 集群中，服务间是经过 DNS 称号彼此拜访的，而网络流量可能被 DNS 诈骗、BGP/路由劫持、ARP 诈骗等手法劫持，为了将服务称号（DNS 称号）与服务身份强相关起来，Istio 运用置于 X.509 证书中的安全命名机制。SPIFFE 是 Istio 所选用的安全命名的标准，它也是云原生界说的一种标准化的、可移植的作业负载身份标准。

Secure Production Identity Framework For Everyone (SPIFFE) 是一套服务之间彼此进行身份辨认的标准，主要包含以下内容：

SPIFFE ID 标准，SPIFFE ID 是服务的仅有标识，具体完成运用 URI 资源标识符
SPIFFE Verifiable Identity Document (SVID) 标准，将 SPIFFE ID 编码到一个加密的可验证的数据格局中
颁发与吊销 SVID 的 API 标准（SVID 是 SPIFFE ID 的辨认凭据）

SPIFFE ID 规则了形如 spiffe:/// 的 URI 格局，作为作业负载（Workload）的仅有标识。而 Istio 在本身的生态中只运用到了 SPIFFE ID 作为安全命名，其数据格局由自己完成，通讯格局选用 CNCF 支撑的 xDS 协议标准（证书认证通讯更具体来说是 xDS 的 SDS）。

Istio 运用特定格局的 SPIFFE ID 作为安全命名，注入到 X.509 证书的 subjectAltName 扩展中。其中”trust_domain”参数经过 Istiod 环境变量 TRUST_DOMAIN 注入，用于在多集群环境中交互。

特定格局形如：

spiffe:///ns//sa/

以下是 Dubbo Proxyless Mesh 证书颁发的过程：

创立 RSA 私钥
构建 CSR（Certificate signing request）模板
自签名 CSR 生成证书
创立 Kubernetes Secret 资源储存 CA 证书和私钥（CA Service 处理）

事例实践

接下来我将带领大家经过一个例子使已有的项目快速跑在 Proxyless Mesh 形式下。

环境准备

装置 docker

www.docker.com/

装置 minikube

墙裂推荐：

kubernetes.io/zh-cn/docs/…

装置 istio

istio.io/latest/docs…

注：装置 Istio 的时分需求敞开 first-party-jwt 支撑（运用 istioctl 工具装置的时分加上 –set values.global.jwtPolicy=first-party-jwt 参数），否则将导致客户端认证失败的问题。

参考命令如下：

curl -L https://istio.io/downloadIstio | sh -
cd istio-1.xx.x
export PATH=$PWD/bin:$PATH
istioctl install --set profile=demo --set values.global.jwtPolicy=first-party-jwt -y

代码准备

这儿咱们直接复用官方供给的 sample，代码地址：

github.com/apache/dubb…

到目前为止咱们的环境和代码就全都准备完毕了！

构建镜像

1. 发动 docker

2. 发动 minikube

因为 minikube 是一个本地的 K8s，他发动需求一个虚拟引擎，这儿咱们用 docker 来办理。咱们经过如下命令发动

minikube start

咱们能够在 docker 里看到 minikube

3. 查看 istio 的状况

4. 构建镜像

在本地找到代码地点位置、顺次执行以下命令：

# 找到provider地点途径
cd ./dubbo-samples-xds-provider/
# 构建provider的镜像
docker build -t apache/dubbo-demo:dubbo-samples-xds-provider_0.0.1 .

# 找到consumer地点途径
cd ../dubbo-samples-xds-consumer/
# 构建consumer的镜像
docker build -t apache/dubbo-demo:dubbo-samples-xds-consumer_0.0.1 .

5. 查看本地镜像

6. 创立 namespace

# 初始化命名空间
kubectl apply -f https://raw.githubusercontent.com/apache/dubbo-samples/master/dubbo-samples-xds/deploy/Namespace.yml
# 切换命名空间
kubens dubbo-demo

如果不创立 namespace，那么会看到如下错误：

布置容器

# 找到provider地点途径
cd ./dubbo-samples-xds-provider/src/main/resources/k8s
# dubbo-samples-xds/dubbo-samples-xds-provider/src/main/resources/k8s/Deployment.yml
# dubbo-samples-xds/dubbo-samples-xds-provider/src/main/resources/k8s/Service.yml
# 布置provider的Deployment和Service
kubectl apply -f Deployment.yml
kubectl apply -f Service.yml

# 找到consumer地点途径
cd ../../../../../dubbo-samples-xds-consumer/src/main/resources/k8s
# dubbo-samples-xds/dubbo-samples-xds-consumer/src/main/resources/k8s/Deployment.yml
# 布置consumer的Deployment
kubectl apply -f Deployment.yml

在 minikube dashboard 看到咱们现已布置的 pod

调查 consumer 作用

kubectl logs xxx

result: hello, xDS Consumer! from host: 172.17.0.5
result: hello, xDS Consumer! from host: 172.17.0.5
result: hello, xDS Consumer! from host: 172.17.0.6
result: hello, xDS Consumer! from host: 172.17.0.6

总结&展望

本文主要分析了 Dubbo Proxyless Mesh 的架构、服务发现以及证书办理等中心流程，最终经过示例给大家演示了怎么运用 Dubbo Proxyless。

跟着 Dubbo 3.1 的 release，Dubbo 在云原生的路上又迈出了重要的一步。在今年年末，Dubbo Mesh 将发布具有服务发现才能的版别，届时将面向一切 Dubbo 用户供给从低版别滑润搬迁到 Mesh 架构的才能；在下一年年初春季的时分将发布带有办理才能的版别；在下一年年末前发布带热插件更新才能的版别，期望有爱好见证 Dubbo 云原生之路的同学能够积极参与社区贡献！

作者介绍

王程铭，蚂蚁金服工程师、Apache Dubbo Committer、关注 RPC、Service Mesh 和云原生等领域。

Proxyless Mesh 在 Dubbo 中的实践

布景