gRPC 中的负载均衡包括服务端负载均衡和客户端负载均衡，本文将介绍客户端负载均衡，gRPC 中的客户端负载均衡主要有 2 个部分:1) Name Resolver 2) Load Balancing Policy 接下来将依次介绍。 Name Resolver gRPC 中的默认 name-system 是 DNS , 同时各种客户端还提供了插件以使用自定义 name-system。gRPC Name Resolver 会根据 name-system 进行对应的解析，将用户提供的名称转换为对应的地址。 Load Balancing Policy gRPC 中内置了多种负载均衡策略，本文将介绍常见的几种负载均衡策略:1) pick_first 2) round_robin pick_first pick_first 是默认的负载均衡策略，该策略从 Name Resolver 获得到服务器的地址列表，按顺序依次对每个服务器地址进行连接，直到连接成功，如果某个地址连接成功则所有的 RPC 请求都会发送到这个服务器地址。 round_robin round_robin 策略，该策略从 Name Resolver 获得到服务器的地址列表，依次将请求发送到每一个地址，例如第一个请求将发送到 backend1 ,第二个请求将发送到 backend2。 接下来分别使用这两种策略进行测试。 例子 我们先创建服务端，循环创建了 3 个服务端，分别使用 30051、30052、30053 端口。 package main import ( "context" "fmt" "log" "net" "sync" "google.golang.org/grpc" pb "github.com/overstarry/grpc-example/proto/echo" ) var ( addrs = []string{":30051", ":30052",":30053"} ) type ecServer struct { pb.UnimplementedEchoServer addr string } func (s *ecServer) UnaryEcho(ctx context.Context, req *pb.EchoRequest) (*pb.EchoResponse, error) { return &pb.EchoResponse{Message: fmt.Sprintf("%s (from %s)", req.Message, s.addr)}, nil } func startServer(addr string) { lis, err := net.Listen("tcp", addr) if err != nil { log.Fatalf("failed to listen: %v", err) } s := grpc.NewServer() pb.RegisterEchoServer(s, &ecServer{addr: addr}) log.Printf("serving on %s\n", addr) if err := s.Serve(lis); err != nil { log.Fatalf("failed to serve: %v", err) } } func main() { var wg sync.WaitGroup for _, addr := range addrs { wg.Add(1) go func(addr string) { defer wg.Done() startServer(addr) }(addr) } wg.Wait() } 接下来创建对应的客户端连接： ...

前面的文章介绍了 gRPC 相关的功能，今天继续介绍 gRPC 的功能，本文将介绍 gRPC 的重试功能。 介绍 请求的重试是一个常见的功能，在我们日常的使用中，如果需要重试请求往往需要使用外部包进行实现，在 gRPC 中内置了重试了功能，不需要我们自己实现。 通过查阅 gRPC 的文档可以看到，gRPC 会根据开发者设定的策略进行失败 RPC 的重试，有两种策略 1) 重试策略：重试失败的 RPC 请求 2) hedging 策略：并行发生相同 RPC 请求。单个 RPC 请求可以选择两种重试策略中的一种，不能同时选择多种策略。 重试策略有以下参数可以使用： maxAttempts: 必填 RPC 最大请求次数，包括原始请求 initialBackoff, maxBackoff, backoffMultiplier: 必填 决定下次重试前的延迟时间 random(0, min(initialBackoff*backoffMultiplier**(n-1), maxBackoff)) retryableStatusCodes: 必填 收到服务器非正常状态码时，根据 retryableStatusCodes 中的状态码列表决定是否重试请求 hedging 策略可以主动发送单个请求的多个副本，而无需等待响应。需要注意的是，此策略可能会导致后端多次执行，因此最好仅对可以多次执行不会有不利影响的请求开启此策略。有如下参数： maxAttempts 必填 hedgingDelay 可选 nonFatalStatusCodes 可选 一个请求在没有收到成功响应时，经过 hedgingDelay 没收到响应 将继续发送请求，直至达到 maxAttempts 最大次数或请求成功。当收到成功响应时，所有未完成的其它请求将停止。本质上 hedging 策略可以看作在收到失败响应前重试请求。 使用 接下来讲解如何在 gRPC go 语言版本中配置使用重试功能。 服务端 服务端创建一个服务，只有当请求次数达到第三次时，才返回成功响应。 package main import ( "context" "flag" "fmt" "log" "net" "sync" "google.golang.org/grpc" "google.golang.org/grpc/codes" "google.golang.org/grpc/status" pb "github.com/overstarry/grpc-example/proto/echo" ) var port = flag.Int("port", 9000, "port number") type failingServer struct { pb.UnimplementedEchoServer mu sync.Mutex reqCounter uint reqModulo uint } func (s *failingServer) maybeFailRequest() error { s.mu.Lock() defer s.mu.Unlock() s.reqCounter++ if (s.reqModulo > 0) && (s.reqCounter%s.reqModulo == 0) { return nil } return status.Errorf(codes.Unavailable, "maybeFailRequest: failing it") } func (s *failingServer) UnaryEcho(ctx context.Context, req *pb.EchoRequest) (*pb.EchoResponse, error) { if err := s.maybeFailRequest(); err != nil { log.Println("request failed count:", s.reqCounter) return nil, err } log.Println("request succeeded count:", s.reqCounter) return &pb.EchoResponse{Message: req.Message}, nil } func main() { flag.Parse() address := fmt.Sprintf(":%v", *port) lis, err := net.Listen("tcp", address) if err != nil { log.Fatalf("failed to listen: %v", err) } fmt.Println("listen on address", address) s := grpc.NewServer() failingservice := &failingServer{ reqCounter: 0, reqModulo: 3, } pb.RegisterEchoServer(s, failingservice) if err := s.Serve(lis); err != nil { log.Fatalf("failed to serve: %v", err) } } 客户端 客户端通过 WithDefaultServiceConfig 设置配置好重试功能 ...

