3. Oracle Cloud Infrastructure服务网格（OCI Service Mesh）入门

在微服务架构中，服务之间的通信一旦从单体应用内部的函数调用变成跨进程、跨主机的网络调用，就会立刻引入一系列新的问题：服务如何发现彼此、流量如何加密、调用失败如何重试、灰度发布如何按比例切流、调用链如何观测。传统做法是把这些能力以 SDK 的形式写进每个服务的代码里，但这样会导致语言绑定、版本升级困难、业务代码被治理逻辑污染。服务网格（Service Mesh）正是为了解决这一矛盾而出现的：它把服务间通信的治理能力从应用进程中“下沉”到基础设施层，让业务代码只关心业务逻辑。

一、服务网格的核心概念

服务网格的本质是一组轻量级网络代理的集合，这些代理与业务服务实例一起部署，接管服务之间的所有入站和出站流量。它通常被划分为两个平面：

• 数据平面（Data Plane）：由与业务容器同生命周期的代理组成，负责实际转发、加密、限流、重试等流量处理动作，是真正“搬运数据包”的一层。
• 控制平面（Control Plane）：负责下发配置、签发证书、收集遥测数据，把“策略”翻译成数据平面能执行的规则，本身不直接参与业务流量转发。

服务网格带来的典型能力包括：mTLS 双向认证与自动证书轮换、基于权重的流量切分、超时与重试策略、熔断与故障注入、细粒度的访问控制，以及统一的指标、日志和分布式追踪。这些能力对应用代码是透明的，因此多语言微服务可以共享同一套治理策略。

二、Sidecar 代理模式

Sidecar（边车）模式是服务网格数据平面的实现基础。它的做法是：在同一个 Pod（或同一台主机）内，为每个业务服务实例额外启动一个代理容器，业务容器的所有进出流量都被重定向到这个代理，由代理完成治理后再转发给真正的目标。

以 OCI 服务网格为例，Sidecar 通常使用 Envoy 作为代理实现。流量重定向依赖 Pod 网络命名空间中的 iptables 规则：入站流量被劫持到 Envoy 的监听端口，出站流量同样先经过 Envoy，再由 Envoy 根据控制平面下发的路由规则选择目标实例。这样，业务容器看到的仍然是普通的 HTTP/gRPC 调用，而加密、重试、负载均衡都在 Sidecar 中完成。

Sidecar 模式的优势在于语言无关、升级独立、策略统一；代价是每个实例多一个容器，带来一定的资源开销和调用延迟（通常为毫秒级）。因此在实际部署中需要为 Sidecar 设置合理的 CPU/内存 requests 与 limits。

三、OCI 服务网格的架构组件

OCI 服务网格是 Oracle Cloud Infrastructure 提供的托管式服务网格能力，它与 OKE（Oracle Container Engine for Kubernetes）深度集成，控制平面由 OCI 托管，用户无需自行运维 Istio 控制平面。其关键组件包括：

• Mesh（网格）：逻辑边界，用于把一组需要互相通信的服务纳入同一治理域，通常按命名空间或应用划分。
• VirtualService（虚拟服务）：定义路由规则，例如按 HTTP 路径、Header 或权重把请求分发到不同版本的服务。
• DestinationRule（目标规则）：定义流量到达目标后的策略，如负载均衡算法、连接池、熔断阈值、mTLS 模式。
• Ingress Gateway（入口网关）：网格的南北向入口，把集群外部流量引入网格内部，并执行入口侧的路由与 TLS 终止。
• Sidecar 注入：通过命名空间标签或 Pod 注解，让 OCI 服务网格自动为工作负载注入 Envoy 代理容器。

这些组件的关系可以概括为：Mesh 划定范围，VirtualService 决定“去哪里”，DestinationRule 决定“怎么去”，Ingress Gateway 决定“怎么进来”，Sidecar 负责“实际执行”。

四、安装与配置服务网格控制平面

在 OCI 上启用服务网格，通常先确认 OKE 集群可用，然后在 OCI 控制台或使用 CLI 创建 Mesh 资源。以下示例展示通过 OCI CLI 创建网格并启用 Sidecar 注入的典型过程，参数为教学示例，实际使用时需替换为你的 compartment、VCN 和子网 OCID。

# 1. 查看可用的 OKE 集群
oci ce cluster list --compartment-id ocid1.compartment.oc1..example

# 2. 创建服务网格（示例参数）
oci service-mesh mesh create \
  --compartment-id ocid1.compartment.oc1..example \
  --display-name demo-mesh \
  --vcn-id ocid1.vcn.oc1..example \
  --description "Demo mesh for microservice governance"

# 3. 为命名空间开启 Sidecar 自动注入
kubectl label namespace demo istio-injection=enabled

# 4. 重启工作负载，使 Sidecar 生效
kubectl rollout restart deployment -n demo

执行完成后，可以用以下命令确认 Sidecar 是否注入成功。若 Pod 的 READY 列显示为 2/2，说明业务容器与 Envoy 代理都已就绪；若仍为 1/1，则说明注入未生效，需要检查命名空间标签、Pod 注解以及 OCI 服务网格的注入策略。

kubectl get pods -n demo
# NAME                        READY   STATUS    RESTARTS   AGE
# service-a-7c9f8d6b5-2xk4p   2/2     Running   0          45s
# service-b-5f7c9d8a4-9m2qz   2/2     Running   0          45s

五、验证与观察

网格是否真正生效，不能只看 Pod 是否 Running，而要通过实际调用和可观测数据来判断。一个简单的验证方式是：在 demo 命名空间中启动一个临时客户端，调用服务 A，然后观察 Sidecar 日志中是否出现对应的出站和入站记录。如果调用成功且日志中能看到目标服务、响应码和耗时，说明数据平面已经接管流量。

进一步地，可以配置 VirtualService 将 90% 流量指向 v1、10% 指向 v2，然后通过多次调用统计响应版本分布，验证灰度切流是否符合预期。若比例明显偏离，应检查 VirtualService 的权重配置、DestinationRule 的子集定义以及目标 Pod 的标签是否匹配。通过这种“配置—调用—观察—修正”的闭环，才能真正掌握 OCI 服务网格的治理能力。