add blog ai to gongzhonghao

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。

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++

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 的控制系统。目标是既可以控制微服务网关，也可以控制服务网格，统一的把集群内以及多个集群的网络流量管理做一个统一。
 

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 年前搞的时候要好多了，那个时候很多时候要拿示波器来看发送信号是否正确，真正的底层开发。目前看这个系统在易用性和完整性上还算不错，但是也只是正对低端设备，我不知道公司是基于什么样的考虑要做一块，方正我使用起来还挺流畅。

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)
 
 这次的定义和总结，我认为才真正把云，云原生和应用联系起来了。所以我认为这个定义是相对比较清晰合理的，从而能真正指导了云原生技术的发展。从另外一个角度可以说：一个明确的定义可以推动一个技术能更好的发展。
 

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

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)。

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 后端环形缓冲区中拿的原始的以太帧包，所以丢弃逻辑可以很早的执行，这样就节省了内核时间，避免了会导致协议栈执行导致的延时。
 

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 是非常高效的。
 

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)
 
 我们的征程是星辰大海，在技术的路上，我们还需要不断的努力，不断的探索。
 

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
 

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]。