上面 #3 #5 给了方案，我瞄了一眼 cog：
cog 不得行的原因是 就是 dockerd 代理限制。

cog 做的不好的一点是，他不提供额外的 docker --build-arg 参数让用户配置！

如果提供配置，你就不需要修改 dockerd 了，这样就会更灵活

```go
func Build(dir, dockerfile, imageName string, progressOutput string) error {
var args []string
if util.IsM1Mac(runtime.GOOS, runtime.GOARCH) {
args = m1BuildxBuildArgs()
} else {
args = buildKitBuildArgs()
}
args = append(args,
"--file", "-",
"--build-arg", "BUILDKIT_INLINE_CACHE=1",
"--tag", imageName,
"--progress", progressOutput,
".",
)
cmd := exec.Command("docker", args...)
cmd.Env = append(os.Environ(), "DOCKER_BUILDKIT=1")
cmd.Dir = dir
cmd.Stdout = os.Stderr // redirect stdout to stderr - build output is all messaging
cmd.Stderr = os.Stderr
cmd.Stdin = strings.NewReader(dockerfile)

console.Debug("$ " + strings.Join(cmd.Args, " "))
return cmd.Run()
}
```

瓶颈 Mysql 写入，核心解决思路，控制 Mysql 写入更新量。

如果可以容忍最新进度的丢失的容忍性，和粒度放大问题。最低成本的解决方案：
本地记录最新的时间。拉长上报 最新进度上报时间间隔比如 3 分钟？ TPS 约 600 了。
退出立即记录退出时间。
客户：异常退出再进来利用本地记录恢复。本地没有取远端最新，导致进度可能不准，但是异常退出量少
正常退出再进来，利用远端退出时间记录。准确进度

1.这样改动最少 2 不引入其他额外组件，最低成本
缺点：统计的粒度不够细。

@hopingtop
https://github.com/uber-go/automaxprocs

这库的原理就是取读取 容器里 /sys/fs/cgroup/cpu 里面的值，然后计算出一个合理的 MAXPROCS
在你 main 函数执行之前通过 import 这个过程去初始化 MAXPROCS

针对 Docker 运行 Go 确实有取宿主机的 CPU 来设置 MAXPROCS.
当使用 Pod 限制资源的配置时，就不建议手动去调整 MAXPROCS ， 这样做不好运维，所以可以选择 Uber 的一个库

我也很好奇一个问题，好大的人员规模才适合中台？因为之前一直没接触过。
我在重庆这个互联网荒漠的地方，也听到一些人到处都吹中台中台！
结果一落地，稀烂！

我个人感觉架构更多的是基于自己团队的演进，而不是一开始就各种高大上的名词整起，服务上起。

对于 50 人内的研发团队来说，大概率是徒增开支，加剧内耗。
可能最终就是丰富了，带头人的简历： 执行 XXX 战略，引进 XXX 先进技术。 失败原因就是公司不行！

看官就当看个乐吧。

首先要考虑你场景的一致性容忍度，如果一点就不能容忍，那么你就不应该用 redis 来做。应该选强一致性方案，也就是说的 etcd 或者 zk 。

redis 是做不了强一致性的，包括 多 client 端连接多 master (n/2)+1 这种方案，还有就是 redis wait 命令，都只能是减少锁失效的概率。

如果有容忍性，又是选举场景这种并发不大的情况，只需要找一块共享存储原子操作就行。member 去 loop 尝试加锁，leader 去续约就好。

如果 Leader 后续操作有数据库的话，这样 redis 这个依赖就能不要，减少一个自己不太熟悉的东西，提升稳定性。

不建议用 Pub 消息去通知。订阅可能存在失效等问题，而且这样实现就深度绑定了一些特性，以后不好做迁移。

xorm.io/xorm 我印象中，是没有 空返回 error ，exists, error := .Get(&struct{}) 不存在 exists 是 false

@aaaaaaaaa 因为是自有协议，目前不支持 公共第三方导入。
/api 有协议编码文件，不过没有详细的文档

@BigTaoTao 一般操作是，起一个 nginx 通过 acme.sh 去配置，然后通过 nginx 代理你的 nextcloud 。内部 http 访问应该不影响。没具体看 nextcloud 但是看它上面的 docker 报错，应该内部有 Apache 服务，acme.sh 也支持

看看 Dockerfile 是否有通过 环境变量 配置这个 ServerName

