前言 随着业务发展，MongoDB 中的核心业务流（如停车流水、订单日志等）会逐渐演变成几千万甚至数亿级别的超大集合。为了保障核心查询性能和控制存储成本，冷热数据分离成为了必经之路。 核心迁移方案全景对比 根据不同的业务特征和基础架构能力，冷热分离有以下主流架构选型。 基于 Change Stream / FlinkCDC 实时同步 + 异步清理 …

现状 传统微服务下的IAM（SSO）方案，要么是使用开源的IAM系统，然后各子系统进行轻量/重量级改造来进行适配，要么是自主研发使用spring security、shiro等权限框架实现统一认证/授权。其中以Sa-Token框架较为优秀，大部分关于认证、鉴权等操作均有封装较好的函数，可以实现一行代码调用实现，且有成熟的jar包，各子系统只需要ma…

前言 在 Kubernetes (K8s) 集群中，服务 YAML 文件里的 resources 配置块往往是被开发者误解最深的区域。面对 requests 和 limits，许多人的做法是“凭感觉填”或者“抄隔壁项目的配置”。 但实际上，这短短几行 YAML 决定了你的微服务在面对突发流量时是安然度过、被无情限流（Throttling），还是直接…

前言 现所属公司使用了k8s来作为生产环境，使用了knative来作为服务基础构建，底层服务与服务之间的通信全由knative-eventing进行异步传输，broker底层使用的kafka作为消息队列存储。那么服务与服务之间的通信目前是处于黑盒状态，A到B的消息A是否发送成功了，kafka是否收到了，以及B是否消费了，这都是黑盒的。又因为前几天因…

前言 在云原生架构中，系统是否能够真正做到“弹性伸缩”，取决于对底层扩缩容引擎的控制力。从基础的资源监控（CPU/内存），到面向业务的 Serverless 并发调度，扩缩容不仅是简单的“超过阈值就加机器”，而是一套精密结合了数学计算、防抖动容错以及业务特性的控制流。 扩缩容的核心大脑：K8s 原生 HPA 的底层规则 HPA (Horizonta…

前言 在 Kubernetes (K8s) 集群中，服务 YAML 文件里的 resources 配置块往往是被开发者误解最深的区域。面对 requests 和 limits，许多人的做法是“凭感觉填”或者“抄隔壁项目的配置”。 但实际上，这短短几行 YAML 决定了你的微服务在面对突发流量时是安然度过、被无情限流（Throttling），还是直接…

前言 在 Kubernetes (K8s) 集群中，服务 YAML 文件里的 resources 配置块往往是被开发者误解最深的区域。面对 requests 和 limits，许多人的做法是“凭感觉填”或者“抄隔壁项目的配置”。 但实际上，这短短几行 YAML 决定了你的微服务在面对突发流量时是安然度过、被无情限流（Throttling），还是直接…

仓促编写，新鲜出炉，如有错误，欢迎大家指正~ 目标 早干完，早回家！不熬夜！ 痛点 服务众多，上线发布巨慢无比 目前有五十个微服务，需要把这些全部上线才能构建完整系统。CPD项目引入serverless，完全实现后服务数量会成指数级增长。上线时一个个发布巨慢无比。 配置众多，不好管理 基于以上服务，每个至少有三个配置文件，就是总共约150个配置文件…

先看本地和operator的效果！ 原理也可简单，就是通过k8sGPT把集群状态信息发送给大模型，由大模型进行诊断并给出具体操作由k8sGPT去执行。 前言 深夜被告警邮件叫醒，对着满屏飘红的 CrashLoopBackOff 和 ImagePullBackOff 发呆？又或者在成百上千行的 Kubernetes 事件日志里大海捞针，试图寻找那个导…

前言 构建k8s集群大体可分为三种方式： 使用kubeadm或者封装了kubeadm的框架进行部署。 使用terraform在支持的云厂商进行部署。 直接购买云厂商现成的k8s集群产品。 这三种方式由难到易（其实难的也没多难，就是可能会稍微复杂一点点），这里记载使用terraform在腾讯云构建k8s集群因参数设置不对，导致serviceIP不够，…