部署应用 on Apache Dubbo

部署 Istio 环境

Mon, 01 Jan 0001 00:00:00 +0000

1. 准备工作

docker、helm、kubectl 环境已安装。
已安装 dubbogo-cli 及相关依赖工具。dubbogo-cli 请从 dubbo-go 主仓库 tools/dubbogo-cli 安装。

2. 部署 Istio 环境

使用helm 安装 istio 基础 CRD 和 istiod 组件。也可以参考 Istio 文档使用 istioctl 安装。

$ helm repo add istio https://istio-release.storage.googleapis.com/charts
$ kubectl create namespace istio-system
$ helm install istio-base istio/base -n istio-system
$ helm install istiod istio/istiod --namespace istio-system

删除istio 水平扩展资源

*目前 dubbo-go 依赖单个 istiod 实例进行服务发现。

$ kubectl delete hpa istiod -n istio-system

安装完成后，可以在 istio-system 命名空间下看到一个 istiod pod 在正常运行。

Istio 环境部署 Dubbo-go 应用

Mon, 01 Jan 0001 00:00:00 +0000

在本章节中，我们将使用应用模板快速创建一组 Dubbo-go Server和 Client 端应用，部署在 Istio 集群中；观察、调试和验证服务发现和调用成功。

对应的 mesh 示例见 dubbo-go-samples/mesh。

1. 准备工作

已安装 dubbogo-cli 及相关依赖工具。dubbogo-cli 请从 dubbo-go 主仓库 tools/dubbogo-cli 安装；grpc_cli 仅在本地调试时需要。
docker、helm、kubectl 环境已安装。（arm 机器需支持 docker buildx）
任务【istio 环境部署】已完成

2. 开发 server 端 Dubbo-go 应用

2.1 使用 dubbogo-cli 创建项目模板

$ mkdir mesh-app-server
$ cd mesh-app-server
$ dubbogo-cli newApp . 
$ tree .
.
├── Makefile
├── api
│ └── api.proto
├── build
│ └── Dockerfile
├── chart
│ ├── app
│ │ ├── Chart.yaml
│ │ ├── templates
│ │ │ ├── _helpers.tpl
│ │ │ ├── deployment.yaml
│ │ │ ├── service.yaml
│ │ │ └── serviceaccount.yaml
│ │ └── values.yaml
│ └── nacos_env
│ ├── Chart.yaml
│ ├── templates
│ │ ├── _helpers.tpl
│ │ ├── deployment.yaml
│ │ └── service.yaml
│ └── values.yaml
├── cmd
│ └── app.go
├── conf
│ └── dubbogo.yaml
├── go.mod
├── go.sum
└── pkg
 └── service
 └── service.go

dubbogo-cli 现在维护在 dubbo-go 主仓库的 tools/dubbogo-cli 目录下，本文后续步骤都基于它生成的模板展开。

流量管理

Mon, 01 Jan 0001 00:00:00 +0000

在本节中，我们将延续上一个任务【在 Istio 环境部署 Dubbo-go 应用】。

在之前的任务中，我们在集群中部署了一组 Dubbo-go Server和 Client 端应用，验证了服务发现和调用成功。在本节中，我们将创建新版本的 Server 端应用。通过配置 VirtualService 和 DestinationRule ，实现路由管理，和流量转移能力

对应的流量治理部署清单见 dubbo-go-samples/mesh/deploy/traffic。

1. 准备工作

已安装 dubbogo-cli 及相关依赖工具。dubbogo-cli 请从 dubbo-go 主仓库 tools/dubbogo-cli 安装；grpc_cli 仅在本地调试时需要。
docker、helm、kubectl 环境已安装。（arm 机器需支持 docker buildx）
任务【在 Istio 环境部署 Dubbo-go 应用】已完成

2. 开发多版本Dubbo-go 应用。

2.1 使用 dubbogo-cli 创建另一个项目模板

$ dubbogo-cli newApp .

2.2 开发和部署客户端 Dubbo-go 应用 v2：

编写业务逻辑

修改 package/service/service.go 的实现方法，返回版本号为 v2.0.0

func (s *GreeterServerImpl) SayHello(ctx context.Context, in *api.HelloRequest) (*api.User, error) {
	return &api.User{Name: "Hello " + in.Name, Id: "v2.0.0"}, nil
}

修改如下配置文件，使用xds协议作为注册中心，加载名为 GreeterServerImpl 的服务结构。

无代理服务网格

Mon, 01 Jan 0001 00:00:00 +0000

示例源码：dubbo-go-samples/mesh。

1. 什么是 Proxyless Service-Mesh (无代理服务网格) ?

1.1 Service Mesh 简析

Istio 是当今最流行的开源服务网格。它由控制平面和数据平面构成，其架构如下，图片摘自 istio官网