问题 最近收到了阿里云云数据库的报警信息，提示数据库连接数过高，通过监控可以看到，数据库的连接数升高了 50%,其它指标保持正常。 分析及解决 通过阿里云后台的一键诊断中的会话管理可以看到占用大量连接的 ip 地址，可以看到 100.104.205.90、100.104.205.83 和 100.104.205.6 这三个 ip 占用了大量连接，可以看到并没有 sql 请求，只是单纯的保持数据库连接，通过查看阿里云文档和询问客服，可以得知这个 ip 地址是阿里云 dms 服务的地址，。 找到原因后就好解决了，可以使用SELECT pg_terminate_backend(pid)语句释放数据库连接，使用语句释放与这三个 ip 相关的数据库连接:select pg_terminate_backend(pid) from pg_stat_activity where client_addr in ('100.104.205.90','100.104.205.83') ,过了一会数据库连接恢复正常了。 小结 本文通过阿里云数据库连接过高的问题，分析遇到此类问题时如何排查并解决。 参考 https://help.aliyun.com/zh/dms/configure-an-ip-address-whitelist

前言 Kubernetes 的 pod 可以按照节点的资源进行调度，默认情况下 pod 能够使用节点的全部资源，这样往往会出现因为节点自身运行的一些驱动及 Kubernetes 系统守护进程，导致资源不足的问题。 例如有一个应用在运行中使用了大量的系统资源，导致 kubelet 和 apiserver 的心跳出现故障，导致节点处于 Not Ready 的状态，节点出现 Not Ready 的状况后，过一会儿会将 pod 调度到其它 node 节点上运行，往往会导致节点雪崩，一个接一个的出现 Not Ready 状况。 那么如何解决这个问题呢？这时可以通过 为 Kubernetes 集群配置资源预留，kubelet 暴露了一个名为 Node Allocatable 的特性，有助于为系统守护进程预留计算资源，Kubernetes 也是推荐集群管理员按照每个节点上的工作负载来配置 Node Allocatable。 Node Allocatable Kubernetes 节点上的 Allocatable 被定义为 Pod 可用计算资源量。调度器不会超额申请 Allocatable。目前支持 CPU、内存 和 存储 这几个参数。可以通过 kubectl describe node 命令查看节点可分配资源的数据： 可以看到有 Capacity 和 Allocatable 两个内容，Allocatable 这个就是节点可分配资源，由于没有设置，所以默认 Capacity 和 Allocatable 是一致的。 Capacity 是节点所有的系统资源，kube-reserved 是给 kube 组件预留的资源，system-reserved 是给系统进程预留的资源，eviction-hard 是 Kubelet 的驱逐阈值。 ...

前言 最近出现了服务器 cpu、内存升高导致服务器宕机的问题，发生宕机后，往往由于对系统资源数据收集的不齐全，导致无法快速查明发生宕机的原因。在通过云厂商客服和网络相关资料帮助下，了解了 atop 这个工具，本机对 atop 的安装及使用进行介绍。 atop 介绍 atop 是一款用于监控 Linux 系统资源与进程的工具，能够报告所有进程的活动。其以一定的频率记录系统和进程活动，采集的数据包含 CPU、内存、磁盘、网络的资源使用情况和进程运行情况，并能以日志文件的方式保存在磁盘中。对于每个进程，会显示 CPU 使用率、内存增长、磁盘使用率、优先级、用户名、状态和退出码等。当服务器出现问题后，可以根据相应的 atop 日志文件进行分析。 安装 atop 不是系统的内部自带命令，需要进行安装，接下来以 Ubuntu 系统为例子，介绍如何安装 atop 命令。 1 更新软件源 执行 sudo apt update 进行软件源的更新。 2 安装 atop 执行 sudo apt install atop 命令安装 atop。 配置 安装完 atop 后，可以使用 atop 的默认配置使用，也可根据使用情况修改默认配置，atop 默认配置在 /etc/sysconfig/atop,查看默认配置文件内容： # /etc/default/atop # see man atoprc for more possibilities to configure atop execution LOGOPTS="-R" LOGINTERVAL=600 LOGGENERATIONS=28 LOGPATH=/var/log/atop LOGINTERVAL 是监控周期，默认 600s，LOGGENERATIONS 是日志文件保留周期，默认是 28 天，可以根据具体的需求进行修改。 ...

