作者：江河清，阿里云研发工程师、Apache Dubbo PMC
随着云原生的兴起，越来越多的应用选择基于 Kubernetes 进行部署，相关的 DevOps 等工具也应运而生。而 Dubbo 作为微服务体系的主流解决方案，如何开发面向 Kubernetes 部署和运维的微服务应用是很多开发者与架构师要解决的问题。本文将从开发、部署、监控、运维等多维度视角分析，详细的介绍如何基于 Dubbo 在Kubernetes 体系下构建高效、可靠的微服务应用。
上图是今天演讲会使用到的一个 Demo 工程。这个工程参考自 istio 的示例 book info 工程，总共部署四个应用。其中 Product Page 负责页面的属性整合，通过 http 接口对外暴露信息；Reviews、Details、Ratings 分别负责了评价、规则、评分等细分模块信息。
01
使用 Dubbo Starter 初始化项目
对于很多开发来说，在 Java 体系下创建出新的应用，无外乎就是用 IDE 创建一个新的项目，或者用 maven 的 template，或者基于 Spring 的 Initializer。上图使我们基于 Spring 的 Initializer 建立了我们自己的初始化项目的工程。我们点击最上面的网址就能直接看到这个页面了，你需要输入对应的 group 和 artifact。然后选择你希望用到的组件，比如 Nacos、Prometheus 的组件等等。
（观看完整演示视频请前往此处）
除此之外，我们在 IDE 里提供了一个 Dubbo 的插件。这个插件可以通过上图的方式进行安装，或者如果你的仓库里已经用到了 Dubbo 的配置，它会提示你可以直接安装。安装完成后在右边就会有一个对应的初始化的项目了。
（观看完整演示视频请前往此处）
:26
上图是一个示例，它在这里建立了一个 Dubbo 的项目，然后你需要在这里选中所需要的组件信息，最后点击创建，之后它就会帮你在本地直接创建出一个全新的项目，然后你就可以在这个模版上开发了。
开发微服务之协议选型
初始化完应用以后，下一步就是开发服务，这里我们选取一个和 Dubbo 关系较为密切的环节——协议选型展开进行讲解。
Dubbo 的 Triple 协议期望设计成一个易于浏览器访问，且完全支持 gRPC 的协议。这就意味着，这样的一个协议可以实现从端上到后端集群之间的协议统一。
（观看完整演示视频请前往此处）
下面来看一下我们的项目，这是刚才建立的一个项目，我现在把应用启动起来，配置一些注册中心的地址，这就是一个标准的 Spring 的启动的流程。这里定义了一个接口，这个接口返回了一个 “hello” 的内容信息。然后我用一个简单的命令，就可以直接返回我的 hello world 的结果了。这样对我们本身的测试来说有很大的帮助，也就是本地启动之后，就可以直接测试接口。03
基于 Kubernetes 快速初始化环境
对于微服务应用，如果需要在一个新的环境下部署，则必须前置部署包括但不限于注册中心、配置中心、可观测等组件。不管是从组件的数量上，还是单一组件的部署复杂度上来说，这都是一件耗时耗力的事情。为了改变这一现状，Dubbo 提供了一个快速拉起环境的工具，仅需 dubboctl manifest install 一键就可以在 Kubernetes 环境中部署起前面所说道的若干个组件，极大的降低整体部署的难度。
（观看完整演示视频请前往此处）
这里有一个简单的例子，环境拉起来之后，它会把所有的组件都会帮你拉起来。这里埋一个点，这里的 Prometheus 我们后面还会继续使用。整个 Nacos 的地址，ZooKeeper 的地址都会直接提供给你。
这也是一个的例子。执行一个简单的命令，然后本地会把 Kubernetes 的配置都准备好，它就会自动的帮你把组件都创建起来。也就是我们一键就可以获取到所有 service 的部署。04
快速部署应用到 Kubernetes 集群中
为了将应用正确地部署在 Kubernetes 中，主要有三个步骤需要完成，分别是应用容器化、无状态部署和生命周期对齐。首先是应用容器化，顾名思义需要将应用运行在容器中。为了实现容器化，通常我们需要准备一个 Dockerfile，然后通过一系列的脚本进行打包。但是其实我们可以把这一切通过一个 Maven 的插件来完成，今天要给大家介绍的是一个基于 Maven 的自动化构建插件，通过简单的几行配置就可以自动在 Maven 打包的过程中将编译结果打包进容器中，实现快速构建。
（观看完整演示视频请前往此处）
可以看到，我只需要把我的 pom 里添加一个对应的配置项依赖，通过一键 maven 的编译模式，它就可以在 maven 打包的过程中帮你构建完镜像，然后直接推送到远端仓库。这一切都只需要这一个命令就可以完成，而且一次性配置之后，未来你所有的镜像更新都可以自动化的去做，不需要再去写繁琐的 dockerfile。
在应用实现容器化以后，下一步通过 Kubernetes 的资源配置将镜像运行在 Kubernetes 容器中，右边这个模板是 Kubernetes 中一个非常简单的无状态 Deployment 部署的模版。
（观看完整演示视频请前往此处）
这是一个简单的例子，把 deployment 配置完之后，指定了刚才的镜像。同时我声明了一个 service，这个 service 非常重要，它后面会作为 frontend 应用入口的配置，但它是一个 Ingress 网关。可以看到 apply 镜像之后，我们就可以在 K8s 体系上把这个环境 run 起来了。这里做一个简单的测试，我引入一个 curl 的容器，同样我们可以用刚才 curl 的命令访问我新部署好的容器节点，可以看到它返回了 hello world 的数据信息。综上，我们通过 deployment 的部署，可以在 K8s 上把容器 run 起来，同时它还可以对外提供服务，对外提供的服务我可以通过下面 curl 的命令进行调用。
最后是将应用部署到 Kubernetes 集群中以后，由于 Kubernetes 是基于 POD 的生命周期进行调度的，在执行分批轮转的过程中会基于 POD 的健康状态进行调度，如果没有配置对应的健康状态，会导致实际上前一批应用还没启动成功就把后一批的应用给发布了的情况。而为了解决这个问题，Dubbo 提供了几个 QoS 命令可以供 Kubernetes 调用查询应用状态。
（观看完整演示视频请前往此处）
上图是一个例子。在整个应用启动的时候，这里 sleep 了 20 秒，然后配置了对应的 probe 信息。我们简单推测一下，我在前面设置了等待 20 秒，那么我的应用肯定要超过 20 秒才能起来。因为修改了代码，所以这里需要重新编译一下，用一键 maven 的编译模式直接推上去。接下来要把 deployment apply 进去，进去之后 Pod 的状态全都是 not ready 的，都是零的状态。因为前面 sleep 了 20 秒的时候，Dubbo 还没启动完，所以都是 not ready 的状态。我们等 sleep 的阶段过了，它就会变成 ready 的状态，然后再进行分批这就是生命周期对齐的过程。所以 Kubernetes 知道应用什么时候启动成功了，什么时候启动失败了，才能进行更好的调度。05
云原生微服务可观测最佳实践
可观测体系整体来说分为 Metrics、Tracing 和 Loggin 几个模块。首先对于 Metrics 我们主要关心几个核心指标，比如延迟、流量、异常情况等等。对应到 Dubbo 的有包括 QPS、RT 等等的指标。
为了更好地观测这些指标，Dubbo 最新版本默认集成了 Metrics 收集能力，如果你部署的集群中已经有了 Prometheus，仅需要简单的配置几个参数，即可实现 Metrics 的自动采集。
（观看完整演示视频请前往此处）
上面是一个演示的例子。我们在前面的 deployment 的例子上加上 Metrics 的采集信息，然后把它 apply 进去之后，我们就可以用整个 Grafana 导出过来。跑了一段时间之后，就会有对应的流量信息，比如 QPS 信息、RT 信息、成功率等等。得到这些指标后，我们还可以做一个告警。比如 QPS 从 100 突然跌到了 0，或者成功率突然跌了很多，这种情况我们需要做一个警示，让大家知道当前发生的问题。我们可以基于 Prometheus 采集，做一个主动的推送，这就是告警的过程。
除了 Metrics 之外，Tracing 也是一个很重要的可观测组成部分。目前业界主流为了实现 Tracing 能力有两种解决方案，一种是通过 SDK 依赖的方式引入 Tracing 相关组件，静态化部署；另外一种是通过 Agent 的模式自动注入到代码中动态部署。
（观看完整演示视频请前往此处）
大家可以看到，在这里你只需要依赖 dependency 里面加上 Dubbo 的 starter，配置项里把 Tracing 能力打开，开启一个指标的上报，9411 是我们 Zipkin 的一个后端。
这也是一个例子，我只需要配置这些配置，它的数据就会报到 Zipkin 上去，这里的 dependency 直接加上。同样的，用刚才的命令进行打包，把镜像推送上去，然后我们等待一下。推送的过程中可以看一下 Zipkin 这个组件，它也是在最前面我们在 K8s 初始化环境的时候一起拉起的，所以这一切你只需要在前面一次性部署的时候就可以拥有了。然后我们简单的执行一个 curl 命令，因为我需要让我的环境有流量。部署完之后，用 curl 命令还是执行一下我们的获取，这个其实已经把后端开发完了，它返回了真实的结果。接下来我们去 Zipkin 上看看能不能找到这条 Tracing。首先把 9411 映射过来，我们可以看到 curry 一下，这里就会有对应的指标信息。整个全链路的调用信息这里都可以看到，这就是全链路的接入的流程。相当于你只需要把前面的 dependency 加上，把上报的配置加上，之后的一切我都会帮你在后面完成以及上报。你看到对应的结果，就可以知道全链路上发生了什么事情。
除此之外也可以基于 Agent 的模式进行部署，这个示例是基于 Skywaling 的配置默认。通过修改 deployment 的配置，可以实现自动挂在 javaagent 到应用中。
对于整个可观测来说，我们可以通过 Metrics 看到 QPS、RT 等信息，通过 Tracing 看到全链路的访问信息。这里提供给我们一个很好的方案，就是我们要先去做服务的观测，基于服务的观测更好的排查整体的问题，第一时间知道应用挂没挂。比如半夜两点，它的可用率跌到零了。这个时候可以通过一系列的自动化机制告诉你应用出了问题，快速的进行恢复。这里的快速恢复可以使用回滚，将流量隔离的方案他都可以快速的执行。基于这样快速的从观测到排查，再到快速恢复的链条，可以构建整个生产环境下的安全稳定的体系。所以我们观测完之后的目标就是保证整个应用的稳定。06
在 Kubernetes 中管理微服务应用
K8s 给我们带来的收益包括快速扩缩容，即我可以很快的基于 K8s 从一个 Pod 变成多个 Pod。因为 K8s 是基于整个 Image 的部署的流程，当镜像打包出来后，你的环境就是固定的，只需要去横向的扩容即可。横向的快速扩容也会涉及到几个瓶颈的点，如果我需要让我的应用能够快速扩容，比如我的应用提起来就要几十分钟，这种情况即使快速扩容了，等扩容完之后你的业务峰值也过去了，这里就会引入到 Native Image。基于 Native Image，我们可以很好的实现整个 Serverless 的横向的扩容。如果可以实现毫秒级的启动，我可以在流量来的波峰，直接让我的 Pod 横向扩容好几倍，当它的流量下去的时候就直接下掉，这样就实现了成本的压缩。另外还有一个问题是怎么知道什么时候要扩容？这就需要基于 Metrics 的观测，基于一些历史数据的分析，知道在某个时间点会有多少的流量，然后提前扩容，或者做一个自动化的扩容。
这里我举一个简单的例子，比如我的 rating 上出了一些问题，我需要把它的故障摘除掉，返回一个 Mock 的结果。
这个时候你只需要在上面去配置一个上图的规则，它就会返回。这就是 Admin 的使用流程，这里就不再展开了，还有刚刚提到的我们在做 Go 版本的重构能力，后面也都会有更好的建设。
除此之外，基于 istio 的 Service Mesh 治理，我们前面协议选型的时候选了 Triple 协议，它完全是 based on HTTP 标准的。因此我们使用 istio 的整个体系之后，你只需要挂上 sidecar 它就会帮你去做流量治理。这一切的前提是你的协议一定是 istio 可见的。
比如你原来用是 Dubbo 2 的 Dubbo 的协议，它是一个私有的 tcp 协议，对于 istio 来说它很难分辨你的协议内容。如果你用了 Triple 协议，我们可以基于 HTTP 标准，你就可以知道你的 header 里有什么东西，可以去做一个流量的转发。所以它完全拥抱 Mesh 的体系，可以支持我们所有 istio 的治理能力。
本文通过 Bookinfo 示例，介绍了如何基于新版 Starter 快速初始化一个项目、通过一系列云原生工具实现应用快速部署、使用 Dubbo 原生可观测能力进行线上诊断分析等，实现了从项目初始化到线上部署的全流程覆盖，为期望在 Kubernetes 下开发微服务的用户提供了可以复制且大规模部署的样板。
