技術文章 » Proxyless Mesh 在 Dubbo 中的實踐

Proxyless Mesh 在 Dubbo 中的實踐

2023-01-03 12:00:49

背景

隨著 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 代理，因此可以減少應用程式效能的損耗。

但相比於 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://<trust domain>/<workload identifier> 的 URI 格式，作為工作負載（Workload）的唯一標識。
而 Istio 在自身的生態中只使用到了 SPIFFE ID 作為安全命名，其資料格式由自己實現，通訊格式採用 CNCF 支援的 xDS 協定規範（證書認證通訊更具體來說是 xDS 的 SDS）。

Istio 使用形如 spiffe://<trust_domain>/ns/<namespace>/sa/<service_account> 格式的 SPIFFE ID 作為安全命名，注入到 X.509 證書的 subjectAltName 擴充套件中。
其中"trust_domain"引數通過 Istiod 環境變數TRUST_DOMAIN 注入，用於在多叢集環境中互動。

以下是 Dubbo Proxyless Mesh 證書頒發的過程

  • 建立 RSA 私鑰（Istio 還不支援 ECDSA 私鑰）
  • 構建 CSR（Certificate signing request）模板
  • 自簽名 CSR 生成證書
  • 建立 Kubernetes Secret 資源儲存 CA 證書和私鑰（CA Service處理）

案例實踐

接下來我將帶領大家通過一個例子使已有的專案快速跑在 Proxyless Mesh 模式下。

環境準備

安裝docker

https://www.docker.com/

安裝minikube

牆裂推薦：https://kubernetes.io/zh-cn/docs/tutorials/hello-minikube/

安裝istio

https://istio.io/latest/docs/setup/getting-started/

❗❗❗ 安裝 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

程式碼準備

xds-provider

定義一個介面

public interface GreetingService {

    String sayHello(String name);
}

實現對應的介面

@DubboService(version = "1.0.0")
public class AnnotatedGreetingService implements GreetingService {

    @Override
    public String sayHello(String name) {
        System.out.println("greeting service received: " + name);
        return "hello, " + name + "! from host: " + NetUtils.getLocalHost();
    }
}

編寫啟動類

public class ProviderBootstrap {

    public static void main(String[] args) throws Exception {
        AnnotationConfigApplicationContext context = new AnnotationConfigApplicationContext(ProviderConfiguration.class);
        context.start();
        System.out.println("dubbo service started");
        new CountDownLatch(1).await();
    }

    @Configuration
    @EnableDubbo(scanBasePackages = "org.apache.dubbo.samples.impl")
    @PropertySource("classpath:/spring/dubbo-provider.properties")
    static class ProviderConfiguration {
    }
}

編寫設定資訊

dubbo.application.name=dubbo-samples-xds-provider
# 由於 Dubbo 3 應用級服務發現的後設資料無法從 istio 中獲取，需要走服務自省模式。
# 這要求了 Dubbo MetadataService 的埠在全叢集的是統一的。
dubbo.application.metadataServicePort=20885
# 走xds協定
dubbo.registry.address=xds://istiod.istio-system.svc:15012
dubbo.protocol.name=tri
dubbo.protocol.port=50051
# 對齊k8s pod生命週期，由於 Kubernetes probe 探活機制的工作原理限制，
# 探活請求的發起方不是 localhost，所以需要設定 qosAcceptForeignIp 引數開啟允許全域性存取
dubbo.application.qosEnable=true
dubbo.application.qosAcceptForeignIp=true

編寫Deployment.yml和Service.yml

apiVersion: apps/v1
kind: Deployment
metadata:
  name: dubbo-samples-xds-provider
  namespace: dubbo-demo
spec:
  replicas: 3
  selector:
    matchLabels:
      app: dubbo-samples-xds-provider
  template:
    metadata:
      labels:
        app: dubbo-samples-xds-provider
    spec:
      containers:
        - name: server
          image: apache/dubbo-demo:dubbo-samples-xds-provider_0.0.1
          livenessProbe:
            httpGet:
              path: /live
              port: 22222
            initialDelaySeconds: 5
            periodSeconds: 5
          readinessProbe:
            httpGet:
              path: /ready
              port: 22222
            initialDelaySeconds: 5
            periodSeconds: 5
          startupProbe:
            httpGet:
              path: /startup
              port: 22222
            failureThreshold: 30
            periodSeconds: 10

apiVersion: v1
kind: Service
metadata:
  name: dubbo-samples-xds-provider
  namespace: dubbo-demo
