云原生是为云而生的方法论，核心在于默认运行于弹性分布式环境，而非简单容器化单体应用；需解决无状态、服务发现、按业务域拆分微服务、合理配置K8s探针与资源、构建业务语义层可观测性。
云原生不是一种技术，而是一套“为云而生”的构建和运行应用的方法论——它要求你在写第一行代码时，就默认自己跑在弹性、分布、自动化的云环境里，而不是把旧系统打个包扔上云。
为什么不能把单体应用直接 Docker 化就叫云原生？
很多人以为 docker build + docker run 就是云原生，其实只是容器化第一步。真正卡住落地的，是没解决“状态”和“协作”问题：
- 单体镜像启动快，但无法独立扩缩容（比如只扩订单模块，不扩用户模块）
- 数据库连在容器里？违反
十二要素第六条“进程必须无状态”，故障恢复和滚动更新都会失败 - 没有
Service或Endpoint抽象，服务间调用硬编码 IP/Port，Kubernetes 一调度就断连
换句话说：容器是“车”，Kubernetes 是“高速公路+交管系统”，但如果你还用这辆车拉整列绿皮火车（单体），那再好的路也跑不出云原生的效果。
微服务拆分到底按什么边界？别迷信“一个功能一个服务”
真实项目里，最常踩的坑是过早、过细拆分。比如把“发短信验证码”单独成服务，结果引入了 3 个新问题：延迟增加、链路追踪变复杂、运维成本翻倍。
Docker Image Puller
下载
使用 Python 脚本下载 Docker 镜像并打包为 tar 文件。用户说“下载镜像”“拉取镜像”“pull xxx”“帮我下载 nginx 镜像”等时触发。支持 SOCKS5 代理直连（推荐）和国内镜像站加速两种模式。
- 优先按
业务域划分（如“会员中心”“交易中台”），而非功能点 - 每个服务必须拥有自己的数据库（
database per service），禁止共享 MySQL 实例 - 服务间通信必须走轻量协议：
gRPC（内部）或REST over HTTPS（对外），禁用直连 JDBC - 初期可保留“伪微服务”：同一进程内多模块 + API 网关路由，等流量和团队成熟再物理拆分
Kubernetes YAML 里哪些字段动不得？
新手常改错关键字段，导致部署后行为反直觉。最典型的是：
-
replicas写死为1？——失去弹性基础，HPA 失效 -
livenessProbe和readinessProbe混用：用liveness做健康检查，服务卡住时反复重启；该用readiness控制流量接入 - 没设
resources.requests？Kubernetes 调度器无法判断节点是否有空闲资源，Pod 可能永远Pending -
imagePullPolicy: Always在生产环境慎用——镜像名带:latest时会绕过本地缓存，拖慢发布
可观测性不是加个 Prometheus 就完事
很多团队部署了 Prometheus + Grafana，但告警全靠 CPU > 80%，等于回到十年前。云原生需要的是“业务语义层”监控：
- HTTP 服务必须暴露
/metrics，统计http_request_duration_seconds_bucket（P95 延迟）比看 CPU 有用十倍 - 日志不能只收集
stdout，要打结构化字段：{"service":"order","order_id":"ORD-2026-xxxx","status":"timeout"} - 分布式追踪必须透传
trace_id，从 API 网关进来的请求，要贯穿到下游所有gRPC调用，否则查一次超时根本定位不到哪一跳挂了
真正的难点不在工具安装，而在让每个服务开发者理解：你写的那行 log.Info("order created")，得能被 Loki 当成查询条件，得能和 Jaeger 的 span 关联上——否则可观测性就是摆设。
