✨ [2025-04-01] 添加rocketmq 配置

教程/20250402-使用KtConnect实现本地Debug.md

@@ -0,0 +1,67 @@
+<!-- Space: qifu -->
+<!-- Parent: 后端技术&知识&规范 -->
+<!-- Parent: 技术方案 -->
+<!-- Parent: 基建 -->
+<!-- Parent: 04-使用教程 -->
+<!-- Title: 20250402-使用KtConnect实现本地Debug -->
+
+<!-- Macro: :anchor\((.*)\):
+     Template: ac:anchor
+     Anchor: ${1} -->
+<!-- Macro: \!\[.*\]\((.+)\)\<\!\-\- width=(.*) \-\-\>
+     Template: ac:image
+     Url: ${1}
+     Width: ${2} -->
+<!-- Macro: \<\!\-\- :toc: \-\-\>
+     Template: ac:toc
+     Printable: 'false'
+     MinLevel: 2 
+     MaxLevel: 4 -->
+<!-- Include: 杂项/声明文件.md -->
+
+<!-- :toc: -->
+
+# 20250402-使用KtConnect实现本地Debug
+ 
+## 前置说明
+- 快速开始：https://github.com/alibaba/kt-connect/blob/master/docs/zh-cn/guide/quickstart.md
+
+## 使用
+### 下载 kt-connect
+- 访问 release 页面：https://github.com/alibaba/kt-connect/releases/tag/v0.3.7
+- 或者直接使用wget下载
+```shell
+wget https://github.com/alibaba/kt-connect/releases/download/v0.3.7/ktctl_0.3.7_Windows_x86_64.zip
+```
+
+### Mesh 服务
+用于将指定服务的部分流量重定向到本地。基本用法如下：
+
+```bash
+ktctl mesh <目标服务名> --expose <本地端口>:<目标服务端口>
+```
+
+命令可选参数：
+
+```
+--mode value         实现流量重定向的路由方式，可选值为 "auto"（默认）和 "manual"
+--expose value       指定目标服务的一个或多个端口，格式为`port`或`local:remote`，多个端口用逗号分隔，例如：7001,8080:80
+--versionMark value  指定本地服务路由的版本标签值，格式可以是 `<标签值>`，`<标签名>:` 或 `<标签名>:<标签值>`
+--skipPortChecking   不必检查指定的本地端口是否有服务监听
+--routerImage value  （仅用于auto模式）指定Router Pod使用的镜像地址
+```
+
+关键参数说明：
+
+- `--mode`提供了两种服务重定向路由的方式。
+  默认的`auto`模式采用Router Pod实现HTTP请求的自动路由，无需额外配置服务网格组件，适用于集群中未部署服务网格的场景。
+  `manual`模式仅将本地服务"混入"集群中，并打上特定的版本Label，开发者自行通过服务网格组件（如Istio）灵活配置路由规则。
+- `--expose`是一个必须的参数，它的值应当与目标Service的`port`属性值相同，若本地运行服务的端口与目标Service的`port`属性值不一致，则应当使用`<本地端口>:<目标Service端口>`的方式来指定。
+- `--versionMark`用于指定路由到本地的Header或Label名称和值。默认值为"version:\<随机生成值\>"，可仅指定标签值，如`--versionMark demo`；可用标签名加冒号的格式仅指定标签名，如`--versionMark kt-mark:`；也可以同时指定标签的名称和值，如`--versionMark kt-mark:demo`。
+  在`auto`模式下，该值实际上是用于路由的Header。在`manual`模式下，该值为附加在通往本地服务的Shadow Pod上额外的Label。
+
+#### 例子
+- KubeConfig 文件需要找运维拿
+```shell
+.\ktctl.exe mesh <目标服务名> --namespace qifu --expose <本地端口>:<目标服务端口> --kubeconfig /env/.kube/KubeConfig
+```

方案/20250401-全链路灰度方案.md

@@ -0,0 +1,94 @@
+<!-- Space: qifu -->
+<!-- Parent: 后端技术&知识&规范 -->
+<!-- Parent: 技术方案 -->
+<!-- Parent: 基建 -->
+<!-- Parent: 02-技术方案 -->
+<!-- Title: 20250401-全链路灰度方案 -->
+
+<!-- Macro: :anchor\((.*)\):
+     Template: ac:anchor
+     Anchor: ${1} -->
+<!-- Macro: \!\[.*\]\((.+)\)\<\!\-\- width=(.*) \-\-\>
+     Template: ac:image
+     Url: ${1}
+     Width: ${2} -->
+<!-- Macro: \<\!\-\- :toc: \-\-\>
+     Template: ac:toc
+     Printable: 'false'
+     MinLevel: 2 
+     MaxLevel: 4 -->
+<!-- Include: 杂项/声明文件.md -->
+
+<!-- :toc: -->
+
+# 全链路灰度方案
+
+## 一、现状
+
+### 业务背景
+
+现有平台多项目多团队同时进行时，各个团队之间的服务发布互相干扰，无法实现有效的测试隔离
+
+## 二、需求
+
+### 业务需求
+
+开发泳道管理，支持多项目、多任务并行开发互不干扰
+
+## 三、设计目标
+
+### 实现的功能
+
+- 灰度服务发布
+- 流量灰度路由
+- 全链路灰度（定时任务、MQ、Redis、RDB 暂时不持支）
+
+## 四、方案对比
+### 方案一、Spring Cloud + Nacos + 负载均衡器实现全链路灰度发布
+https://zhuanlan.zhihu.com/p/29869400585
+
+#### 优点
+- 实现流程不是很复杂
+- 支持响应式编程，灵活性高
+
+#### 缺点
+- 需要代码实现
+
+### 方案二、Istio 灰度方案
+https://www.kubesphere.io/zh/docs/v3.3/pluggable-components/service-mesh/
+https://istio.io/latest/zh/docs/overview/what-is-istio/
+
+#### 优点
+- 云原生
+- 无关技术语言
+- 扩展性好
+- 大团队维护
+
+#### 缺点
+- 维护成本
+
+## 五、方案选择
+基于一下几个需求
+- 实现灰度发布
+- 运维人员只有一个
+- 暂时没有过多的流量治理需求
+- 技术栈只有java
+
+所以建议先使用方案一、后续运维团队增加，流量治理需求增加，运维人员熟悉 istio 后再做迁移部署
+
+## 六、实施步骤
+### 一、核心包扩展灰度链路包
+- 快速集成
+- 无需改动业务代码
+- 后续上 Istio 后可以快速下架
+
+### 二、业务集成
+- 业务引入灰度链路包
+
+### 三、Pipeline 添加对应的灰度参数
+- jenkins 添加对应的灰度 pipeline
+- 灰度 pipeline 添加对应的参数
+
+### 四、部署测试
+
+### 五、运维人员开始熟悉 Istio