spec:
  clusterIP: None
  selector:
    app: dubbo-samples-xds-provider
  ports:
    - name: grpc
      protocol: TCP
      port: 50051
      targetPort: 50051

編寫Dockerfile

FROM openjdk:8-jdk
ADD ./target/dubbo-samples-xds-provider-1.0-SNAPSHOT.jar dubbo-samples-xds-provider-1.0-SNAPSHOT.jar
CMD java -jar -agentlib:jdwp=transport=dt_socket,server=y,suspend=n,address=31000 /dubbo-samples-xds-provider-1.0-SNAPSHOT.jar

xds-consumer

定義一個介面

public interface GreetingService {

    String sayHello(String name);
}

實現對應的介面

@Component("annotatedConsumer")
public class GreetingServiceConsumer {
  	// 這裡特別注意的是、由於當前 Dubbo 版本受限於 istio 的通訊模型無法獲取介面所對應的應用名，
		// 因此需要設定 providedBy 引數來標記此服務來自哪個應用。
    @DubboReference(version = "1.0.0", providedBy = "dubbo-samples-xds-provider")
    private GreetingService greetingService;

    public String doSayHello(String name) {
        return greetingService.sayHello(name);
    }
}

編寫啟動類

public class ConsumerBootstrap {

    public static void main(String[] args) {
        AnnotationConfigApplicationContext context = new AnnotationConfigApplicationContext(ConsumerConfiguration.class);
        context.start();
        GreetingServiceConsumer greetingServiceConsumer = context.getBean(GreetingServiceConsumer.class);
        while (true) {
            try {
                String hello = greetingServiceConsumer.doSayHello("xDS Consumer");
                System.out.println("result: " + hello);
                Thread.sleep(100);
            } catch (Throwable t) {
                t.printStackTrace();
            }
        }
    }

    @Configuration
    @EnableDubbo(scanBasePackages = "org.apache.dubbo.samples.action")
    @PropertySource("classpath:/spring/dubbo-consumer.properties")
    @ComponentScan(value = {"org.apache.dubbo.samples.action"})
    static class ConsumerConfiguration {

    }
}

編寫設定資訊

dubbo.application.name=dubbo-samples-xds-consumer
dubbo.application.metadataServicePort=20885
dubbo.registry.address=xds://istiod.istio-system.svc:15012
dubbo.consumer.timeout=3000
dubbo.consumer.check=false
dubbo.application.qosEnable=true
dubbo.application.qosAcceptForeignIp=true

編寫Deployment.yml和Service.yml

apiVersion: apps/v1
kind: Deployment
metadata:
  name: dubbo-samples-xds-consumer
  namespace: dubbo-demo
spec:
  replicas: 2
  selector:
    matchLabels:
      app: dubbo-samples-xds-consumer
  template:
    metadata:
      labels:
        app: dubbo-samples-xds-consumer
    spec:
      containers:
        - name: server
          image: apache/dubbo-demo:dubbo-samples-xds-consumer_0.0.1
          livenessProbe:
            httpGet:
              path: /live
              port: 22222
            initialDelaySeconds: 5
            periodSeconds: 5
          readinessProbe:
            httpGet:
              path: /ready
              port: 22222
            initialDelaySeconds: 5
            periodSeconds: 5
          startupProbe:
            httpGet:
              path: /startup
              port: 22222
            failureThreshold: 30
            periodSeconds: 10

apiVersion: v1
kind: Service
metadata:
  name: dubbo-samples-xds-consumer
  namespace: dubbo-demo
spec:
  clusterIP: None
  selector:
    app: dubbo-samples-xds-consumer
  ports:
    - name: grpc
      protocol: TCP
      port: 50051
      targetPort: 50051

編寫Dockerfile

FROM openjdk:8-jdk
ADD ./target/dubbo-samples-xds-consumer-1.0-SNAPSHOT.jar dubbo-samples-xds-consumer-1.0-SNAPSHOT.jar
CMD java -jar -agentlib:jdwp=transport=dt_socket,server=y,suspend=n,address=31000 /dubbo-samples-xds-consumer-1.0-SNAPSHOT.jar

✅ 到目前為止我們的環境和程式碼就全都準備完畢了！

構建映象

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 雲原生之路的同學可以積极參與社群貢獻！

歡迎在 https://github.com/apache/dubbo 給 Dubbo Star。
搜尋關注官方微信公眾號：Apache Dubbo，瞭解更多業界最新動態，掌握大廠面試必備 Dubbo 技能