1 简介

什么是web动态路由，动态路由是指在 Web 框架中，URL 路径中包含 可变参数 或 通配符，可以匹配多个不同的请求路径。

假设 Web 服务的 API 有以下路由：

/user/123 → 获取用户 123 的信息
/user/456 → 获取用户 456 的信息
/user/:id → 匹配任意用户 ID

在这个例子中，:id 是动态参数。

Radix 树如何保障动态路由匹配？
Radix 树通过以下机制保障动态路由匹配：

1. 路径分片 (Prefix Splitting)

每个节点保存路径的公共前缀。
对于动态路由片段 (如 :id) ，可以标记节点类型。

2. 动态参数节点

在插入路径时，如果检测到路径中有 :id，可以将其标记为通配符节点。
在匹配路径时，通配符节点优先级低于精确匹配节点。

3. 路径压缩

将公共前缀合并在同一个节点上，减少节点数量，提升性能。

实现思路

将路径 /user/:id 拆解为 /user/ 和 :id
在节点中保存 :id 标记
查询时优先匹配固定路径
若路径不匹配固定路径，匹配动态参数

2 在微服务治理中

这些模式处理客户端服务如何发现服务器端服务的位置并路由到它们。在基于云的应用程序中，您可能有数百个微服务，每个微服务最多可能运行数百个实例。

需要抽象出这些服务的物理 IP 地址，并为每个服务提供单个入口点，以便您可以一致地对所有服务调用实施连接和安全策略。此外，您需要能够根据某些条件动态路由流量。

这里将介绍两种模式，即 Service Discovery 和 Service Routing

3 服务发现Service Discovery

服务发现需要解决的问题是什么？

如何使微服务可被发现，以便客户端服务可以找到它们，而无需对服务的位置进行硬编码？此外，我们如何确保从可用实例池中删除那些行为异常的服务实例？

• 通信设计

在任何分布式架构中，我们都需要找到机器所在位置的物理地址。这个概念从分布式计算开始就已经存在，正式名称为服务发现。它对微服务、基于云的应用程序至关重要，原因有两个：

它提供了快速水平扩展和缩减服务实例的能力，而服务使用者没有意识到扩展。
它通过从可用实例池中删除运行状况不佳或不可用的实例来帮助提高应用程序弹性。
实现此模式的更可靠方法是使用 Service Discovery Service 并使用 Client-side Load Balancing。图 RP-1 显示了典型服务发现过程的流程。

它比服务器端的 DNS + LB 更好，原因如下：

没有单点故障，因为服务 IP 存储在客户端的本地内存中，因此即使 DNS 或 ELB 或两者都损坏，客户端仍然可以请求服务
LB 算法选择更多，最具体的能力是客户端 LB/Proxy 可以检测实例的性能并均衡负载
Service Discovery 服务具有更高的可用性，因为它是一个分布式存储系统，一个由多个节点组成的集群。数据基于某些分布式系统一致性算法（如 Gossip）在彼此之间快速同步。
下图描述了如何实现客户端服务从不直接知道服务的 IP 地址，而是从服务发现服务获取 IP 地址。

1 当服务上线时，它会向服务发现代理注册其 IP 地址。

2 服务位置可以通过服务发现代理的逻辑名称进行查找。

3 服务发现节点共享服务实例运行状况信息

4 服务向服务发现代理发送检测信号。如果服务终止，服务发现服务将删除“死”实例的 IP。

5 当客户端服务需要调用服务时，它将检查本地缓存中的服务实例 IP。服务实例之间的负载平衡将在客户端服务上进行。

6 如果客户端服务在缓存中找到服务 IP，它将使用它。否则，它将转到服务发现，然后直接将请求发送到实例 IP。
服务发现服务将定期刷新客户端缓存

4 服务路由 Service Routing

需要解决的问题，如何为所有微服务提供单一入口点，以便统一应用安全策略和路由规则？
我们如何确保开发人员不必提出自己的解决方案来路由到其他服务或服务实例？服务路由包括以下 4 个方面，

	动态路由 - 

根据来自传入请求的数据（例如标头），将流量路由到特定服务的不同实例集。P-6 模式将严重依赖这种能力

	静态路由 - 

将所有外部服务调用放在单个 URL 或 URL 前缀后面，并将这些调用映射到实际服务

	准入控制 - 

在一个集中位置检查呼叫者关于所有服务的横切关注点（例如身份验证、授权、防抓取或访问限制）的准入。

	指标收集和日志记录 – 

收集所有传入请求的指标数据，并确保每个用户请求和响应都包含一些关键信息，以便在所有下游服务中进行日志关联。

• 通信设计

动态路由可能需要代理解决方案（如 Nginx、HAProxy 或 Envoy）的协助，尤其是内部微服务之间的路由。我们需要利用这些代理提供的一些功能，例如基于 Weighted的路由、基于路径的路由或基于标头的路由，来实现动态路由。

API Gateway 可以涵盖其他三个要求，即静态路由、准入控制和指标收集。请前往微服务模式网站了解更多详情，我们只从流量治理的角度来讲动态路由。

• 基于标头的路由

此路由方法可用于实现不同类型流量的分离。我们可以将分离特征 Traffic Channel 和每种 Traffic 称为 channel。

例如，我们有两种类型的流量，一种来自面向客户的网站，另一种来自所有其他地方，例如后端作业或我们的公共 API。

5 小结

本文介绍微服务治理的两种路由模式，其中包括模式可以解决的问题、这些问题的常见解决方案以及该解决方案的实现。

第一个选项是 Service Discovery，用于发现具有多个副本的服务实例的目的地，用于处理大规模请求和提供高可用性。
例如AWS App Mesh 基于 AWS Cloud Map，提供了一种声明性方式来为某些服务的不同实例集指定服务发现终端节点。

第二个 Service Routing 用于查找具有多个部署的服务组实例的路径，用于为各种流量提供服务或并行发布不同版本。

例如AWS App Mesh 创建一个多功能的 Kubernetes CRD VirtualRouter，以通过您定义的路由规则（可能基于权重、标头和路径）来导航传入请求。