最近我在回顾思考（写 PPT），整理了现状，发现了这个问题存在多时，经过一番波折，最终确定了元凶和相对可行的解决方案，因此也在这里分享一下排查历程。 时间线： 在上 Kubernetes 的前半年，只是用 Kubernetes，开发没有权限，业务服务极少，忙着写新业务，风平浪静。 在上 Kubernetes 的后半年，业务服务较少，偶尔会阶段性被运维唤醒，问之 “为什么你们的服务内存占用这么高，赶紧查”。此时大家还在为新业务冲刺，猜测也许是业务代码问题，但没有调整代码去尝试解决。 在上 Kubernetes 的第二年，业务服务逐渐增多，普遍增加了容器限额 Limits，出现了好几个业务服务是内存小怪兽，因此如果不限制的话，服务过度占用会导致驱逐，因此反馈语也就变成了：“为什么你们的服务内存占用这么高，老被 OOM Kill，赶紧查”。据闻也有几个业务大佬有去排查（因为 OOM 反馈），似乎没得出最终解决方案。 不禁让我们思考，为什么个别 Go 业务服务，Memory 总是提示这么高，经常达到容器限额，以至于被动 OOM Kill，是不是有什么安全隐患？

虽然公司已经从大单体切换为微服务化有一定的年头了，但一些细节方面的处理总会有不同的人有不同的看法，这其中一个讨论点，就是 Proto 这个 IDL 的代码到底放在哪里？ 目前来看，一共有如下方案， 我们一起来探讨一下 Proto 的存储方式和对应带来的优缺点。 方案一：存放在代码仓库 直接将项目所依赖到的所有 Proto 文件都存放在 proto/ 目录下，不经过开发工具的自动拉取和发布： 缺点 项目所有依赖的 Proto 都存储在代码仓库下，因此所有依赖 Proto 都需要人工的向其它业务组 “要” 来，再放到 proto/ 目录下，人工介入极度麻烦。 Proto 升级和变更，经常要重复第一步，沟通成本高。

