diff --git a/content/blog/2020/build-envoy-filter-echo/index.md b/content/blog/2020/build-envoy-filter-echo/index.md
index 84ce2b4..294bf64 100644
--- a/content/blog/2020/build-envoy-filter-echo/index.md
+++ b/content/blog/2020/build-envoy-filter-echo/index.md
@@ -74,7 +74,7 @@ ubuntu@ubuntu:/data/mesh/envoy-filter-example$ bazel build //:envoy
 ## 6. 测试编译后的例子
 ### 6.1 测试流程
 先说一下基本的测试流程，`echo` 这个例子非常好测试，因为它是一个拦截 filter，就是说请求到这个 filter 这里就终止了，不会继续向下游传。而且是正对 tcp 协议的一个 filter，没有使用私有协议，所以测试工具也不用找了，直接使用 telnet 进行测试就好了。如下图所示：
-![](imgs/1.png)
+![](blog/2020/build-envoy-filter-echo/imgs/1.png)
 
 所以测试流程也就非常简单了，罗列如下：
 1. 准备启动配置文件 test.yaml。
diff --git a/content/blog/2020/build-envoy-filter-http/index.md b/content/blog/2020/build-envoy-filter-http/index.md
index 21ddb52..0e4dfd0 100644
--- a/content/blog/2020/build-envoy-filter-http/index.md
+++ b/content/blog/2020/build-envoy-filter-http/index.md
@@ -51,7 +51,7 @@ bazel build //http-filter-example:envoy
 4. 使用命令行 curl 测试
 
 测试示意
