前言: 通常对于初创企业或者初创业务团队来说，对于开源组件的使用都会显的比较随意，而这种情况会随着业务量级的增长或时间的推移导致开源服务的滥用，进而造成的结果就是服务整体的稳定性和可靠性相对较差，且是边际效应递减的，如果此时不对整体业务以及开源服务进行规划和改造，那么风险和成本将是同比增长的。在我过去的工作经历中，经历过类似服务的有Redis集群，ElasticSearch集群，虽然整体改造后并不一定将成本降到最低，但是可以将服务的可用性和可靠性提高很多，而且根据业务场景以及使用方式来规划集群后会使得整体的边际成本呈递减状态。

笔者目前所处的团队所管理的kafka集群也处于该种状态，集群当前规模大约为20+ECS，总数据量大约400T，其中承接的Topic服务主要分为日志收集、数据管道、流式计算、业务事件存储几种大场景，我们需要知道，以上几种使用场景对于kafka集群的的可用性，可靠性，数据一致性要求其实是不同的，如果将所有场景耦合到同一个集群，在数据量较大的情况下，任何的小异常点都可能造成整体服务受到影响，并且整个集群的恢复周期会很长，如果业务没有及时的降级策略很可能影响核心业务的处理。

鉴于以前对开源分布式服务的规划和改造经验，本篇文章将根据官方文档以及经验来分享一些关于Kafka生产集群规划和运维管理相关的知识.

通常对于很多java应用来说，当打成jar包后会下意识的使用java -jar xxx.jar来运行应用，而不是根据自己业务或实际debug的一些需求

背景: 对于初创企业来说，在很长一段时间一些基础的开源服务基本都是"裸奔"上线的，除了一些传统的主机级别的监控之外，很难有

Traefik的可观测性支持

traefik-observability

注意: 在Traefik-2.X的生态里，将可观测性分为了如下几个部分，并提升到了专门的功能说明中

• 服务日志: Traefik进程本身相关的操作日志
• 访问日志: 由Traefik接管的代理服务的访问日志(access.log)
• Metrics: Traefik提供的自身详细的metrics数据
• Tracing: Traefik也提供了追踪相关的接口，用来可视化分布式或微服务中的调用情况

基于DCGM和Prometheus的GPU监控方案

背景: 在早期的GPU监控中我们会使用一些NVML工具来对GPU卡的基本信息进行采集，并持久化到监控系统的数据存储层。因为我们知道，其实通过nvidia-smi这样的命令也是可以获取到GPU的基本信息的，但随着整个AI市场的发展和成熟，对于GPU的监控也越来越需要一套标准化的工具体系，也就是本篇文章讲的关于DCGM相关的监控解决方案。

背景: 前两天在群里看到有人提到说，自己构建了一个镜像，明明就只往base镜像中增加了tomcat，但是构建好的镜像大小最终却是两倍的tomcat包的大小，最后看到Dockerfile后才发现作者在把tomcat包拷贝进去之后，又使用RUN指令，执行了一次chmod a+x tomcat，我想说，这么搞镜像不大那是不可能的。另外一件事就是前段时间，同事说让搞一个公司级别的base镜像，要稳定并且尽量小，借着这两个事，和大家分享几点Docker镜像相关的事情。

背景: 在如今前后端分离开发的大环境中，我们需要解决一些登陆，后期身份认证以及鉴权相关的事情，通常的方案就是采用请求头携带token的方式进行

前言:gorm是Golang语言中一款性能极好的ORM库，对开发人员相对是比较友好的。当然还有另外一个xorm库也是比较出名的，感兴趣的也可