Posts

前言 最近在使用 Kubernetes 查看 pod 日志时,发现 pod 日志显示的 ip 不是真实的请求者 ip, 而是 Node 节点的 ip。通过查阅资料发现可以通过设置 externalTrafficPolicy 来显示真实的 IP。 本文对 externaltrafficpolicy 进行一个简单的介绍。 简介 ExternalTrafficPolicy 是 Kubernetes Service 对象的一个属性，它决定了流量如何从集群外部访问 Service。有两个可选值：Cluster 和 Local。 Cluster 模式： 在 Cluster 模式下，流量将通过负载均衡器分发到 Service 的所有 Pod 上。这是传统的负载均衡方式，适用于需要水平扩展和容错的场景。负载均衡器会将流量平均分配给所有可用的 Pod，从而实现负载均衡。 Local 模式： 在 Local 模式下，流量将直接访问与请求最近的节点上运行的 Pod。这种方式避免了负载均衡器的介入，直接将流量定向到本地的 Pod 上。这样可以减少延迟，并且在负载均衡器发生故障时仍然保持可用性。 区别 两种模式有什么区别呢? Cluster 模式 Cluster 模式是默认的模式,Kube-proxy 不管容器在哪个节点上,会公平的转发到某一个节点上，在转发时会替换掉源ip，变成转发的上一个节点的ip.原因是Kube-proxy在做转发的时候，会做一次SNAT (source network address translation)，所以源ip变成了上一个节点的ip地址。 这个模式的优点是负载均衡比较好，缺点是由于转发,可能会有性能损耗。 Local 模式 Local 模式下,请求只转发给本机的容器,不会转发给其它节点的容器,保留了源ip。 这个模式的优缺点跟 Cluster 模式恰恰相反:性能好,负载均衡不好。所以如果想要负载均衡就需要一层 LB 来进行控制。 参考 https://github....

前言 最近发现了一个新的工具-clarity, clarity 是一种免费工具，用于捕获用户使用网站。安装非常简单，可以在数分钟内开始获取数据。 clarity 有以下功能特点: 热点地图: 为你的所有页面自动生成。查看用户点击的位置、他们忽略的内容以及滚动的距离。 insights: 快速发现用户在何处感到灰心，并将这些问题转化为机会。 Google Analytics: 可以方便的与 Google Analytics 关联。 会话录制: 观看用户如何使用你的网站。了解运行顺畅的地方、需要改进的内容，并测试新想法。 copilot: 使用由 GPT 构建的直观对话体验来理解你的分析数据。 接下来就开始介绍 clarity 的简单使用。 clarity 使用 创建项目 登录成功后, 可以选择网站或者移动项目, 这里选择网站，输入相应的信息。 配置代码 填完信息，需要配置相应的代码信息，可以看到有2种方法，一种是知名第三方平台提供的快捷配置方法另一种是手动添加代码。这里选择手动添加代码。 配置信息 根据导览，可以配置一些信息，例如与ga关联，屏蔽一些隐私信息。 查看数据 根据导览的指引配置完信息后,第二天再次登录系统就可以看到数据了。可以看到有4个主要的模块栏目:仪表盘、录制、热度地图、ga，接下来分别介绍这4个部分。 仪表盘 仪表盘主要就是用户在你网站上访问的整体数据的展现。 录制 录制通过名字就可以得知这个是对用户在你页面上浏览情况的录制，可以看到用户的访问的整体情况，点击了哪些元素等。 热度地图 热度地图可以看到网站的哪些页面经常被访问，被访问的页面哪些部分经常被点击。 Google Analytics Google Analytics 主要就是 ga的数据了。 小结 本文简单的介绍了 clarity 的使用,由于目前数据量较少，不能很好的展示 clarity 的功能。 clarity 的代码已经开源了，有兴趣的可以访问 https://github.com/microsoft/clarity?tab=readme-ov-file 查看。 参考 https://clarity.microsoft.com/ https://clarity.microsoft.com/demo/projects/view/3t0wlogvdz/dashboard https://www.capterra.com/p/236349/Microsoft-Clarity/ https://learn.microsoft.com/en-us/clarity/ https://github.com/microsoft/clarity https://learn.microsoft.com/en-us/clarity/ga-integration/ga-integration#how-to-find-and-add-your-account-id-on-google-analytics