-![](imgs/1.png)
+![](blog/2020/build-envoy-filter-http/imgs/1.png)
 
 官网这个 http filter 功能非常简单，其目的就是在 http 请求头中加入一个 kv 健值对，并且是把 key 转换为小写字母。
 ```c++
diff --git a/content/blog/2020/getting-started-with-a-service-mesh-starts-with-a-gateway/index.md b/content/blog/2020/getting-started-with-a-service-mesh-starts-with-a-gateway/index.md
index 12b9dab..6934b40 100644
--- a/content/blog/2020/getting-started-with-a-service-mesh-starts-with-a-gateway/index.md
+++ b/content/blog/2020/getting-started-with-a-service-mesh-starts-with-a-gateway/index.md
@@ -47,7 +47,7 @@ Solo CTO 的文章让我更坚定了我们目前的思路和做法。下面几
 
 如果你想在组织内使用落地服务网格，那么采用基于 Envoy 作为微服务网关是非常好的一个开始。作者在他之前写的一本书《Istio in Action》中就极力介绍 Istio 的[服务网关资源](https://istio.io/docs/tasks/traffic-management/ingress/ingress-control/)。因为把 Envoy 作为入口网关是使用 Istio 的最好的开始方式，这样你在不断熟悉 Isito 和推广服务网格文化，让内部逐步接受，并且探索服务网格的最佳使用方式是非常好的，不用一上来就推动大家都必须启用边车。
 
-![](imgs/1.png)
+![](blog/2020/getting-started-with-a-service-mesh-starts-with-a-gateway/imgs/1.png)
 
 使用基于 Envoy 的服务网关这意味着你不但可以解决你微服务网关的问题，而且还可以逐步实践小型化的服务网格。当你部署了服务网关之后，你就可以强有力的掌控流量和路由了（包括百分比的路由，基于协议头或者方法的路由，还有流量镜像），还有加密传输等。
 
@@ -68,11 +68,11 @@ Solo CTO 的文章让我更坚定了我们目前的思路和做法。下面几
 
 另外还有一堆其它的功能，比如外部鉴权，内容改写等等。
 
-![](imgs/2.png)
+![](blog/2020/getting-started-with-a-service-mesh-starts-with-a-gateway/imgs/2.png)
 
 Gloo 的做法是基于 Envoy 构建了一个强大的微服务网关，而且基于 xDS 配备了一个好用的控制管理端。使得这个微服务网关既可以作为微服务网关，也可以继续深入作为边车使用。而在他们的设计单中，首先是可以作为一个强大的微服务网关来使用。而且他们可以直接和 Istio，Consul， AWS App Mesh 和 Linkerd 等集成。目前他们说已经在很多客户那里落地了。
 
-![](imgs/3.png)
+![](blog/2020/getting-started-with-a-service-mesh-starts-with-a-gateway/imgs/3.png)
 
 在我们的实践单中也是这样一个思路，早期我们使用 OpenResty 来构建我们的微服务网关，插件都是使用 lua 来编写，直到我们 2 年前遇到了 Envoy 和 Isito，我们综合对比考虑之后，采用了 Envoy 最为我们的微服务网关，我们也是和 Consul 结合，利用其 xDS 开发了我们公司内的诸多业务插件，配合使用。目前已经作为微服务网关在内部大量使用。同时也在逐步积累开发一个基于 Envoy 和 Istio 的控制系统。目标是既可以控制微服务网关，也可以控制服务网格，统一的把集群内以及多个集群的网络流量管理做一个统一。
 
diff --git a/content/blog/2020/tencentos-tiny-test/index.md b/content/blog/2020/tencentos-tiny-test/index.md
index 3cf2ed1..7fc1672 100644
--- a/content/blog/2020/tencentos-tiny-test/index.md
+++ b/content/blog/2020/tencentos-tiny-test/index.md
@@ -55,13 +55,13 @@ tencentos tiny 目前是开源的，源码地址在这里：[https://github.com/
 ## 具体效果
 我今天中午用跳线链接了传感器和板子，跑通了整个流程，效果是这样的。
 1. 板子上的效果。
-![](imgs/1.png)
+![](blog/2020/tencentos-tiny-test/imgs/1.png)
 
 2. 板子链接wifi后上报信息到腾讯云上的物联网平台。
-![](imgs/2.png)
+![](blog/2020/tencentos-tiny-test/imgs/2.png)
 
 3. 云上数据告警发送微信。
-![](imgs/3.png)
+![](blog/2020/tencentos-tiny-test/imgs/3.png)
 
 ## 总结
 目前这个板子和系统开发测试中我基本上都是一遍搞定，相对来说开发门槛不高，而且嵌入式发展这么多年这些底层应该都是比较稳定的，包括驱动什么的，难度应该都还好。比我在 12 年前搞的时候要好多了，那个时候很多时候要拿示波器来看发送信号是否正确，真正的底层开发。目前看这个系统在易用性和完整性上还算不错，但是也只是正对低端设备，我不知道公司是基于什么样的考虑要做一块，方正我使用起来还挺流畅。
diff --git a/content/blog/2021/cloud-native/index.md b/content/blog/2021/cloud-native/index.md
index a19e980..10aca80 100644
--- a/content/blog/2021/cloud-native/index.md
+++ b/content/blog/2021/cloud-native/index.md
@@ -105,7 +105,7 @@ CNCF在定义中给出了云原生的关键技术：容器、服务网格、微
 
 Pivotal 公司对云原生的最新定义为 4 个要点：DevOps、持续交付、微服务、容器。如下图。
 
-![](imgs/5.png)
+![](blog/2021/cloud-native/imgs/5.png)
 
 这次的定义和总结，我认为才真正把云，云原生和应用联系起来了。所以我认为这个定义是相对比较清晰合理的，从而能真正指导了云原生技术的发展。从另外一个角度可以说：一个明确的定义可以推动一个技术能更好的发展。
 
diff --git a/content/blog/2021/cloud-native2/index.md b/content/blog/2021/cloud-native2/index.md
index a7aa1f5..7e21a3e 100644
--- a/content/blog/2021/cloud-native2/index.md
+++ b/content/blog/2021/cloud-native2/index.md
@@ -41,7 +41,7 @@ draft: false
 
 下面这幅图可以看出一般 VM 和容器方式的区别。
 
-![](imgs/2.png)
+![](blog/2021/cloud-native2/imgs/2.png)
 
 **容器提供的方式是标准化的，可以将不同应用程序的不同组件组装在一起，又可以将它们彼此隔离。**
 
@@ -74,7 +74,7 @@ Docker 项目是当前最受欢迎的容器实现，以至于很多人通常都
 ### 容器编排发展 
 所以容器的编排技术应运而生，从容器诞生起就有在做这方面的工作了，主要的有 Mesos，Swarm，Kuberneters，另外还有其它小型的就更多了。而且现在有了 CRI 标准，实现一个简单的容器调度管理服务也不是太复杂，曾经面试过几个大学生，大学期间就参与过这类项目的开发工作。一般主要是针对一些特殊环境的定制开发。
 
-![](imgs/3.png)
+![](blog/2021/cloud-native2/imgs/3.png)
 
 Kubernetes 源自Google 15 年生产环境的运维经验，同时凝聚了社区的最佳创意和实践。从 Mesos，Swarm，Kuberneters 三个开始争夺天下，到最后 Kuberneters 一统天下也就不过 3 年时间。而且目前 Kuberneters 的开源社区非常活跃，我们本人也参与了 Kuberneters 社区的 2 个项目：
 >1. 社区文档项目：我主要参与中文文档的翻译和review。
@@ -88,7 +88,7 @@ Kubernetes 源自Google 15 年生产环境的运维经验，同时凝聚了社
 
 Kuberneters 的架构非常简单清晰，但是功能也确实非常强调，这里可以看看它的基本架构。
 
-![](imgs/5.png)
+![](blog/2021/cloud-native2/imgs/5.png)
 
 下面我简要的说一下 K8S 架构中的各个模块。
 ### Master
diff --git a/content/blog/2021/cloud-native3/index.md b/content/blog/2021/cloud-native3/index.md
index e69c6df..f610e8d 100644
--- a/content/blog/2021/cloud-native3/index.md
+++ b/content/blog/2021/cloud-native3/index.md
@@ -66,13 +66,13 @@ draft: false
 
 ## 云原生交付部署：不可变基础设施：镜像
 这是镜像的宣传口号：Build, Ship, and Run Any App, Anywhere。
-![](imgs/6.png)
+![](blog/2021/cloud-native3/imgs/6.png)
 
 在这块镜像确实是做到了这一点，OCI 的成立，让容器镜像在只要符合 OCI 标准的环境下就可以使用，无论是 windows 还是 linux，包括不同版本的 linux。
 
 ## 容器镜像仓库
 就如上图一样，镜像总是要保存在一个地方，这也就催生了另外一个技术专门做镜像的存储，我们叫这个技术为镜像仓库技术。解决镜像的基本存储，延伸的功能还有镜像的声明周期管理，安全扫描，镜像分发加速等等。目前提供这类服务的商业公司也有很多，同时也有免费的镜像仓库，比如 docker 公司的这个，大家可以浏览看看：[https://hub.docker.com/](https://hub.docker.com/)。
-![](imgs/3.png)
+![](blog/2021/cloud-native3/imgs/3.png)
 
 目前我们内部使用的腾讯云的 tcr，也是比较好用的，而且提供了安全扫描，镜像分发加速等能力。TCR提供安全独享、高性能的容器镜像托管分发服务。可同时在全球多个地域创建独享实例，以实现容器镜像的就近拉取，降低拉取时间，节约带宽成本。
 [https://cloud.tencent.com/product/tcr](https://cloud.tencent.com/product/tcr)。
diff --git a/content/blog/2021/eBPF-and-XDP/index.md b/content/blog/2021/eBPF-and-XDP/index.md
index 108257b..f9d3d11 100644
--- a/content/blog/2021/eBPF-and-XDP/index.md
+++ b/content/blog/2021/eBPF-and-XDP/index.md
@@ -48,7 +48,7 @@ socket 缓冲区的结构体由多个字段，来标识不同的网络层。从
 在裸机速度下的 eBPF 和 XDP 包处理流程
 
 在网络协议栈中的 XDP 的钩子
-![](imgs/1.png)
+![](blog/2021/eBPF-and-XDP/imgs/1.png)
 
 具体上来看在软中断任务中调度顺序执行的 iptables 规则，会在 IP 协议层中去匹配指定的 IP 地址，以决定是否丢弃这个数据包。和 iptables 不一样的是 XDP 会直接操作一个从 DMA 后端环形缓冲区中拿的原始的以太帧包，所以丢弃逻辑可以很早的执行，这样就节省了内核时间，避免了会导致协议栈执行导致的延时。
 
diff --git a/content/blog/2021/kube-proxy-modes-iptables-or-IPVS/index.md b/content/blog/2021/kube-proxy-modes-iptables-or-IPVS/index.md
index 321fb64..6f945ab 100644
--- a/content/blog/2021/kube-proxy-modes-iptables-or-IPVS/index.md
+++ b/content/blog/2021/kube-proxy-modes-iptables-or-IPVS/index.md
@@ -50,7 +50,7 @@ OK，虽然说 kube-proxy 的链接处理在 iptables 模式下是 O(n) 的复
 
 为了说明这些区别，我们测试了有链接复用和没有链接复用的情况。在链接复用的情况下，我们使用 NGINX 的默认配置，默认配置设置了每个存活链接可以给最多100个请求复用。看下面的图，越低的响应延时越好。
 
-![](imgs/1.png)
+![](blog/2021/kube-proxy-modes-iptables-or-IPVS/imgs/1.png)
 
 这个图展示 2 个关键的东西：
 
@@ -64,7 +64,7 @@ OK，虽然说 kube-proxy 的链接处理在 iptables 模式下是 O(n) 的复
 ## 总 CPU
 为了说明总 CPU 使用率，下图就聚焦于没有使用持久链接的最坏情况，这样对 kube-proxy 的链接处理开销的影响是最大的。
 
-![](imgs/2.png)
+![](blog/2021/kube-proxy-modes-iptables-or-IPVS/imgs/2.png)
 
 这图展示了 2 个关键事情：
 1. 在 iptables 和 IPVS 模式下 CPU 使用率的区别是直到后端 service 超过 1000 个的时候才比较明显。（每个后端还是 10000 个 pod）。
@@ -89,7 +89,7 @@ OK，虽然说 kube-proxy 的链接处理在 iptables 模式下是 O(n) 的复
 
 要正确的看这个事情，下面的图展示了 kube-proxy 和 Calico 对每个链接处理的平均 iptables 规则数量，假设集群中的每个节点上平均有 30 个 pod，每个 pid 平均有 3 个网关处理策略。
 
-![](imgs/3.png)
+![](blog/2021/kube-proxy-modes-iptables-or-IPVS/imgs/3.png)
 
 甚至当集群中全力运行有 10000 个 service 和 100000 个后端 pod，Calico 在每个连接上执行的 iptables 规则数量与kube-proxy 在 20 个服务和 200 个后端 pod 上执行的 iptables 规则数量大致相同。换句话说，Calico 使用 iptables 是非常高效的。
 
diff --git a/content/blog/2021/ms-thinking/index.md b/content/blog/2021/ms-thinking/index.md
index 09d3998..c7a1675 100644
--- a/content/blog/2021/ms-thinking/index.md
+++ b/content/blog/2021/ms-thinking/index.md
@@ -22,28 +22,28 @@ draft: false
 
 这是我分享的3个方面：技术的执念，和其中2个模块建设的意义。
 
-![](imgs/1.png)
+![](blog/2021/ms-thinking/imgs/1.png)
 
 首先是技术的执念，无论是之前的数据服务平台还是现在在做的微服务开发平台，我们都是有一个技术人的执念在哪里，希望能够有一个平台，方便的提供服务建设和服务组装。希望能够屏蔽底层技术的复杂性，让开发者更关注业务和业务能力的创新。能提供一个有规模化生产服务能力的平台。
-![](imgs/2.png)
+![](blog/2021/ms-thinking/imgs/2.png)
 
 所以这里就衍生出来2个关键思路：1.微服务，2.平台化。
 
-![](imgs/3.png)
+![](blog/2021/ms-thinking/imgs/3.png)
 
 这几年我一直也在思考我们使用技术的目的和意义是什么？我不知道大家有没有思考过？我们问什么要用这个技术？是因为很这个技术火热？这个技术能解决我的问题？还是其它的原因呢？
 
 这里我也想说一下，我对我们在微服务开发平台上使用2个技术思路的思考。
 首先是微服务化的意义是什么？
 
-![](imgs/4.png)
+![](blog/2021/ms-thinking/imgs/4.png)
 
 这是一张典型的微服务架构，前端，后端，后端分不同的模块进行建设。每个模块可以由不同的人来负责开发。
 大家看到微服务就仅此而已吗？拆分一下就好了？不同的人来开发就好了？微服务这么简单？
 
 我对微服务的思考是这样的：是一种软件开发新的合作模式，是软件开发中体系化的分工协作模式。
 
-![](imgs/5.png)
+![](blog/2021/ms-thinking/imgs/5.png)
 
 通过微服务的建设，让更多的人可以更低成本的加入到你的系统建设中来。让新来的同学不需要了解整个系统的所有代码，只需要熟悉掌握自己要做的模块，和其它模块对接的标准就可以了。系统的复杂性大大减低的同时，让其他人更容易进行协作贡献自己的力量。
 
@@ -52,7 +52,7 @@ draft: false
 以往的做法是一个开发要掌握整个系统，我全都要，张小龙同学一个人可以完成foxmail的研发，现在已然是不再可能的事情了。而现在希望是大家能以标准化的方式接入云化的一个系统，可以只贡献自己专注的能力即可。让自己成为云上服务的某种能力的提供者。
 再是平台化的意义是什么？
 
-![](imgs/6.png)
+![](blog/2021/ms-thinking/imgs/6.png)
 
 俗话说：没有约束的自由不是真自由。这里也是一样，微服务的模式是解决了大家在软件开发上的分工协作问题，但是这是一种思想。我们要让这种思想落地的时候，就必须要对他进行抽象化和标准化。抽象化的标准的目的是为了能够找出解决一类问题的方法，可以让大家在解决这类问题的时候可以有同样的解决方案，提升复用性。
 
@@ -64,7 +64,7 @@ draft: false
 1. 以微服务为基础的大规模软件开发模式持续流行，多大规模呢？全球合作一定是少不了的。
 2. 以技术抽象和标准化规范化为基础的开发平台模式，以持续提升产能，加强合作效率
 
-![](imgs/7.png)
+![](blog/2021/ms-thinking/imgs/7.png)
 
 我们的征程是星辰大海，在技术的路上，我们还需要不断的努力，不断的探索。
 
diff --git a/content/blog/2022/gartner-2023-top-10-tech/Gartner-2023-Top-10-tech.md b/content/blog/2022/gartner-2023-top-10-tech/Gartner-2023-Top-10-tech.md
index 717529b..7abfcf1 100644
--- a/content/blog/2022/gartner-2023-top-10-tech/Gartner-2023-Top-10-tech.md
+++ b/content/blog/2022/gartner-2023-top-10-tech/Gartner-2023-Top-10-tech.md
@@ -80,7 +80,7 @@ Gartner发布了《2023年十大战略技 术趋势》报告。该报告可以
 ### • Gartner预测 
 到 2026 年，80% 的软件工程组织将建立平台团队，其中 75% 将包含开发者自助服务门户。
 
-![](imgs/7.png)
+![](blog/2022/gartner-2023-top-10-tech/imgs/7.png)
 
 ## 无线价值实现(Wireless Value Realization)
 无线价值实现了从传统终端用户计算，到支持边缘设备再到数字标签解决方案的方方面面。所有这些都需要连接才能运行，并且需要一系列无线解决方案来满足所有环境的需求。
@@ -89,7 +89,7 @@ Gartner发布了《2023年十大战略技 术趋势》报告。该报告可以
 ### • Gartner预测 
 到 2025 年，50% 的企业无线端点将使用网络服务，提供通信以外的其他功能，而这一比例低于 15%。
 
-![](imgs/8.png)
+![](blog/2022/gartner-2023-top-10-tech/imgs/8.png)
 
 ## 超级应用(Superapps)
 超级应用是为最终用户(例如，客户、合作伙伴或员工)提供一组核心功能，以及访问独立创建小应用(mini apps)的应用。超级应用程序被构建为一个平台，可提供一致和个性化的应用程序体验。
@@ -98,7 +98,7 @@ PayPay 是一家日本支付提供商，拥有近 5000 万用户。其增长战
 ### • Gartner预测 
 到 2027 年，全球超过 50% 的人口将成为多个超级应用的日活跃用户。
 
-![](imgs/9.png)
+![](blog/2022/gartner-2023-top-10-tech/imgs/9.png)
 
 ## 自适应人工智能(Adaptive AI)
 自适应人工智能系统不断地重新训练模型并根据新数据在运行时和开发环境中学习，以快速适应初始 开发期间未预见或不可用的环境变化。
@@ -107,7 +107,7 @@ PayPay 是一家日本支付提供商，拥有近 5000 万用户。其增长战
 ### • Gartner预测 
 到 2026年，采用AI工程实践来构建和管理自适应 AI 系统的企业，将在AI模型的可操作性方面优于同行至少 25%。
 
-![](imgs/10.png)
+![](blog/2022/gartner-2023-top-10-tech/imgs/10.png)
 
 
 ## 元宇宙(Metaverse)
@@ -117,7 +117,7 @@ PayPay 是一家日本支付提供商，拥有近 5000 万用户。其增长战
 ### • Gartner预测 
 到 2027 年，全球超过 40% 的大型企业机构将在基于元 宇宙的项目中使用Web3、增强现实(AR)云和数字 孪生的组合来增加收入。
 
-![](imgs/11.png)
+![](blog/2022/gartner-2023-top-10-tech/imgs/11.png)
 
 ## 可持续技术(Sustainability)
 可持续技术是一种解决方案框架，可提高 IT服务的能源和效率;通过可追溯性、分析、可再生能源等技术实现企业可持续发展;并通过应用程序、软件、市场等帮助客户变得更具可持续性。
@@ -127,7 +127,7 @@ PayPay 是一家日本支付提供商，拥有近 5000 万用户。其增长战
 ### • Gartner预测  
 到 2025 年，50% 的 CIO 将拥有与 IT 组织的可持续性相 关的绩效指标。
 
-![](imgs/12.png)
+![](blog/2022/gartner-2023-top-10-tech/imgs/12.png)
 
 完整报告地址： https://www.gartner.com/en/articles/gartner-top-10-strategic-technology-trends-for-2023
 
diff --git a/content/blog/2022/kubeshark/Kubeshark.md b/content/blog/2022/kubeshark/Kubeshark.md
index 90ad0f0..f87cc31 100644
--- a/content/blog/2022/kubeshark/Kubeshark.md
+++ b/content/blog/2022/kubeshark/Kubeshark.md
@@ -30,7 +30,7 @@ Kubeshark 也被叫做 Kubernetes 的可观测性工具，可以对微服务进
 2. Kubeshark 可以嗅探集群中的部分或所有 TCP 流量，将其记录到 PCAP 文件中并剖析。
 3. Kubeshark 使用 eBPF 来跟踪内核空间和用户空间中的函数调用。
 
-![](imgs/2.png)
+![](blog/2022/kubeshark/imgs/2.png)
 
 ## 二、Kubeshark 架构
 
@@ -39,7 +39,7 @@ Kubeshark 由三个不同的软件组成，它们可以协同工作：CLI、Hub
 1. CLI，它是客户端的 二进制文件，通过 K8s API 与集群通信。
 2. Hub，它协调 worker 部署，接收来自每个 worker 的嗅探和剖析，并收集到一个中心位置。它还提供一个Web界面，用于在浏览器上显示收集到的流量。
 3. Work，作为 DaemonSet 部署到集群中，以确保集群中的每个节点都被 Kubeshark 覆盖。
-![](imgs/3.png)
+![](blog/2022/kubeshark/imgs/3.png)
 
 ## 三、Kubeshark 功能
 ### 1）Kubeshark 功能 - 网络嗅探
@@ -50,7 +50,7 @@ Kubeshark 可以使用 Linux 内核中内置的各种方法和 API 嗅探集群
 2. 基于 eBPF 抓包，基于 eBPF 的数据包捕获使用 eBPF 嗅探集群中的加密流量 (TLS)，而无需实际进行解密。事实上，它挂钩到 OpenSSL 库和 Go 的 crypto/tls 包中某些函数的入口点和出口点。
 
 ###  2）Kubeshark 功能 – 查询
-![](imgs/4.png)
+![](blog/2022/kubeshark/imgs/4.png)
 ### 3）Kubeshark 功能 – 内核跟踪
 Kubeshark 使用 🐝 eBPF（扩展伯克利数据包过滤器）提供跟踪内核空间和用户空间功能。
 ``` sh
