envoy怎么代理mysql_Envoy 代理如何处理用户请求

组织常常想知道服务网格如何为部署提供更好的可视性，从而更清楚的了解用户体验。

然而无论是指标或是日志都无法提供单个案例的具体信息。这就是追踪体现作用之处了。

通过对每个用户请求附加关联ID，追踪可以向开发者提供用户体验的完整来龙去脉。该关联ID作为线索，将多个服务的追踪链连接在一起。

由于所有的请求都经过Envoy，看起来Envoy可以提供追踪信息，但并非如此简单。对于Envoy来说，每个应用看起来就像网络一样，即Envoy对应用内部没有任何特殊的洞察力。这意味着Envoy无法追踪因果关系：10条请求进入一个服务，同时有100条请求离开了该服务，这100条请求中的哪些请求与之前的那 10 条请求有关？正因为Envoy不能回答这个问题，所以它无法代表你的应用自动转发追踪上下文或任何类型的上下文。下面的演示以图表的形式展示了这一点。

网络中的请求上下文

追踪沿着请求通过多个服务的路径了解用户体验的全部上下文。追踪起始于一条被分配了关联ID的用户请求。

当追踪开始时，一些标头会被附加到请求上，包括一个正常的标头。

追踪标头也同样被附加到这条请求上，在本例中是1234。

自定义标头也被附加上了。

Envoy位于应用旁边，它俩相互通信。任何进入应用的请求都要经过Envoy。

追踪将显示所有发生在用户请求上的事。由于请求经过了Envoy，所以这个环节也是追踪的一部分。在经过Envoy之后，请求将进入应用。

Envoy也会附加额外的标头以收集应用内部发生什么的信息。

当请求在应用中流动时，该应用可能会联系另一个系统处理请求。

我们可以在应用内部看到这条发出的请求代表来自追踪ID为1234的用户的请求。

每条请求都需要一个Identity，在这里我们可以看到这条请求是和该用户是相关的。

这儿有点复杂。应用必须为该用户复制Identity。因为如果应用不复制Identity，下一条请求就不知道是哪一用户的。

应用发送对用户请求的响应，继而获得回馈的响应。

系统可能需要来回执行多条请求才能获得用户请求的完整答复并返回。

如果应用只接收到一条请求，服务网格可以传播标头信息并进行所有的追踪。但是不存在一次只接收一条请求的情况，总有多条请求同时发生。正是因为这种并发性(即多件事同时发生)导致了可视性不足。

由于Envoy只能看到网络而非应用内部，因此它只看到多条请求和响应。Envoy没办法知道其中哪些属于不同的用户请求，因为它们都是同时发生的。Envoy无法以在单独的请求上附加数据的方式关联不同的请求。

如果我们同时添加多条用户请求，会看到来回的请求和响应数开始快速增长。

这就像第11点里所说的，应用必须复制请求中的数据以实现追踪。这不太容易做到，但一些由追踪社区构建的工具可以让它变得更容易。Tetrate推荐Zipkin。

这就是为什么业务逻辑自身需要将传入请求的标头转发到传出请求上。有许多专门做这个的库用于各种追踪系统和语言。TSB(Tetrate Service Bridge)和Zipkin一起发布，因此任何Zipkin列出的库或者agent都可开箱即用。

对于那些需要被转发的自定义的、非追踪的标头，需要开发者团队在使用的库中自己实现这些。