我的请求如何找到目的地？全面掌握Route和Endpoint 🚀

当我们通过互联网购物并点击订单按钮的那一刻，无数数据沿着复杂的路径安全地抵达服务器。就像快递员准确无误地找到我们家的地址一样！📦

在这个过程中，最重要的两个概念就是路由(Route)和端点(Endpoint)。许多人认为它们是独立的，但实际上它们之间有着非常密切的关系。今天，我们将彻底剖析它们之间的关系！

🛣️ 路由(Route): 通往目的地的告诉公路

路由(Route)顾名思义，是关于数据流量应该遵循哪条“路径”的规则或策略集合。

• “如果用户请求/login页面，就发送到‘登录处理服务器’！”
• “来自移动应用的请求，发送到‘v2 API服务器’！”
• “将90%的支付相关请求发送到新服务器，10%发送到稳定的旧版本服务器进行测试！”

就像交通警察一样，Route根据传入流量的特征（地址、头部信息等）来指示它应该去哪里。

但是，Route仅限于此。它只告诉我们目的地“组”，例如“登录处理服务器”，但它不会告诉我们该组中众多服务器中具体是哪个服务器的哪个门（端口）应该进入。

这就像只告诉我们一个大区域，比如“首尔市江南区”。

💡 核心：Route是关于将流量发送到何处的抽象“方向”和“规则”。

🚪 端点(Endpoint): 最终目的地的玄关

端点(Endpoint)是数据流量最终抵达的实际目的地。它是无路可走的尽头，即通信终止的点。

通常以IP地址和端口(Port)号的组合表示。

• 10.1.2.3:8080
• 172.16.0.10:3000

让我们再次回到快递的比喻。如果Route告诉了你“首尔市江南区”的路径，那么Endpoint就是“德黑兰路123号，45层6号”这样非常具体的最终地址。只有有了这个地址，快递员才能准确地送到你家门口，对吧？

💡 核心：Endpoint是流量到达的具体且物理的“最终地址”。

🗺️ 全局视图: Route的尽头必然是Endpoint

现在我们来到了最重要的问题：它们之间是什么关系？

结论是，端点是路由的一部分，也是路由的最终目的地。无论Route规则多么精巧，如果其末端没有Endpoint来接收流量，那么它就毫无意义。

让我们来走一遍整个流程：

1. 请求发生 📨: 用户向http://my-service.com/api这样的地址发送请求。
2. 抵达路由器/网关 🚦: 请求首先进入Kubernetes Ingress或Istio Gateway等流量入口。
3. 检查路由(Route)规则 📜: 网关检查配置的Route规则（例如：Istio的VirtualService）。
• “嗯，是/api的请求。这个请求被设置为发送到api-service！”
1. 查询端点(Endpoint) 🏠: 现在系统开始查找api-service实际在哪里。Kubernetes拥有连接到此服务的Pod列表，即Endpoint列表。
• api-service的Endpoint: 10.1.2.3:8080, 10.1.2.4:8080, 10.1.2.5:8080
1. 最终流量传输 🚚: 网关从查询到的Endpoint列表中选择一个（例如：10.1.2.3:8080），最终将流量传输过去。

如您所见，Route扮演着指定要发送流量的“服务”的抽象向导角色，而在这条路的尽头，始终有一个具体的地址——Endpoint在等待。

---

🤔 常见误解: “Route和Endpoint不就是独立的吗？”

许多人容易将Kubernetes中的Service或Ingress（Route规则）与Endpoints（目的地列表）视为完全独立的概​​念，因为它们作为不同的对象进行管理。

但事实并非如此。🙅‍♂️

从功能上讲，这两者是紧密耦合的。定义Route规则的行为最终是为了决定“将流量发送到哪个Endpoint？”Route定义了“如何”发送，而Endpoint则是“发送到哪里”的最终答案。

这就像有路（Route）却没有目的地（Endpoint），或者有目的地却没有路一样，什么也做不了。

---

💻 通过代码直接确认: Kubernetes & Istio 示例

百闻不如一见！让我们通过实际代码看看它是如何运作的。

1. 创建服务和端点（基本）

首先，当您在Kubernetes中部署名为my-api的服务时，Kubernetes会自动收集连接到此服务的Pod的IP和端口，并创建Endpoints对象。

# 检查连接到my-api服务的端点列表
kubectl get endpoints my-api

[原始数据结果]

NAME     ENDPOINTS                               AGE
my-api   10.1.2.3:8080,10.1.2.4:8080,10.1.2.5:8080   2d

👆 这就是流量最终可以到达的“实际地址”列表。

2. 使用Istio VirtualService定义路由规则

现在，让我们使用Istio的VirtualService创建复杂的路由规则。规则是“将90%的传入请求发送到v1版本，10%发送到v2版本。”

# my-api-route.yaml
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: my-api-virtualservice
spec:
  hosts:
  - "my-api.example.com"
  http:
  - route: # 👈 这就是“路由(Route)”规则。
    - destination:
        host: my-api-service # 👈 发送到哪个服务？
        subset: v1           # 👈 发送到该服务的“v1”版本组！
      weight: 90
    - destination:
        host: my-api-service # 👈 发送到哪个服务？
        subset: v2           # 👈 发送到该服务的“v2”版本组！
      weight: 10

在上面的YAML中，http.route部分就是路由。此路由指示“将请求发送到my-api-service，但将其分为v1和v2组。”

Istio会引用属于这些v1和v2组的Pod的实际IP地址，即我们上面确认过的Endpoints列表（10.1.2.3:8080等），最终将流量发送过去。

最终，VirtualService中定义的华丽的Route规则，也只不过是为了将流量发送到具体的Endpoint而设计的精巧指示牌。

结论

端点是流量传输路径的核心最终组成部分。

• Route (路由): 关于将流量发送到何处的策略和规则（高速公路）
• Endpoint (端点): 流量最终抵达的实际地址（家门）

下次您设计网络架构或进行故障排除时，请务必记住这两者之间的关系。只有将抽象的路由规则(Route)和具体的目的地(Endpoint)结合起来看，才能彻底理解整个流量的流向！😉

---