Java programming language
View all tags
外部使用 REST，不代表内部也必须使用 REST；内部使用 gRPC，也不代表每个语言都要各自维护证书、重试、负载均衡和访问控制。Istio 的价值，是把跨语言的网络治理收敛到统一的数据平面和策略层。
本文不从 Bookinfo 示例开始，而是搭建一条更接近真实生产系统的链路：
外部客户端
→ HTTPS / REST
→ Istio Ingress Gateway
→ Java Web API
→ gRPC
→ Go Order Service
→ gRPC
→ Rust Inventory Service
→ PostgreSQL
三个服务只实现业务协议，Istio 负责入口、东西向 mTLS、工作负载身份、流量分配、超时、异常实例摘除和基础遥测；应用仍负责业务权限、幂等、事务、数据加密和 Trace Context 传播。
gRPC 在 Kubernetes 中“能调用成功”并不等于“已经具备生产级负载均衡”。当客户端只解析到一个 ClusterIP，再通过一条长期存在的 HTTP/2 连接发送请求时，多个 Pod 很可能长期冷热不均。
本文以 service-a 这一通用 Java 服务为例，复盘一条典型的生产治理路径：保留现有 ClusterIP Service 兼容原有调用，再增加只供内部 gRPC 发现的 Headless Service，让 Java gRPC 客户端和 Envoy 看见每一个 Pod，并把服务发现、健康检查、摘流、连接排空、超时重试、可观测性和发布验收串成闭环。
如果需要先补齐协议和 Java 基础，可以依次阅读 HTTP/2 协议层、Java 与 Netty 实现 和 gRPC 生产治理；本文专注 Kubernetes 与 Envoy 的端点级落地。
这不是一份只解决“DNS 返回几个 IP”的配置说明。生产落地需要同时回答六个问题：
GraphQL 赋予了前端极大的灵活性，允许客户端按需获取数据，避免了 RESTful API 常见的过度获取（Over-fetching）或获取不足（Under-fetching）问题。然而，随着灵活性的增加，GraphQL 在生产环境中也面临着巨大的挑战——尤其是安全防护、性能瓶颈、细粒度权限管控等问题。
本文将结合一线大厂的实践经验，从流量网关、代码侧深度与大小防护、基于 OPA 的动态权限管控、以及监控指标四个维度，为你梳理一套可落地的 GraphQL 生产环境架构闭环。
"写 Demo 很简单，但理解框架底层才能不被生产事故打个措手不及。"
在 上一篇 中，我们深度解构了 gRPC 的灵魂——HTTP/2 协议。
本文将落地到 Java 实现层，带你剥开 grpc-java 的源码，理解 Netty 线程模型和跨语言调用的实践。