云原生架构需从业务场景倒推能力边界，以限界上下文划分微服务；Deployment适用于无状态服务，StatefulSet仅用于有状态组件；敏感配置用immutable Secret，非敏感配置用subPath挂载ConfigMap；可观测性须对齐业务KPI，日志带trace_id和业务字段，指标聚焦失败率、延迟、积压数，链路优先跨服务与慢接口。
怎么识别该拆哪些微服务？别从代码下手，从端到端流程切
很多团队一上来就翻单体代码找“模块”，结果拆出来的是技术耦合的服务，不是业务能力。正确做法是：画出一条核心业务线（比如“客户下单→库存扣减→物流调度→签收反馈”），逐环节问：这个动作是否被多个流程复用？能否独立变更节奏或技术栈？是否需要单独扩缩容？
- 如果“库存扣减”同时支撑秒杀、日常下单、B2B批量采购，且峰值流量差异极大 → 它就是高优先级候选微服务
- 如果“签收反馈”只是调用三方快递API+写个状态，逻辑简单且无并发压力 → 暂不拆，用SDK封装更轻量
- 避免按数据库表拆：一张
order表牵扯支付、履约、售后，硬拆会导致分布式事务泛滥
本质是领域驱动设计（DDD）的实践：以限界上下文（Bounded Context）为单位划服务边界，不是以技术分层为依据。
Kubernetes 上部署微服务，Deployment 和 StatefulSet 到底怎么选？
90% 的业务服务用 Deployment 就够了——它管无状态、可替换的 Pod 副本。但一旦涉及有状态组件，选错就等于埋雷：
-
Deployment用于 API 网关、订单服务、用户中心等：Pod 重启后不丢失状态，IP 和名字可变，靠Service做稳定入口 -
StatefulSet只在必须时启用：比如自建 MySQL 主从、Elasticsearch 集群、Kafka broker——要求每个 Pod 有固定名称（es-0,es-1）、独立存储（PVC绑定）、启动顺序（先 es-0 再 es-1） - 常见错误：把带本地缓存的 Spring Boot 服务也塞进
StatefulSet，以为“要持久化”，其实缓存该放 Redis，Pod 本身仍是无状态的
记住：状态 ≠ 数据库。状态是“进程内不可丢的上下文”，而数据应下沉到外部存储。绝大多数业务逻辑不该持有状态。
配置和密钥怎么管？别再写死在镜像里或 ConfigMap 里
把数据库密码塞进 ConfigMap 是高频事故点——它只是 Base64 编码，不是加密，kubectl get cm 一眼可见。更糟的是，更新 ConfigMap 不会自动滚动重启 Pod，导致配置不生效。
ThinkPHP是一个快速、简单的基于MVC和面向对象的轻量级PHP开发框架，遵循Apache2开源协议发布，从诞生以来一直秉承简洁实用的设计原则，在保持出色的性能和至简的代码的同时，尤其注重开发体验和易用性，并且拥有众多的原创功能和特性，为WEB应用开发提供了强有力的支持。 3.2版本则在原来的基础上进行一些架构的调整，引入了命名空间支持和模块化的完善，为大型应用和模块化开发提供了更多的便利。
-
敏感数据（密码、Token、私钥）必须走
Secret，且设置immutable: true防误改 - 非敏感配置（超时时间、开关标识）可用
ConfigMap，但要用subPath挂载单个文件，避免整卷覆盖导致应用启动失败 - 真正解耦的做法：用
envFrom+configMapRef或secretRef注入环境变量，再由应用框架（如 Spring Boot 的@ConfigurationProperties）自动绑定，而不是手动读文件
另外，不同环境（dev/staging/prod）的配置差异，不要靠多套 YAML 文件维护——用 Kustomize 的 patches 或 Helm 的 values.yaml 分层管理，否则 merge 冲突会让你怀疑人生。
可观测性不是加监控工具，而是定义“故障时第一个看什么”
很多团队一上来就堆 Prometheus + Grafana + ELK + Jaeger，结果告警满天飞，却找不到根因。云原生的可观测性核心是三件事：日志打什么、指标曝什么、链路埋哪里，而且必须对齐业务 KPI。
- 日志：禁止
console.log("enter method X")，每条日志必须带trace_id和关键业务字段（如order_id,user_id），否则查问题等于大海捞针 - 指标：除了 CPU/Memory，每个服务至少暴露三个业务指标：
http_request_total{status=~"5.."}（失败率）、process_duration_seconds_bucket（P95 延迟）、queue_length（消息积压数） - 链路：不是所有接口都要全链路追踪。优先在跨服务调用点（如订单服务调支付服务）和慢接口（>200ms）埋点，避免性能损耗和数据爆炸
最常被忽略的一点：没有把业务指标（如“订单创建成功率”）和底层指标（如“支付服务 HTTP 500 错误数”）做自动关联。这意味着运维看到告警，还得人工翻日志去猜哪条业务流断了——这根本不算可观测，只是“可看见”。