在前面的章节中，已经知道了如何对应用程序进行 Prometheus metrics 的注册和暴露，那么接下来如何让 Prometheus 对应用程序进行采集呢。 设置采集配置 首先打开先前所安装的 prometheus 软件目录： $ ls LICENSE data promtool NOTICE prometheus rules console_libraries prometheus.yml tsdb consoles prometheus.yml.default 打开并修改 prometheus.yml 文件，查看到 scrape_configs 配置选项，进行如下调整： ... scrape_configs: - job_name: 'test01' static_configs: - targets: ['127.

在上一个章节中我们完成了 Prometheus 的基本概念了解和安装，由于考虑到看我博客的估计是开发向的小伙伴居多，因此没有再更深入。而今天本章节将介绍我们开发用的最多的度量指标，并结合实战对 Metrics 进行使用和细节分析。 什么是度量指标 来自维基百科 度量是指对于一个物体或是事件的某个性质给予一个数字，使其可以和其他物体或是事件的相同性质比较。度量可以是对一物理量（如长度、尺寸或容量等）的估计或测定，也可以是其他较抽象的特质。 简单来讲，也就是数据的量化，形成对应的数据指标。 Prometheus 的指标格式 在 Prometheus 中，我们的指标表示格式如下： <metric name>{<label name>=<label value>, ...} 主体为指标名称和标签组成： api_http_requests_total{method="POST", handler="/eddycjy"} 对外提供 metrics 服务 首先创建一个示例项目： func main() { engine := gin.

一般我们说 Prometheus，有两种理解，我们平时需要注意识别的，其含义有两种，一是指的 Prometheus 自身，是一个时序数据库；另外一种是指 Prometheus 生态圈，指的是是整体的监控报警的生态圈和解决方案（Prometheus+Grafana+Alertmanager）。 Prometheus 在 2016年加入了 CNCF（Cloud Native Computing Foundation），是继 Kubernetes 之后的第二个托管项目，目前已经毕业，其主要的特点如下： 多维度的数据模型：由指标名称和键/值对标签标识的时间序列数据来组成多维的数据模型。 灵活的查询语言：在 Prometheus 中使用强大的查询语言 PromSQL 来进行查询。 不依赖分布式存储，Prometheus 单个节点也可以直接工作，支持本地存储（TSDB）和远程存储的模式。 服务端采集数据：Prometheus 基于 HTTP pull 方式去对不同的端采集时间序列数据。 客户端主动推送：支持通过 PushGateway 组件主动推送时间序列数据。 Prometheus 生态组件 Prometheus 生态由多个组件共同组成，其中许多组件是可根据实际情况选择的，并且绝大部分由 Go 语言编写，在部署和构建上比较方便，如下：

在前面的章节中，我们介绍了快速部署 Kubernetes 和应用程序的方法，接下来在本章节中我们将对 Kubernetes 的 API 进行了解，并且进行调用，这是开发人员最关注的一环之一。 因为不论是 DevOps、基础架构，又或是自愈，都需要与 Kubernetes API 直接/间接接触，因此即使在你不懂 Kubernetes 的情况下，Kubernetes API 的知识点仍然属于必知必会，API 总得会调。 查看 Kubernetes API kube-apiserver 架构图 （图来自 kubernetes.io） 在 Kubernetes 的架构中，由 kube-apiserver 组件在主节点上提供 Kubernetes API 服务，kube-apiserver 是 Kubernetes 所有控制的前端，对外提供大量的 RESTful API。

在完成了本地 Kubernetes 的快速搭建（基于 Docker）后，我们已经可以正式的使用它了。对于我们平时最常见的需求，那就是往 Kubernetes 里部署应用程序，如果你没有看过 Kubernetes 相关的知识，这时候你可能会六神无主，但问题不大，我们就可以使用最经典的 Nginx 来小试身手。 创建 Deployment 创建 nginx-deployment.yaml 文件： apiVersion:apps/v1kind:Deploymentmetadata:name:nginx-deploymentlabels:app:nginxspec:replicas:2selector:matchLabels:app:nginxtemplate:metadata:labels:app:nginxspec:containers:- name:nginximage:nginx:1.18.0应用 nginx-deployment.yaml 文件： $ kubectl apply -f nginx-deployment.yaml deployment.apps/nginx-deployment created 查看运行状态 查看 Pod 运行情况：

Kubernetes 在容器编排大战结束后已经在云原生中占据了明确的一席，最近几年越来越火热，目前搜索趋势： Kubernetes 的热度很明显是不断地在上涨，因此学习和使用 Kubernetes 是一件相对正确的事，同时公司大多都在往容器化上接近，在拥抱 Kubernetes，所以我们所开发的应用也总是跑在容器环境中。更甚的是，需要对接 Kubernetes API 来做一些功能的开发。 这个时候，我们就需要一个 Kubernetes 环境来进行开发和调试，但你准备开始时，又遇到了一个问题，虽然在 2020 年的现在，Kubernetes 的安装已经有了极大的简化，教程也满地跑，但 Kubernetes 的安装和运行依然有一定的要求，像我，就遇到了如下问题： 显然，我的小水管 Mac 承受不起，但是又需要对 Kubernetes 进行学习和使用，除了买云服务器，又或是再在台式机上搭虚拟机，还有没有什么办法呢。 非运维开发的情况下，入门级中最简单的方式就是采用 Docker 所提供的 Kubernetes 支持。 Docker for Mac/Windows with Kubernetes Docker 在 17.

2020 年的上半年因为一些事情耽搁了整体的进程，不过最近也快要到 Deadline 了，因此又愉快的能空出手了。 回顾这几年在个人技能上，我随着公司的大泥球应用再到微服务化的飞速发展，经历了很多，突破了更多，有了不少新的感悟。因此今年打算再修修内功，认识一下自己的弱小，所以读书清单会比较偏基础方向，如下： 必看 《图解 TCP/IP》 《TCP/IP 详解 卷1：协议》 《深入理解计算机系统》 《大话数据结构》 《算法（第4版）》 《剑指 Offer》 《操作系统_清华大学》 可选 《Unix 环境高级编程（第3版）》 《SRE Google 运维解密》：进行中，已经了看了不少。 《Google 工作法》：进行中，已经了看了不少。 所有的目标都需要有一个验收的标准和奖罚，否则所谓的目标意义不会特别大。我想，验收标准就是 《重读 CS》 的基本成型，其它不在该集合类的属于第二梯队，考虑释出读书笔记。

Go modules 是 Go 语言中正式官宣的项目依赖解决方案，Go modules（前身为vgo）于 Go1.11 正式发布，在 Go1.14 已经准备好，并且可以用在生产上（ready for production）了，Go官方也鼓励所有用户从其他依赖项管理工具迁移到 Go modules。 而 Go1.14，在近期也终于正式发布，Go 官方亲自 “喊” 你来用： 因此在今天这篇文章中，我将给大家带来 Go modules 的 “终极入门”，欢迎大家一起共同探讨。 Go modules 是 Go 语言中正式官宣的项目依赖管理工具，Go modules（前身为vgo）于 Go1.