前言 我们知道 kubernetes 内部服务之间是通过 service 进行相互访问的，那么如果现在有一个非 kubernetes 部署的服务，我们可以也通过 service 进行内部交互使用吗？答案是可以，我们可以使用 service 的 ExternalName 类型将 service 映射到外部服务上。 最近需要将一个外部服务映射到 kubernetes service 上，通过查找资料学习，本文记录如何将 kubernetes service 映射到外部服务的流程步骤。 外部域名映射内部 service 先讲解如何将外部服务通过域名的方式映射到内部 service 上，通过配置 externalName 字段来配置映射关系。例如，以下 Service 定义将 test 命名空间中的 my-service 服务映射到 my.overstarry.vip: apiVersion: v1 kind: Service metadata: name: my-service namespace: test spec: type: ExternalName externalName: my.overstarry.vip 虽然 externalName 也支持填写 ip 地址，但不会被 kubernetes 解析，如果需要使用 ip 地址，可以使用无头服务 Headless，下文会进行介绍。 外部服务 ip 映射 service 接下来介绍没有域名的外部服务和 service 如何进行映射。上文讲过虽然 externalName 也支持填写 ip 地址，但不会被 kubernetes 解析，如果需要，则应该使用 Headless Service 进行映射。 ...

前言 cdn 刷新是 cdn 使用过程中的一项重要的功能，通过刷新功能，您可以删除 CDN 节点上已经缓存的资源，并强制 CDN 节点回源站获取最新资源，适用于源站资源更新和发布、违规资源清理、域名配置变更等。 接下来将分别讲述 阿里云 CDN、AWS cloudfront、Cloudflare cdn 使用 go 语言进行 cdn 的刷新操作的。 阿里云刷新 cdn 如何刷新 阿里云 cdn 的缓存呢？只需使用 阿里云 openapi 的 go sdk 即可，通过查阅文档，我们只需使用 RefreshObjectCaches API 即可刷新阿里云 cdn 的缓存，RefreshObjectCaches 有以下参数： ObjectPath: 刷新的url ,多个 url 使用换行符进行分隔 ObjectType: 刷新任务的类型，有以下类型 File（默认值）：文件刷新。 Directory：目录刷新。 Regex：正则刷新。 IgnoreParams：去参数刷新。去参数指的是去除请求 URL 中?及?之后的参数，去参数刷新指的是用户先通过接口提交去参数后的 URL，然后用户提交的待刷新 URL 将会与已缓存资源的 URL 进行去参数匹配，如果已缓存资源的 URL 去参数以后与待刷新 URL 匹配，那么 CDN 节点将对缓存资源执行刷新处理。 Force: 当回源内容和源站资源对比后不一致时，是否刷新对应目录下的资源。默认为 false。 下面是一个例子： package main import ( cdn20180510 "github.com/alibabacloud-go/cdn-20180510/v4/client" openapi "github.com/alibabacloud-go/darabonba-openapi/v2/client" util "github.com/alibabacloud-go/tea-utils/v2/service" "github.com/alibabacloud-go/tea/tea" "os" ) func CreateClient(accessKeyId *string, accessKeySecret *string) (result *cdn20180510.Client, err error) { config := &openapi.Config{ AccessKeyId: accessKeyId, AccessKeySecret: accessKeySecret, } config.Endpoint = tea.String("cdn.ap-southeast-1.aliyuncs.com") result = &cdn20180510.Client{} result, err = cdn20180510.NewClient(config) return result, err } func main() { client, err := CreateClient(tea.String(os.Getenv("ALIBABA_CLOUD_ACCESS_KEY_ID")), tea.String(os.Getenv("ALIBABA_CLOUD_ACCESS_KEY_SECRET"))) if err != nil { return } refreshObjectCachesRequest := &cdn20180510.RefreshObjectCachesRequest{ ObjectPath: tea.String("http://example.com/image/1.png\\\n\t\thttp://aliyundoc.com/image/2.png"), } runtime := &util.RuntimeOptions{} _, err = client.RefreshObjectCachesWithOptions(refreshObjectCachesRequest, runtime) if err != nil { return } return } aws cloudfront 接下来讲解 aws cloudfront 如何刷新 cdn，cloudfront 刷新缓存的操作叫使文件失效，通过查阅 cloudfront 的 API 文档，发现可以使用 CreateInvalidation 来创建失效。可以使用 aws go sdk 来进行操作。 ...

