为什么Serverless应用引擎的部分请求还是会打到正常的那个pod上去？

这很可能是由于负载均衡算法的问题。

一般情况下,Serverless应用引擎使用随机负载均衡算法。

灰度发布时,会将请求根据x-mse-tagheader分配到不同的pod实例。

但是随机负载均衡存在一个问题,请求还是有一定概率分配到其它pod。

尤其是:

请求量很大时,分配不够均匀
pod实例数目不同时,分配不均衡
比如有2个pod,其中1个为灰度实例,承载10%的流量。

由于负载均衡是随机的,存在10%-20%的请求还是有可能分配到非灰度实例。

因此部分请求仍然会打到正常的pod上。

为了解决这个问题,可以考虑使用:

点选负载均衡算法
确保header标识的请求只分配到对应的实例。

Eureka服务注册
实现基于服务名字的负载均衡,而非端口。

基本上只要能实现基于请求标签(header)的精确分流,就可以解决这个问题。

在Serverless应用引擎（SAE）中，部分请求可能会打到正常的Pod上，而不是通过无服务器计算处理。这主要与SAE的设计和实现方式有关。

SAE采用了混合架构的方式，其中一部分请求会通过无服务器计算（Function Compute）进行处理，而另一部分请求会直接路由到正常的Pod上。

具体来说，当您的应用程序配置了HTTP触发器时，请求首先会进入负载均衡器（SLB），然后按照规则分发到容器组（Container Group）中的无服务器计算或正常Pod之间。默认情况下，大部分请求会进入无服务器计算以实现无服务器计算的弹性、可扩展等特性。但对于某些请求，例如长连接、大文件上传、WebSocket等特殊场景，SAE会将其直接路由到正常的Pod中进行处理。

SAE根据请求的特征和类型来决定是否通过无服务器计算进行处理，这样可以根据实际需要灵活调度计算资源和容器资源。这种混合架构的设计可以兼顾Serverless计算的优势和传统容器的灵活性。

需要注意的是，SAE的具体实现方式可能会根据阿里云的策略和技术进展而变化。因此，在使用SAE时，建议参考官方文档，以了解最新的架构和行为。