位于图中下半部分的控制平面负责配置、服务信息、证书等资源的下发。位于上半部分的数据平面关注业务之间的通信流量；传统服务网格通过代理的方式拦截所有的业务网络流量，代理需要感知到控制平面下发的配置资源，从而按照要求控制网络流量的走向。

在 Istiod 环境中，其控制平面是一个名为 istiod 的进程，网络代理是 envoy 。istiod 通过监听 K8S 资源例如Service、Endpoint 等，获取服务信息，并将这些资源统一通过 XDS 协议下发给位于数据平面的网络代理。envoy 是一个独立的进程，以 sidecar（边车）的形式伴随业务应用 Pod 运行，他与应用进程共用同一个主机网络，并通过修改路由表的方式，劫持业务应用的网络流量。

Service Mesh 可以解决微服务场景下的众多问题，随着集群规模的扩大与业务复杂度的增长，基于原生 k8s 的容器编排方案将会难以应付，开发人员不得不面对巨大的服务治理挑战。而 Service Mesh 很好地解决了这一问题，它将服务治理需求封装在了控制平面与代理中，业务开发人员只需要关注于业务逻辑。在应用部署之后，只需要运维人员通过修改配置，即可实现例如故障恢复、负载均衡、灰度发布等功能，这极大地提高了研发和迭代效率。

Istio 的 sidecar 通过容器注入的形式伴随业务应用进程的整个生命周期，对于业务应用是毫无侵入的，这解决了业务应用可迁移、多语言、基础架构耦合等问题。但这也带来了高资源消耗、请求时延增长的问题。

Service 为服务治理提供了一个很好的思路，将基础架构与业务逻辑解耦，让应用开发人员只需关注业务。另一方面，由于 sidecar 的弊端，我们可以考虑使用 sdk 的形式，来替代 sidecar 支撑起数据平面。

1.2 Proxyless Service-Mesh

无代理服务网格，是近几年提出的一个新的概念，isito、gRPC、brpc 等开源社区都在这一方向进行了探索和实践。无代理服务网格框架以 SDK 的形式被业务应用引入，负责服务之间的通信、治理。来自控制平面的配置直接下发至服务框架，由服务框架代替上述 sidecar 的功能。

服务框架（SDK）的主要能力可以概括为以下三点：

对接控制平面，监听配置资源。
对接应用，为开发者提供方便的接口。
对接网络，根据资源变动，响应流量规则。

1.3 Proxyless 的优缺点

优点：

优雅停机

Mon, 01 Jan 0001 00:00:00 +0000

优雅停机

示例源码：dubbo-go-samples/graceful_shutdown。

1. 背景

在发布新版本、扩缩容或迁移节点时，Kubernetes、systemd 或运维平台会终止旧实例并启动新实例。如果旧实例直接退出，注册中心、客户端连接池和上游流量之间会出现短暂的不一致：注册中心可能还没有推送摘除事件，上游请求也可能仍在处理中。对于高流量服务，这会带来连接断开、请求失败、超时重试和告警放大。

Dubbo-go 的优雅停机用于在进程退出前完成摘流和请求排空，尽量保证：

Provider 不再接收新的业务请求之前，先从注册中心反注册并通知长连接 Consumer。
已经进入 Provider 的请求可以在超时时间内完成。
Consumer 本身正在发出的下游调用可以在退出前拿到响应。
资源销毁、端口释放和用户自定义回调按顺序执行。

2. 工作机制

一次 Dubbo-go 调用链路中，某个服务实例通常既是 Provider，也是 Consumer。因此优雅停机会同时处理服务提供端和服务消费端。

2.1 触发停机

当应用收到 SIGTERM、SIGINT 等退出信号时，如果 dubbo.shutdown.internal-signal 为 true，Dubbo-go 会进入内置优雅停机流程。Kubernetes 删除 Pod、滚动发布、kubectl delete pod、kill -TERM <pid> 和终端 Ctrl+C 都属于典型触发方式。

不要使用 kill -9 触发停机。SIGKILL 无法被进程捕获，Dubbo-go 没有机会执行优雅停机流程。

2.2 Provider 侧流程

Provider 侧目标是先摘流，再等待正在执行的请求完成。

从注册中心反注册当前实例，触发 Consumer 端服务列表更新。
对 Triple 长连接 Consumer 发送关闭通知，使 Consumer 可以尽快避开正在关闭的 Invoker。
在 consumer-update-wait-time 时间内继续接收请求，给客户端和注册中心事件传播留出窗口。
在开启拒绝新请求前，在 step-timeout 和 offline-request-window-timeout 约束下等待 Provider 侧活跃请求数归零。
进入拒绝新请求阶段，后续新请求会被拒绝或由自定义 reject-handler 处理。
销毁协议、关闭监听端口并释放资源。

offline-request-window-timeout 主要用于高流量场景：当活跃请求暂时归零后，再观察一个短窗口。如果窗口内没有新的请求进入，就可以更安全地继续销毁资源。