部署应用 on Apache Dubbo

部署 Istio 环境

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

1. 准备工作

docker、helm、kubectl 环境已安装。
dubbo-go 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 集群中；观察、调试和验证服务发现和调用成功。

1. 准备工作

dubbo-go 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

生成项目包括几个目录：

流量管理

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

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

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

1. 准备工作

dubbo-go 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 的服务结构。

conf/dubbogo.yaml

dubbo:
 registries:
 xds:
 protocol: xds
 address: istiod.istio-system.svc.cluster.local:15010
 protocols:
 triple:
 name: tri
 port: 20000
 provider:
 services:
 GreeterServerImpl:
 interface: "" # read from stub

至此，应用开发完成。

无代理服务网格

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

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

优雅下线

背景

在稳定生产的过程中，容器调度完全由 k8s 管控，微服务治理完全由服务框架或者运维人员进行维护和管理。而在发布新版本，或者扩缩容的场景下，会终止旧的容器实例，并使用新的容器实例进行替换，对于承载高流量的线上生产环境，这个替换过程的衔接如果不合理，将在短时间内造成大量的错误请求，触发报警甚至影响正常业务。对于体量较大的厂家，发布过程出现问题所造成的损失会是巨大的。因此，优雅下线的诉求被提出。这要求服务框架在拥有稳定服务调用能力、传统服务治理能力的基础之上，应当提供服务下线过程中稳定的保障，从而减少运维成本，提高应用稳定性。

特性说明

在一次完整的RPC调用过程中，中间服务往往充当服务提供者和服务消费者两个角色。中间服务在接收到来自上游服务的请求之后，处理请求得到结果返回给上游服务，然后根据需要调用下游服务提供的接口使用下游服务。因此优雅下线功能需要兼顾服务作为服务提供者和服务消费者两侧的稳定性，具体可以分为以下几步：

向注册中心进行反注册，销毁在注册中心注册的服务信息
作为服务提供者，要等待一段时间，保证客户端成功更新服务信息以及上游任务请求处理完毕，然后拒绝接收新的请求
作为服务消费者，要等待一段时间，保证使用下游服务的请求得到响应，然后取消对注册中心的订阅
销毁对下游任务的引用，销毁对外提供服务暴露的端口
执行用户的自定义回调操作

通过以上步骤，可以保证dubbo-go服务实例安全平稳停止，不对进行中的业务产生影响。

注意：取消对注册中心的订阅不能在步骤1中执行，这是因为中间服务对下游服务发送请求的时候可能存在下游服务信息的变动

使用场景

对dubbo-go实例使用kill pid命令停止实例

使用方式

以下是在yaml配置文件中，用户可以自定义的配置

作为服务提供者，dubbo-go实例下线时需要等待客户端成功更新服务信息，这段时间在配置中对应的字段为consumer-update-wait-time，默认3s
作为服务提供者，dubbo-go实例下线时如果来自上游任务的请求暂未处理完毕，需要等待上游任务请求处理完毕。作为服务消费者，dubbo-go实例需要等待对下游的请求收到回复。这段时间在配置中对应的字段为step-timeout，默认3s
作为服务提供者，dubbo-go实例下线时如果来自上游任务的请求已经处理完毕，需要等待一段窗口时间，如果在窗口时间内没有接收到新的请求，再执行后续步骤。这段时间在配置中对应的字段为offline-request-window-timeout，默认0s
用户可以自定义是否开启优雅下线功能，在配置中对应的字段为internal-signal，默认开启。
dubbo-go实例在优雅下线过程中可能因为异常导致卡死，在配置中可以配置超时时间，实例在超时之后强制关闭。这在配置中对应的字段为timeout，默认60s

dubbo:
 shutdown:
 timeout:60
 step-timeout:3
 consumer-update-wait-time:3
 internal-signal:true
 offline-request-window-timeout:0

此外，如果用户希望在下线逻辑彻底结束后，执行一些自定义的回调操作，可以使用如下代码

extension.AddCustomShutdownCallback(func() {
	// 用户自定义操作
})

参考资料

【Dubbo-go 优雅上下线的设计与实践】