使用 Coze 打造专属 AI Bot

前言 Coze 是新一代一站式 AI Bot 开发平台。无论你是否有编程基础,都可以在 Coze 平台上快速搭建基于 AI 模型的各类问答 Bot,从解决简单的问答到处理复杂逻辑的对话。并且,你可以将搭建的 Bot 发布到各类社交平台和通讯软件上,与这些平台/软件上的用户互动。 Coze 具有以下功能及优势: Coze 提供了丰富的插件集合,可以扩展你的 Bot 的能力。用户也可进行插件的自定义,将现有的 API 能力通过配置的方式让 Bot 进行调用。 提供了知识库功能来管理和存储数据,可以让 Bot 使用知识库的内容进行回答。 长期记忆能力,Coze 提供了用于长期记忆的数据库功能,Bot 可以持久化的记住用户输入的参数和内容。 定时任务支持,Coze 支持为 Bot 创建定时任务,无需编写任何代码,只需输入任务描述,Bot 会暗示执行任务。 工作流,Coze 支持通过可视化的方式来创建工作流。 多 Agent 支持 Coze 有国内版 (www.coze.cn) 和国际版[www.coze.com],本篇文章使用国际版进行介绍如何创建一个 Bot。 创建 Bot 注册完 Coze 账号,先创建 Bot,点击 Create Bot 输入 Bot 名称,这里由于想搭建一个 blog 助手,于是输入 Blog Assistant,然后上次 Bot 图像,如果没有合适的图像,也可以使用 DALL·E-3 生成头像。 设置 创建完 Bot 后,就进入 Bot 的设置页面。 ...

六月 1, 2024 · 2 分钟 · overstarry

golang 生成 slug 字符串

slug 介绍 slug 在不同的场景有不同的意义,在 URL 中表示一种用于描述资源的短简洁易于理解的资源描述符,在数据库系统中还可以用于描述资源的唯一标识符,总的来说 slug 可以用来标识和描述资源的文本标识符,有很好的可读性和唯一性。 本文将介绍 golang 中如何根据字符串生成相应的 slug 文本。 安装 执行 go get -u github.com/gosimple/slug 来安装 slug 使用 先介绍 slug 库的基础使用方法: package main import ( "fmt" "github.com/gosimple/slug" ) func main() { text := slug.Make("overstarry home") fmt.Println(text) text = slug.Make("text generate") fmt.Println(text) } 运行后: overstarry-home text-generate 除了基础的转换功能,slug 还支持将不同的语言进行转换,查看下面的例子: func main() { text := slug.Make("overstarry home") fmt.Println(text) text = slug.Make("text generate") fmt.Println(text) text = slug.Make("Hellö Wörld хелло ворлд") fmt.Println(text) someText := slug.Make("影師") fmt.Println(someText) enText := slug.MakeLang("This & that", "en") fmt.Println(enText) } overstarry-home text-generate hello-world-khello-vorld ping-guo this-and-that 如果想要保留大写字母,可以设置 slug.Lowercase 参数来实现。如果想实现自定义的替换可以使用 slug.CustomSub 来实现。 ...

五月 25, 2024 · 1 分钟 · overstarry

metabase 介绍及简单使用