前言 本文介绍如何使用 CTE 表达式来简化 PostgreSQL 中的一些复杂查询。那 CTE 表达式是什么呢? CTE 介绍 在 PostgreSql 中 WITH 提供了一种方式来书写在一个大型查询中使用的辅助语句。这些语句通常被称为公共表表达式或CTE（Common Table Expressions），它们可以被看成是定义只在一个查询中存在的临时表。在WITH子句中的每一个辅助语句可以是一个SELECT、INSERT、UPDATE或DELETE，并且WITH子句本身也可以被附加到一个主语句，主语句也可以是SELECT、INSERT、UPDATE或DELETE。在 PostgreSQL 中，WITH 子句提供了一种编写辅助语句的方法，以便在复杂的查询中使用。 使用 该如何创建 CTE 呢, 创建 CTE 的语句如下: 1 2 3 4 5 6 7 8 WITH cte_name AS ( SELECT column1, column2, ... FROM table_name WHERE condition ... ) SELECT * FROM cte_name; 在日常查询中 CTE 用于哪些场景呢: 递归查询：CTE 表达式常用于执行递归查询。通过在 CTE 表达式中引用自身，可以简洁地实现递归操作。 复杂查询：CTE 表达式可以用于构建复杂的查询，将查询逻辑分解为更易于理解和维护的部分。每个 CTE 子查询块可以负责不同的逻辑操作，最终组合成一个完整的查询。 数据转换和重组：CTE 表达式可以用于对数据进行转换和重组。通过在不同的 CTE 子查询块中选择、过滤和连接数据，可以生成新的结果集。 递归查询 WITH 表达式如何实现递归查询呢,可以通过添加 RECURSIVE修饰符来实现。下面是一个示例:...

今天介绍一个常见的设计模式-策略模式，并基于一个简单的例子来讲解。 策略模式介绍 策略模式（Strategy Pattern）是一种行为型设计模式，它将一组算法封装成独立的对象，并使它们可以互相替换。这样做的好处是，可以在运行时动态地改变对象的行为，而不需要修改使用该对象的代码。 何时可以使用策略模式呢 我们在用GO编程的时候经常碰到多层控制语句，一层又一层，既不优雅，也不利于后续维护。比如下述这种： 1 2 3 4 5 6 7 8 if xxx { // do something } else if xxx { // do something } else if xxx { // do something else { } 虽然按这种模式写起来简单快捷，但它也违背了面向对象的两个原则： 单一职责原则：多个控制语句，意味着拥有多种功能； 开闭原则：当要进行修改时，原有代码不可避免要被修改； 此时就可以采用策略模式来替换这类多层控制语句。 go 实现策略模式 go 语言该怎么实现策略模式呢? 在Go语言中，策略模式可以通过接口和函数来实现。首先，我们定义一个接口，该接口声明了算法执行的方法。然后，我们可以为每个具体的算法实现一个结构体，并实现接口中的方法。最后，我们可以在需要使用算法的地方，通过接口来调用具体的算法。 下面通过一个简单的例子来讲解策略模式, 现在有这样一个场景我们现在有2个数据表,这2个数据表拥有相同的字段，都可以根据 name 来查询某个数据，我们需要根据参数的不同来决定使用哪种表进行查询, 在没有使用策略模式时, 我们往往使用大量的if来实现这个操作。 接下来由我来介绍策略模式来实现相同的操作。 先定义查询操作的接口: 1 2 3 type DataStrategy interface { Query(name string) } 定义2张表的查询struct,并实现DataStrategy接口: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 // table1 通过table1 来查询 type table1 struct{} func (s *table1) Query(name string) { fmt....

前言 前段时间看到了一个提案，是关于 go for 循环的一个提案，根据提案看到了去年 rsc 在社区发出的讨论，讨论的内容主要是为了解决 for 循环变量的问题，是什么样的问题呢,常见的例子如下: 1 2 3 4 var all []*Item for _, item := range items { all = append(all, &item) } 这段代码有一个问题，循环结束后，all 的内容是包含了 len(all) 个相同的指针，指针指向迭代的最后一个 item。为什么会发生这种情况呢，因为 item 变量是每个循环的而不是每次迭代的，&item每次迭代都是相同的，并且每次迭代都会被覆盖。 怎么解决呢，最简单的方法就是添加 item := item 这段代码: 1 2 3 4 5 var all []*Item for _, item := range items { item := item all = append(all, &item) } 我在使用 Goroutine 协程时也经常遇到这种问题。这种错误已导致许多公司出现生产问题，包括 Lets Encrypt 公开记录的问题。 go 社区为了解决这个问题，打算将循环变量改为每次迭代，即隐式的添加上面的代码。由于其它一些原因，直到今年的6月才正式决定在 go 1....