最近使用 Apisix 网关时，需要开启 gzip 功能，通过查阅资料学习，了解了几种开启 gzip 的方式，本文记录 2 种 Apisix 开启 gzip 的方式。 gzip 插件 我们可以使用 gzip 插件 针对某些路由开启 gzip，只需对路由使用 gzip 插件并配置一些插件属性即可。 接下来使用一个例子来演示 gzip 插件，使用 apisix admin api 创建一条路由，要注意的是本文的例子是使用 apisix 3.7 版本： curl -i http://127.0.0.1:9180/apisix/admin/routes \ -H 'X-API-KEY: edd1c9f034335f136f87ad84b625c8f1' -X POST -d ' { "uri": "/get", "plugins": { "gzip": { "buffers": { "number": 8 }, "comp_level": 6, "disable": false, "types": "*" } }, "upstream": { "nodes": [ { "host": "httpbin.org", "port": 443, "weight": 1 } ], "timeout": { "connect": 6, "send": 6, "read": 6 }, "type": "roundrobin", "scheme": "https", "pass_host": "pass", "keepalive_pool": { "idle_timeout": 60, "requests": 1000, "size": 320 } }, "status": 1 }' ...

前言 最近出现了多次因为各种原因导致的操作系统宕机的问题，为了查找系统宕机的原因，需要收集系统宕机后的内存转储信息。本文就介绍几种常见的方式。 阿里云内置命令收集 由于主要使用的是阿里云的服务器，就先介绍阿里云收集系统宕机内存转储信息的方式。 阿里云系统默认没有开启 dump 配置，我们需要使用以下命令开启：acs-plugin-manager --exec --plugin=ecs_dump_collector --params="--enable" 那我们如何收集内存转储信息呢，执行以下命令：acs-plugin-manager --exec --plugin=ecs_dump_collector --params="-c" 出现以下信息表示收集成功。 有了转储信息文件我们就可以将文件交给专业的运维人员或阿里云工程师进行宕机原因分析。 使用 Crash + Kdump 如果我们没有使用阿里云的服务该如何收集系统崩溃的转储信息呢，我们可以使用 Crash + Kdump 进行收集，通过前面的使用可以看出阿里云的插件就是使用了这两个工具，接下来开始进行简单的介绍。 安装 需要先安装 Crash + Kdump，使用此命令进行安装： $ sudo apt install linux-crashdump $ sudo apt install crash 安装完为了使服务生效需要重启服务器。 使用以下命令：sudo cat /etc/default/grub.d/kdump-tools.cfg 可以看出系统保留了 192M RAM 内存区供转储捕获内核使用 收集 为了测试方便我们可以使用此命令快速触发崩溃：sudo echo c > /proc/sysrq-trigger 。命令执行后在 /var/crash 目录会生成以当前时间为名称的目录，目录里面就是收集到的转储信息。 demsg.x 为崩溃时候的系统内核日志，dump.x 文件则为转储的内核快照文件。为了更好的查找问题，我们还需要安装 vmlinux，使用以下命令安装： ...

前言 本文介绍一个 go 汉字转拼音的库 go-pinyin，可以从名字看出这个库的功能就是将汉字转换为相应的拼音。接下来就由我来简单的介绍 go-pinyin。 安装 使用此命令安装：go get github.com/mozillazg/go-pinyin cli 安装 如果你的 go 版本在 1.17 以下使用此命令安装：go get -u github.com/mozillazg/go-pinyin/cli/pinyin。1.17 及以上版本使用此命令安装：go install github.com/mozillazg/go-pinyin/cli/pinyin@latest。 使用 接下来将分别介绍 cli 的使用和 API 的使用。 cli 使用 安装完在终端输入 pinyin，可以看到使用的方法，尝试一个汉字，可以看到相应的拼音，但也可以看出对多音字的支持有问题。 $ pinyin 中国 zhōng guó $ pinyin 重庆 zhòng qìng 接下来介绍 API 的使用。 api 使用 通过查看文档，可以看出主要是 2 个方法 pinyin.NewArgs 和 pinyin.Pinyin 。 pinyin.NewArgs 创建包含默认配置的 Args, 可以通过修改 Args 的成员来使用不同的模式。 type Args struct { Style int // 拼音风格（默认：Normal) Heteronym bool // 是否启用多音字模式（默认：禁用） Separator string // Slug 中使用的分隔符（默认：-) // 处理没有拼音的字符（默认忽略没有拼音的字符） // 函数返回的 slice 的长度为 0 则表示忽略这个字符 Fallback func(r rune, a Args) []string } pinyin.Pinyin 就是将汉字转为拼音。 ...