@@ -59,7 +59,7 @@ Kubeshark 使用 🐝 eBPF（扩展伯克利数据包过滤器）提供跟踪内
 kubeshark tap --tls -n harbor
 ```
 
-![](imgs/5.png)
+![](blog/2022/kubeshark/imgs/5.png)
 
 ### 3）Kubeshark 功能 – 流量校验
 Kubeshark 具有流量验证功能，可与网络嗅探器功能结合使用。
@@ -81,7 +81,7 @@ rules:
 
 部署完成后，Kubeshark CLI 将在 http://localhost:8899 打开 UI 单击右上角名为 Service Map 的按钮打开服务依赖关系图。该图根据网络流量显示 Pod 以及它们之间的关系。
 
-![](imgs/6.png)
+![](blog/2022/kubeshark/imgs/6.png)
 
 ### 5）Kubeshark 功能 – 数据脱敏
 Kubeshark 捕获的流量包含敏感信息。用户可以配置 Kubeshark 以隐藏某些关键字或数据片段将在 UI 中显示为 [REDACTED]。
diff --git a/content/blog/2022/microservices-design-patterns/index.md b/content/blog/2022/microservices-design-patterns/index.md
index 48418b5..45da826 100644
--- a/content/blog/2022/microservices-design-patterns/index.md
+++ b/content/blog/2022/microservices-design-patterns/index.md
@@ -43,7 +43,7 @@ draft: false
 
 
 
-![](imgs/1.png)
+![](blog/2022/microservices-design-patterns/imgs/1.png)
 
 _微服务设计模式_
 
@@ -191,7 +191,7 @@ There will be multiple dependencies of for single services or microservice eg: S
 这些事件持久化存储在充当系统记录系统的事件存储中。事件存储系统中事件发布的典型应用场景是：在应用中保持实体的物化视图和事件的动作一样来改变他们，以及集成的外部系统。例如系统可以维护一个针对所有用户的物化视图，用来填充UI部分的数据。当应用程序添加新订单，添加或删除订单上的项目以及添加运输信息时，这些事件描述了这些数据变化可以被处理并且可以更新到物化视图上。下面是这个模式的纵览：
 
 
-![](imgs/2.png)
+![](blog/2022/microservices-design-patterns/imgs/2.png)
 
 Event Sourcing pattern[8]
 
@@ -201,7 +201,7 @@ Event Sourcing pattern[8]
 
 -   编排（Choreography）指导  — 如果没有中央服务协调，则每个服务都会产生并侦听另一个服务的事件，并决定是否应采取措施。编排是指定两个或两个以上参与者的方式。 每一个参与者都无法控制对方的流程，或者任意可见的流程，这些可见的流程可以协调他们的活动和流程以共享信息和数值。当需要跨控制/可见性域进行协调时，请使用 Choreography 编排指导 。你可以在简单的情况下将编排视为网络协议，它规定了各参与者之间可接受的请求和响应模式。
 
-![](imgs/3.png)
+![](blog/2022/microservices-design-patterns/imgs/3.png)
 
   
 
@@ -211,7 +211,7 @@ Saga pattern — Choreography
 
 - Orchestration —  一个Orchestration （对象）负责 Saga 的决策和业务逻辑顺序。当你已经控制流程中的所有参与者时，当它们全部处于一个控制范围内时，你可以控制活动的流程。当然，通常情况下，当你制定一个组织内的业务流程时，你已经控制了它。
 
-![](imgs/4.png)
+![](blog/2022/microservices-design-patterns/imgs/4.png)
 
 Sage pattern — Orchestration  
 
@@ -264,7 +264,7 @@ Sage pattern — Orchestration
 -   客户端，例如：Netflix Eureka
 -   服务端：例如： AWS ALB
 
-![](imgs/5.png)
+![](blog/2022/microservices-design-patterns/imgs/5.png)
 服务发现 [9]
 
 ### **断路器模式（Circuit Breaker Pattern）**
@@ -273,7 +273,7 @@ Sage pattern — Orchestration
 
 消费者应通过代理来调用远程服务，该代理的行为类似于电路中的断路器。当连续的请求失败的次数超过阈值时，断路器将跳闸一段时间，并且在跳闸的这段时间内，所有远程服务调用的尝试都将立即失败。当超过了断路器跳闸时间之后，断路器将允许有限数量的测试请求通过。如果这些请求成功，则断路器将恢复正常操作。否则，如果有一个请求失败，则断路器再次跳闸。对于一个应用试图尝试调用另一个远程服务或者获取共享资源，并且该操作很容易的失败的情况来说， 这个模式非常适用。
 
-![](imgs/6.png)
+![](blog/2022/microservices-design-patterns/imgs/6.png)
 
  断路器模式Circuit Breaker Pattern [10]  
 
@@ -283,7 +283,7 @@ Sage pattern — Orchestration
 
 蓝绿发布模式可以减少或消除停机时间，它的做法是通过运行切换两个相同的生产环境：Blue 和 Green。这里我们假设 Green 是已存在的工作实例，Blue 是该应用程序的新版本。在任何时候，只有一个环境处于服务状态，该服务环境为所有生产流量提供服务。 所有云平台均提供了用于实施蓝绿色部署的选项。
 
-![](imgs/7.png)
+![](blog/2022/microservices-design-patterns/imgs/7.png)
 蓝绿发布模式Blue-Green Deployment Pattern
 
 **References**  
diff --git a/content/blog/2024/aihao/imgs/1.png b/content/blog/2024/aihao/imgs/1.png
new file mode 100644
index 0000000..6a7e51d
Binary files /dev/null and b/content/blog/2024/aihao/imgs/1.png differ
diff --git a/content/blog/2024/aihao/imgs/10.png b/content/blog/2024/aihao/imgs/10.png
new file mode 100644
index 0000000..2dd3d89
Binary files /dev/null and b/content/blog/2024/aihao/imgs/10.png differ
diff --git a/content/blog/2024/aihao/imgs/11.png b/content/blog/2024/aihao/imgs/11.png
new file mode 100644
index 0000000..2b14fab
Binary files /dev/null and b/content/blog/2024/aihao/imgs/11.png differ
diff --git a/content/blog/2024/aihao/imgs/12.png b/content/blog/2024/aihao/imgs/12.png
new file mode 100644
index 0000000..6a51fb9
Binary files /dev/null and b/content/blog/2024/aihao/imgs/12.png differ
diff --git a/content/blog/2024/aihao/imgs/13.png b/content/blog/2024/aihao/imgs/13.png
new file mode 100644
index 0000000..3553209
Binary files /dev/null and b/content/blog/2024/aihao/imgs/13.png differ
diff --git a/content/blog/2024/aihao/imgs/14.png b/content/blog/2024/aihao/imgs/14.png
new file mode 100644
index 0000000..0f5ad6b
Binary files /dev/null and b/content/blog/2024/aihao/imgs/14.png differ
diff --git a/content/blog/2024/aihao/imgs/15.png b/content/blog/2024/aihao/imgs/15.png
new file mode 100644
index 0000000..ca6967c
Binary files /dev/null and b/content/blog/2024/aihao/imgs/15.png differ
diff --git a/content/blog/2024/aihao/imgs/16.png b/content/blog/2024/aihao/imgs/16.png
new file mode 100644
index 0000000..7bd3d68
Binary files /dev/null and b/content/blog/2024/aihao/imgs/16.png differ
diff --git a/content/blog/2024/aihao/imgs/17.png b/content/blog/2024/aihao/imgs/17.png
new file mode 100644
index 0000000..59fe5e5
Binary files /dev/null and b/content/blog/2024/aihao/imgs/17.png differ
diff --git a/content/blog/2024/aihao/imgs/18.png b/content/blog/2024/aihao/imgs/18.png
new file mode 100644
index 0000000..f6e820f
Binary files /dev/null and b/content/blog/2024/aihao/imgs/18.png differ
diff --git a/content/blog/2024/aihao/imgs/2.png b/content/blog/2024/aihao/imgs/2.png
new file mode 100644
index 0000000..31eb28a
Binary files /dev/null and b/content/blog/2024/aihao/imgs/2.png differ
diff --git a/content/blog/2024/aihao/imgs/3.png b/content/blog/2024/aihao/imgs/3.png
new file mode 100644
index 0000000..0527d0f
Binary files /dev/null and b/content/blog/2024/aihao/imgs/3.png differ
diff --git a/content/blog/2024/aihao/imgs/4.png b/content/blog/2024/aihao/imgs/4.png
new file mode 100644
index 0000000..f6ec1fc
Binary files /dev/null and b/content/blog/2024/aihao/imgs/4.png differ
diff --git a/content/blog/2024/aihao/imgs/5.png b/content/blog/2024/aihao/imgs/5.png
new file mode 100644
index 0000000..98f1950
Binary files /dev/null and b/content/blog/2024/aihao/imgs/5.png differ
diff --git a/content/blog/2024/aihao/imgs/6.png b/content/blog/2024/aihao/imgs/6.png
new file mode 100644
index 0000000..87c2e20
Binary files /dev/null and b/content/blog/2024/aihao/imgs/6.png differ
diff --git a/content/blog/2024/aihao/imgs/7.png b/content/blog/2024/aihao/imgs/7.png
new file mode 100644
index 0000000..323fe30
Binary files /dev/null and b/content/blog/2024/aihao/imgs/7.png differ
diff --git a/content/blog/2024/aihao/imgs/8.png b/content/blog/2024/aihao/imgs/8.png
new file mode 100644
index 0000000..63cd085
Binary files /dev/null and b/content/blog/2024/aihao/imgs/8.png differ
diff --git a/content/blog/2024/aihao/imgs/9.png b/content/blog/2024/aihao/imgs/9.png
new file mode 100644
index 0000000..5b6b4e3
Binary files /dev/null and b/content/blog/2024/aihao/imgs/9.png differ
diff --git a/content/blog/2024/aihao/index.md b/content/blog/2024/aihao/index.md
new file mode 100644
index 0000000..c5cf109
--- /dev/null
+++ b/content/blog/2024/aihao/index.md
@@ -0,0 +1,108 @@
+---
+title: "快速给公众号接入腾讯混元大模型"
+date: 2024-09-24T08:45:20+08:00
+tags: ["产品服务", " 大模型"]
+categories: ["产品服务", "大模型"]
+banner: "/blog/2024/aihao/imgs/1.png"
+author: "helight"
+authorlink: "http://helight.cn"
+summary: ""
+keywords: ["产品服务", "大模型"]
+draft: false
+---
+
+## 引言
+
+最近也折腾了一下大模型的使用，目前看大模型的智能程度已经不错了，至少在文字类的工作中处理中应该是非常有优势，而且目前很多工具都非常成熟，使用门槛也减低了一定程度。
+
+前几天折腾了 dify，感觉配置非常方便，很多工作拖拖拉拉的就可以搞定。所以今天也看了一下腾讯混元的一个服务：腾讯元器。也是可以通过拖拖拉拉就可以搭建一个大模型的使用 bot。
+
+让我非常惊讶的是，我发现可以直接和公众号绑定，而且可以可以把公众号中的内容作为私有数据库，做一个公众号 RAG 应用。
+
+先看看效果：
+
+![](./imgs/1.png)
+
+## 操作详解
+
+### 创建智能体
+元器网址：https://yuanqi.tencent.com/
+
+![](./imgs/2.png)
+
+在这里直接添加一个智能体，我这里已经添加了，可以直接看我添加的内容。如下图展示，主要是名称，介绍，头像，角色设定等等信息。
+
+![](./imgs/3.png)
+
+我这里要展示的是公众号内容的展示，所以这里重点是要把公众的内容关联起来，如下图配置，添加知识库。
+
+### 使用公众号内容创建知识库
+![](./imgs/4.png)
+
+点击添加之后会有一个：创建知识库，在创建知识库的时候选择公众号文章。
+
+![](./imgs/5.png)
+
+这里需要公众号授权，也是非常简单，有多个公众号的话，要选择你要创建知识库的号，这里就会自动去拉去公众号的文章作为知识库内容了。
+
+![](./imgs/6.png)
+
+添加了之后看知识库这里就会有一个项目，这里就是刚刚添加的公众内容组成的知识库了。
+
+![](./imgs/7.png)
+
+可以点击知识库看具体的一些配置信息。
+
+![](./imgs/8.png)
+
+可以看到这里有 107 篇文章录入，如果有文章处理问题也会展示。
+
+![](./imgs/9.png)
+
+可以到里面看具体的问题是什么，目前看知识库重点处理的还是文字信息，对于图片信息处理还是不太支持。这里我这篇文章就是文字太少。
+
+![](./imgs/10.png)
+
+可以点击刷新让知识库继续处理。
+
+![](./imgs/11.png)
+
+正常处理的内容都是这样的。
+
+![](./imgs/12.png)
+
+### 智能体发布使用
+在智能要发布审批之后才能使用， 主要使用方式有 4 种，
+1. 网页直接使用，就是腾讯元器
+2. 小程序或者 app 使用，腾讯元宝
+3. 直接扫码进公众号使用
+4. 使用 api 调用
+
+![](./imgs/13.png)
+
+下图是网页直接使用。
+
+![](./imgs/14.png)
+
+### 绑定到公众号菜单中使用
+
+首先要登录公众号，把元宝的这个小程序绑定到公众号上，绑定方式如下图。
+
+![](./imgs/15.png)
+
+在元器中点击使用方式中的腾讯元宝，在这里获取元宝小程序的 appid 和小程序路径。
+
+![](./imgs/16.png)
+
+把这两个信息填写到公众号菜单中，然后发布即可
+
+![](./imgs/17.png)
+
+这样就可以直接在公众号的菜单中访问，但是我发现直接和公众号对话也是可以调用的。
+![](./imgs/18.png)
+
+## 总结
+
+目前 ai 的发展实在太快了，各方面的应用都是飞速发展。尤其在文生文方面已经是比较成熟了。这里直接快捷的把小程序私有内容和大模型结合确实是一个非常好的落地点。
+
+但是这里怎么发挥更大的价值还有待进一步探索。
\ No newline at end of file