微服务框架 go-micro 使用 Kafka 作为发布订阅的 Broker go-micro 默认使用http服务作为服务中的Broker 服务默认启动的时候 使用kafka启动 http服务作为服务中的Broker，有三个明显的缺点： 不能持久化存储 不能对未消费的数据，进行消费 每个需要发送消息的微服务都会启动一个 http Broker服务，可能会影响服务器性能 bro

服务器时间导致服务崩溃 测试反馈最近版本发布完,内网演示环境服务测试的时候,服务卡顿明细,让我找找问题 爬到服务器上一看,数据库负载到了20多 top + iostat 一看, 好家伙, 磁盘IO拉满了 假装分析一波发现 mongodump 这个进程在 top 中排第一位, 原来是在备份数据啊,忙问了一下领导, 回复说没有进行数据备份 仔细想了一下 crontab 里面有定时数据库备份的任务,凌晨

Kafka特点： 1 解耦合 消息队列提供了借口, 生产者和消费者能够独立的完成读操作和写操作。 2 高吞吐率。即使是在廉价的商用机器上也能做到单机支持每秒100K条消息的传输 3 信息传输快。以时间复杂度为O（1）的方式提供持久化能力, 即使对TB级以上数据也能保证常数时间的访问性能 4 可提供持久化。消息存储在中间件上, 数据持久化, 直到全部被处理完, 通过这一方式规避了数据丢失的风险

公司内网环境自建的 MinIO 作为对象存储,而外网的对象存储则是使用的阿里云服务 MinIO和阿里云 都兼容亚马逊(AWS) 的S3协议, 为此使用 AWS-SDK 上传服务生成的数据内容 docker 创建一个 MinIO 的容器 MINIO_ROOT_USER 和 MINIO_ROOT_PASSWORD 就是 9001 端口的登录的账号密码, 也是AK和SK(也可以进入后台自己更换) 12d

etcd 超出空间导致服务注册不成功 keyword：mvcc: database space exceeded go-micro 使用etcd作为注册中心, 公司当前处于的是业务开发状态, 发布订阅功能也是直接基于go-micro 使用etcd来做消息转存的,导致消息发布有大量消息没有及时处理, 堆积下来, 然后新服务不能写入注册信息到etcd中 上网搜索了一下,官方文档已经写的很清楚了 ht

在golang中使用 NACOS 管理项目的配置文件 安装Nacos nacos go 1go get github.com/nacos-group/nacos-sdk-go/[email protected] 12345678910111213141516171819202122232425262728293031323334353637383940414243444546474849505152535

kubeadm 安装 K8s 关闭防火墙： 1234systemctl stop firewalldsystemctl disable firewall 关闭 selinux： 12sed -i 's/enforcing/disabled/' /etc/selinux/config # 永久setenforce 0 # 临时 关闭 swap： 12swapoff -a # 临时

1234567891011121314151617181920212223242526272829303132333435363738394041424344454647484950515253545556575859606162636465666768697071727374757677# yaml格式的pod定义文件完整内容：apiVersion: v1 #必选, 版本号, 例如v

微服务框架 go-micro 代理 proxy 接受消息值最大修改 keyword: MaxCallRecvMsgSize go-micro 框架自带了 proxy 用来代理微服务之间的rpc请求,因为框架内部封装好了 client(本质是服务对服务直接请求) 可以在golang端轻松修改 clientGrpc.MaxRecvMsgSize,clientGrpc.MaxSendMsgSize

错误的初始化 Slice, 痛痛痛 先上代码 1234567891011121314151617181920212223242526package mainimport "fmt"func main() { s := []string{"A", "B", "C"} ns1 := newSl