前言 前面的文章介绍过一个开源的大数据可视化工具 - Apache Superset,本文将介绍作者最近了解到的另一个可视化工具 Metabase。 Metabase 介绍 Metabase 是一个简单易用的开源项目,旨在为公司中的每个人提供商业智能和分析的最简单、最快捷的方法。Metabase 具有以下核心优势和主要功能: 短时间内完成设置。 团队成员不需要 SQL 知识基础。 提供 SQL 编辑器来进行更复杂的查询。 构建漂亮、交互式的仪表盘,包括过滤器、自动刷新、全屏显示和自定义点击行为等功能。 定义规范的细分和指标供团队使用 使用仪表板订阅按计划将数据发送到 Slack 或发送电子邮件。 设置警报,让数据更改时通知您。 在应用程序中嵌入图表及仪表盘。 配置了细粒度的数据权限功能,方便进行数据安全控制。 安装 接下来介绍如何安装 Metabase,我们将使用 docker 部署的方式进行安装。 docker-compose.yaml 内容如下: version: '3.9' services: metabase: image: metabase/metabase:latest container_name: metabase hostname: metabase volumes: - /dev/urandom:/dev/random:ro ports: - 3000:3000 environment: MB_DB_TYPE: postgres MB_DB_DBNAME: metabaseappdb MB_DB_PORT: 5432 MB_DB_USER: metabase MB_DB_PASS: mysecretpassword MB_DB_HOST: postgres networks: - metanet1 healthcheck: test: curl --fail -I http://localhost:3000/api/health || exit 1 interval: 15s timeout: 5s retries: 5 postgres: image: postgres:latest container_name: postgres hostname: postgres environment: POSTGRES_USER: metabase POSTGRES_DB: metabaseappdb POSTGRES_PASSWORD: mysecretpassword networks: - metanet1 networks: metanet1: driver: bridge 执行 docker compose up -d 即可启动服务。接下来访问 http://127.0.0.1:3000/ 进行安装,设置完语言密码默认数据库,安装即算完成。 ...

五月 17, 2024 · 1 分钟 · overstarry

Go 生成 Google analytics 衡量 ID

Google Analytics 介绍 Google Analytics(分析)4 是一项分析服务,用于衡量您的网站和应用中的流量和互动情况。本文将介绍如何通过调用 Google Analytics admin API 来生成 Google Analytics 衡量 ID. 配置 启用 API 在 Google Cloud console 后台 API 和服务 启用 Google Analytics Admin API。 配置服务账号 为了调用 API,我们需要创建一个服务账号,然后为创建的服务账号添加密钥。 需要注意的是还需要在 Google Analytics 为服务账号添加权限,不然请求接口会没数据。 安装 go 客户端 接下来安装 go 客户端: go get google.golang.org/api/analyticsadmin/v1alpha 生成流程 接下来我们会按照常规的 id 生成流程编写相应的代码,流程: 1 获取账号信息 通过 List 接口获取当前服务账号所拥有的所有 Google Analytics 账户信息。 accountsService := analyticsadmin.NewAccountsService(service) accountsReply, err := accountsService.List().Do(); if err != nil { log.Fatal("list account err",err) return } for _,acc := range accountsReply.Accounts { fmt.Println(acc.Name) } 2 创建媒体资源 ...

四月 18, 2024 · 1 分钟 · overstarry

docker init 命令