@sbex 嗯，你的问题很好！这里我们可以看到，当前系统，不支持 全文搜索，不支持跳条件查询，这都是考虑到 索引大小和查询速度， 而牺牲更大的灵活性。traceId 这种查询就不说了，他是走的单索引。
我们觉得 靠谱的日志打印，一定不是大海捞针 才找到。 一般来说通过 3 个 查询维度，就能缩小到很小的范围。所以我们只建立了一个联合索引，并且查询条件设置顺序 严格表现为 前缀形式， 比如：填了 等级筛选，才能填入短消息筛选，填入一级条件，才能使用二级条件...

我们举一个应用场景：一个进程每天的写入量在 5000W 日志，那么我们设置 此进程 3 天分一片， 那么此模块下，单集合容量差不多在 1.5 亿的情况。这个时候如果时间范围控制的比较好，查询返回是在 毫秒 级别的。因为缓存问题，相似查询条件，第二次查询会更快。
当然这里就会产生一个限制，就是单次最大查询时间范围只有 3 天，我们不支持自动跨集合查询。因为产生了跨集合查询，可能会导致资源占用不可控。

因为我们自定义了 collection 隔离，所以需要大量 IO 查询的情况下，对其他的进程写入和查询也是不受影响的。

我们知道 Count 是很耗时的，所以在查询的时候我们 优化了查询方式，异步最大 Count 5W 条 | MaxTimeout 3s 。 所这里存在的问题就是，日志条件筛选后还大于 5W 条 Count 就是不准的了。


如果写入量还很大，比如一天达到了 3-5 亿，因为我们的最小粒度是天分片。所以 2c4g 的 mongo 对单表 5 亿的筛选是很有压力的。不过还是特别恭喜你！你可以有更多的钱 去升级更好的系统了。 或者升级此系统的 Mongo 也可以！

@gerorim 嗯，前端这块不是我的强项，是要优化一下，后面空了，我来弄 详细的 error code 来处理，这块的提醒。目前只有验证类型的错误会直接返回给前端，偷了个懒，哈哈。

@gerorim qezap.New(qezap.WithLevel(YourLevel)) 默认 DEBUG 。 在初始化指定一下就行。 指定 info, 就是 info 及以上。其他日志级别同理

@hopingtop 日志趋势写入量，管理后台已经统计好，可以直接查看，然后灵活调整。
正式因为部署方式特殊，所以才出现这个日志系统。 假想一下，部署 5 套 ELK... 这成本不敢想象。如果要求不高， 这套东西。1c2g 的机器也可以稳稳的跑，畅快的写。

@Maboroshii 嗯，是直接入 DB 的。性能瓶颈，就是 Mongodb 的瓶颈。因为建立索引极其克制，所以批量写入性能很好，
项目 /tools 目录里面有 benchmark 工具，可以依据自己的环境来测试。2c4g 的 mongodb 空集合的情况下 7-8w/s 单条 /350bytes 还是可以的。

针对如果单进程有异常大的日志量，是建议 Bind 一个性能好点的 DB 实例上，进行纵向扩展性能，同时分片时间短一点，比如 7 天一个集合。这样能保证单集合不会过大，导致此进程写入日志性能下降。但是因为 Remote 写入实现是异步的，不会阻塞主进程。短时的峰值流量扛不住或者集群异常，会把日志写入备份本地文件，然后有异步逻辑补偿写入，直到备份文件内容追平。

不同的模块（理解成 APP 进程）可以绑定不同的 mongodb 实例里面，这样写入是分散的。但是做不到自动冷热分布，如果初期无法预估容量，可以通过统计趋势写入量的，然后通过后台手动绑定进程写入到哪个实例，来分布数据的冷热问题，达到均衡使用。

目前，我们部署方式很特殊，我们有很多独立的项目群。 目前网络不互通的 部署了 5 套， 目前最大的集群，日写入量在压缩后有 35G 左右。平均 4000W 条吧，2c4G 的 Mongodb 就可以满足。

@xuzhzzz 哈哈，其实就是有两次团队小伙伴，在写定时任务的时候，有个异常逻辑 select 里面 break 了，并不是退出 for 循环，这个在 Go 语言的 Bug 里面也比较常见。 结果 for 循环了好几个小时，2c4g 的 mongo 写了 8 亿多条数据。最后 mongo 使用内存报警了接近打满了，然后通过后台直接删除异常的 mongo 集合，重启 mongodb 恢复。

@xdeng 哈哈，想法不错，可以考虑考虑，不过连 docker 拉一个 mongo 就觉得麻烦了嘛 555