微服务拆分应以限界上下文定义责任边界，每个上下文对应独立Go module（如git.example.com/micro/order），而非按技术层切分或共用根module；Kubernetes Deployment数量取决于运行时职责分离需求，非建模结果；跨上下文调用必须走gRPC/HTTP契约，禁止直接import internal包；internal/仅限本module私有逻辑，pkg/仅放跨module稳定复用组件并语义化版本；module path须与K8s label及gRPC package名对齐。
微服务拆分不是“把单体切成小块”，而是用限界上下文重新定义责任边界；Go模块化结构不是目录堆砌，而是让go mod能自然反映业务边界——这两件事必须同步设计，否则后期必然出现循环依赖、部署耦合或调试断点失效。
按DDD限界上下文划分服务边界时，为什么不能直接映射到Kubernetes Deployment数量
常见错误是看到一个“订单”上下文，就立刻建一个order-service Deployment，再建一个order-api和order-worker，结果三个Deployment共享同一套model和types包，导致版本升级时必须全量同步发布。
- 每个限界上下文应对应一个独立的Go module（即单独的
go.mod），module path如git.example.com/micro/order，而非共用git.example.com/micro根module - Kubernetes中Deployment数量取决于运行时职责分离需求，不是DDD建模结果：例如
order上下文可只用1个Deployment，但通过不同启动参数区分API server与后台worker进程 - 跨上下文调用必须走gRPC或HTTP契约，禁止直接import对方internal包——哪怕它们物理上在同一Git仓库
Go项目目录结构里，internal/和pkg/到底该放什么
很多团队把所有工具函数塞进pkg/，结果user-service和payment-service都依赖pkg/util，形成隐式耦合。真正的解耦不是靠目录名，而是靠module边界。
Kubernetes Skills
下载
针对 Kubernetes 仪表板和 Web UI 的浏览器自动化。适用于与 Kubernetes Dashboard、Grafana、ArgoCD UI 或其他 Web 界面交互。需要设置 MCP_BROWSER_ENABLED=true。
-
internal/只能被本module内代码引用，Go编译器会强制检查；它适合放纯私有逻辑，比如internal/logic/order_create.go -
pkg/应仅用于**跨module复用且稳定不变**的组件，例如自研的pkg/tracing（封装OpenTelemetry SDK）或pkg/health（标准健康检查Handler），且必须发布语义化版本 - 如果某个“工具函数”只被两个服务用到，但这两个服务属于不同限界上下文，那就把它抽成独立module，而不是放进
pkg/——否则下次改函数签名就得同时升级两个服务
使用go mod vendor时，为什么Kubernetes镜像构建常出问题
本地go build成功，Docker构建却报cannot find module，多数是因为vendor路径没被正确识别，或Go版本不一致。
- Dockerfile中必须显式启用vendor模式：
GOFLAGS="-mod=vendor"，否则go build会忽略vendor目录，仍去拉远程依赖 - 确保
go version在CI环境、本地开发机、Kubernetes节点上完全一致（推荐锁定小版本，如1.25.3），go.sum校验在不同Go大版本间不兼容 - 不要把
vendor/提交到Git——它只是构建产物；但要确保go.mod和go.sum已提交，且go mod verify能通过
服务间通信用gRPC还是HTTP，关键看这三点
不是性能决定选型，而是契约演进成本和可观测性需求。
- 内部服务调用优先用gRPC：Protocol Buffers强制定义接口，
protoc-gen-go生成的代码天然支持trace context传递，且Kubernetes Service + gRPC负载均衡（需配置service.spec.sessionAffinity: None）已足够稳定 - 对外暴露API必须用HTTP/REST：Istio Ingress或Nginx无法解析gRPC帧，且前端、第三方系统集成成本高
- 避免混合使用：同一个服务既暴露gRPC端口又暴露HTTP端口，会导致健康检查、超时配置、重试策略分散在两套体系里，运维时极易漏配
最易被忽略的其实是module命名一致性——go.mod里的module path必须与Kubernetes资源label（如app.kubernetes.io/name）和gRPC service package name保持语义对齐，否则CI流水线里自动注入sidecar或生成OpenAPI文档时会找不到对应关系。