前言 Docker 是一个广受欢迎的开发平台,它允许用户通过容器化技术来构建、打包和部署应用程序。尽管 Docker 提供了强大的功能和灵活性,但对于初学者而言,在项目中配置 Docker 可能会遇到一些挑战。 不过,Docker 官方为了降低使用门槛,推出了一个便捷的命令docker init。这个命令旨在快速初始化 Docker 配置,从而简化将 Docker 集成到项目中的流程。通过使用这个命令,用户可以轻松地为项目设置必要的 Docker 支持,进而享受到 Docker 带来的便利和效率提升。 docker init 简介 docker init 命令会根据用户指定的选项生成运行容器的一些文件,极大的加快了项目的容器化: .dockerignore : docker 构建时忽略的文件列表 Dockerfile: 镜像的核心文件 Compose.yaml: docker compose 的配置文件 README.Docker.md 如果你的项目中已有以上文件,会让你选择是否覆盖旧文件避免文件冲突问题。 docker init 提供了一组项目的模板文件,包括了 Go、Python、ASP.NET Core 等常见的服务器应用程序及一个其它类型应用程序模板。开发者使用 init 命令时,可以根据选择的模板生成相应的文件,使开发者可以快速的构建并启动容器。 使用 接下来介绍如何使用 docker init 进行项目容器的初始化,这里以前文的 go 项目为例子进行介绍。 进入项目根目录执行 init 命令,选择 go 模板,会让你选择使用的 go 版本,主程序的位置及应用所使用的端口: 执行完可以看到会生成相应的文件及如何构建并运行的命令。 查看生成的 Dockerfile 和 Compose.yaml 文件: # syntax=docker/dockerfile:1 # Comments are provided throughout this file to help you get started. # If you need more help, visit the Dockerfile reference guide at # https://docs.docker.com/go/dockerfile-reference/ # Want to help us make this template better? Share your feedback here: https://forms.gle/ybq9Krt8jtBL3iCk7 ################################################################################ # Create a stage for building the application. ARG GO_VERSION=1.21.0 FROM --platform=$BUILDPLATFORM golang:${GO_VERSION} AS build WORKDIR /src # Download dependencies as a separate step to take advantage of Docker's caching. # Leverage a cache mount to /go/pkg/mod/ to speed up subsequent builds. # Leverage bind mounts to go.sum and go.mod to avoid having to copy them into # the container. RUN --mount=type=cache,target=/go/pkg/mod/ \ --mount=type=bind,source=go.sum,target=go.sum \ --mount=type=bind,source=go.mod,target=go.mod \ go mod download -x # This is the architecture you’re building for, which is passed in by the builder. # Placing it here allows the previous steps to be cached across architectures. ARG TARGETARCH # Build the application. # Leverage a cache mount to /go/pkg/mod/ to speed up subsequent builds. # Leverage a bind mount to the current directory to avoid having to copy the # source code into the container. RUN --mount=type=cache,target=/go/pkg/mod/ \ --mount=type=bind,target=. \ CGO_ENABLED=0 GOARCH=$TARGETARCH go build -o /bin/server ./retry/server ################################################################################ # Create a new stage for running the application that contains the minimal # runtime dependencies for the application. This often uses a different base # image from the build stage where the necessary files are copied from the build # stage. # # The example below uses the alpine image as the foundation for running the app. # By specifying the "latest" tag, it will also use whatever happens to be the # most recent version of that image when you build your Dockerfile. If # reproducability is important, consider using a versioned tag # (e.g., alpine:3.17.2) or SHA (e.g., alpine@sha256:c41ab5c992deb4fe7e5da09f67a8804a46bd0592bfdf0b1847dde0e0889d2bff). FROM alpine:latest AS final # Install any runtime dependencies that are needed to run your application. # Leverage a cache mount to /var/cache/apk/ to speed up subsequent builds. RUN --mount=type=cache,target=/var/cache/apk \ apk --update add \ ca-certificates \ tzdata \ && \ update-ca-certificates # Create a non-privileged user that the app will run under. # See https://docs.docker.com/go/dockerfile-user-best-practices/ ARG UID=10001 RUN adduser \ --disabled-password \ --gecos "" \ --home "/nonexistent" \ --shell "/sbin/nologin" \ --no-create-home \ --uid "${UID}" \ appuser USER appuser # Copy the executable from the "build" stage. COPY --from=build /bin/server /bin/ # Expose the port that the application listens on. EXPOSE 9000 # What the container should run when it is started. ENTRYPOINT [ "/bin/server" ] 可以看到 Dockerfile 是一个常见的多阶段构建镜像流程。 ...

四月 13, 2024 · 4 分钟 · overstarry

gRPC 客户端负载均衡

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() } 接下来创建对应的客户端连接: ...

三月 30, 2024 · 3 分钟 · overstarry

gRPC 请求重试

前面的文章介绍了 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 设置配置好重试功能 ...

三月 23, 2024 · 3 分钟 · overstarry

阿里云 dms 占用数据库连接问题及解决

问题 最近收到了阿里云云数据库的报警信息,提示数据库连接数过高,通过监控可以看到,数据库的连接数升高了 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

三月 16, 2024 · 1 分钟 · overstarry

Kubernetes 系统资源预留

前言 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 的驱逐阈值。 ...

三月 9, 2024 · 2 分钟 · overstarry

atop 工具介绍及使用

前言 最近出现了服务器 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 天,可以根据具体的需求进行修改。 ...

三月 2, 2024 · 1 分钟 · overstarry