尝试治理微服务

在前面两篇文档中，我们介绍了一个 Dubbo 应用的完整开发与部署过程。接下来，我们会通过一个更复杂、更完整的微服务商城系统，演示 Dubbo 的服务治理相关能力。

示例商城系统的总体架构图如下所示：

部署示例应用

有两种方式可以完成商城系统部署。

方式一

首先要为目标 kubernetes namespace 开启自动注入模式，以便应用部署后能够自动连接到注册中心等组件。

kubectl label namespace dubbo-demo dubbo-injection=enabled --overwrite

接下来，使用以下命令部署整个商城系统，所有应用会自动连接到之前安装的注册中心进行地址发现：

kubectl apply -f https://raw.githubusercontent.com/apache/dubbo-samples/master/10-task/dubbo-samples-shop/deploy/App.yml

方式二

这种方式不需要使用 dubboctl 工具单独安装组件。因为我们已经将相关组件的安装全部集成到示例脚本中，您可以运行以下命令快速部署示例应用及相关依赖组件：

kubectl apply -f https://raw.githubusercontent.com/apache/dubbo-samples/master/10-task/dubbo-samples-shop/deploy/All.yml

运行以下命令查看示例应用是否部署成功：

kubectl get deployments -n dubbo-demo

可视化监控服务状态

应用启动成功后，可以通过 admin 控制台查看部署状态，根据你使用的 Kubernetes 集群，请按照以下步骤操作：

• 根据部署集群选择：
• 本地集群
• 阿里云ACK

流量管控

我们围绕商城系统由 5 个微服务应用组成：

• Frontend 商城主页，作为与用户交互的 web 界面，通过调用 User、Detail、Order 等提供用户登录、商品展示和订单管理等服务。
• User 用户服务，负责用户数据管理、身份校验等。
• Order 订单服务，提供订订单创建、订单查询等服务，依赖 Detail 服务校验商品库存等信息。
• Detail 商品详情服务，展示商品详情信息，调用 Comment 服务展示用户对商品的评论记录。
• Comment 评论服务，管理用户对商品的评论数据。

在此基础之上，我们设计了一系列的流量治理任务，多个应用部署有 v1、v2 两个不同的版本，我们会演示通过规则引导流量到不同的版本。完整的部署架构图如下：

Order 订单服务有两个版本 v1 和 v2，v2 是订单服务优化后发布的新版本。

• 版本 v1 只是简单的创建订单，不展示订单详情
• 版本 v2 在订单创建成功后会展示订单的收货地址详情

Detail 和 Comment 服务也分别有两个版本 v1 和 v2，我们通过多个版本来演示流量导流后的效果。

• 版本 v1 默认为所有请求提供服务
• 版本 v2 模拟被部署在特定的区域的服务，因此 v2 实例会带有特定的标签

接下来，就请根跟随 示例任务 体验 Dubbo 的流量治理能力吧。

更多内容