1. 课程导入与Oracle Cloud微服务全景

欢迎进入《Oracle Cloud微服务治理与服务通信》课程。在接下来的学习中，我们将围绕一个核心问题展开：当微服务数量从十几个增长到上百个，服务之间的调用关系从简单链路演变为复杂网状结构时，如何保证通信可靠、治理可控、故障可查？Oracle Cloud Infrastructure（OCI）提供了一套完整的服务通信与治理能力，包括API网关、服务网格、服务连接器、负载均衡器等组件。本课程的目标不是泛泛介绍概念，而是帮助你在OCI上真正搭建、配置、调试和运维微服务通信体系。

为什么微服务治理与服务通信是核心挑战

微服务架构将单体应用拆分为多个独立部署的服务单元，每个服务可以独立开发、独立发布、独立扩缩容。但拆分带来的代价是：原本在单体内部的方法调用，变成了跨进程、跨网络的远程调用。这引入了一系列新问题。

第一，服务发现与寻址。在单体应用中，模块A调用模块B只需要一个函数名。在微服务中，服务实例的IP地址和端口是动态变化的，容器可能随时被调度到不同节点。调用方需要一种机制来动态获取目标服务的可用实例列表。

第二，通信可靠性。网络不是可靠的。超时、重试、熔断、限流、降级这些机制如果每个服务都自己实现一遍，不仅重复劳动，而且很难保证策略一致。一个服务重试3次，另一个重试5次，级联放大后可能压垮下游。

第三，安全与可观测性。服务之间的调用是否需要认证？是否要加密？调用链如何追踪？日志如何关联？当出现问题时，能否快速定位是哪个服务、哪个实例、哪个接口出了问题？

第四，流量治理。灰度发布、A/B测试、金丝雀发布、流量镜像等场景，要求能够对服务间的流量进行精细控制。这些能力如果依赖应用代码实现，会严重侵入业务逻辑。

这些挑战的共性在于：它们都是横切关注点，不应该由每个微服务各自实现，而应该下沉到基础设施层统一处理。这正是服务网格和API网关要解决的问题。

OCI服务网格与API网关的定位

在OCI的服务通信体系中，API网关和服务网格处于不同的位置，承担不同的职责。

OCI API Gateway位于系统边界，面向外部客户端（如浏览器、移动App、第三方系统）。它负责北向流量的接入，提供路由、认证、限流、请求转换、响应缓存等能力。API网关是外部世界进入微服务系统的统一入口。

OCI Service Mesh位于系统内部，面向服务之间的东西向流量。它通过在每个服务实例旁部署Sidecar代理（基于Envoy），拦截服务间的所有网络通信，实现流量管理、安全策略、可观测性等功能。服务网格的核心价值在于：业务代码不需要感知通信治理逻辑，所有策略由网格控制面统一下发。

两者配合使用，形成完整的流量治理体系：外部请求先经过API网关进行认证和粗粒度限流，然后进入服务网格，由网格完成服务间的细粒度流量控制、重试、熔断和链路追踪。

整体课程框架与实战项目

本课程共30章，按照“基础认知→核心组件→治理策略→可观测性→综合实战”的路径组织。前几章建立OCI微服务全景认知，随后深入API网关和服务网格的配置与使用，再展开流量治理、安全、可观测性等专题，最后通过一个完整的实战项目串联所有知识点。

实战项目是一个典型的电商订单处理系统，包含以下微服务：order-service（订单服务）、inventory-service（库存服务）、payment-service（支付服务）、notification-service（通知服务）。系统部署在OCI Container Engine for Kubernetes（OKE）上，通过API网关暴露订单创建接口，服务之间通过服务网格进行通信治理。

在实战中，你将实际配置以下内容：API网关的路由规则和JWT认证；服务网格的VirtualService和DestinationRule；服务间的mTLS加密；基于权重的灰度发布策略；熔断和重试策略；以及通过OCI Logging和Monitoring观察调用链和指标。每个配置都会给出具体的YAML示例和验证方法。

让我们从最基础的问题开始：在OCI上，一个微服务请求从外部客户端发出，到最终返回响应，中间经过了哪些组件？每个组件做了什么？理解这条完整链路，是后续所有配置和排障的基础。