spring-cloud-tencent
spring-cloud-tencent copied to clipboard
Tencent
支持协议标签透传
What is the feature you want to add? SCT用户，在Feign和RestTemplate的调用模式下，需要将header每一层调用的过程中，传递下来。
Why do you want to add this feature? 在全链路灰度的模式下，如果用户需要支持按请求来进行路由，则针对从网关到微服务的每一层，都需要将用于路由的header原样透传下来，使得后面的服务也可以使用这个标签来进行路由匹配计算。 类似下面的金丝雀发布的应用场景三：
https://github.com/polarismesh/polaris/issues/631
How to implement this feature? 用户可以在pod中，增加一个环境变量，指定需要透传的标签，SCT识别到这个标签后，就进行传递
Additional context Add any other context or screenshots about the feature request here.
为什么我觉得这像是已有的功能呢？在元数据路由中，可以给流量染色，其中静态染色时，可以定义哪些实例标签作为请求标签透传到链路上，比如SCT_METADATA_CONTENT_TRANSITIVE=IDC,ENV就能将key为IDC和ENV的标签透传。
可能没真正明白您的意思，还请再解释解释。
为什么我觉得这像是已有的功能呢？在元数据路由中，可以给流量染色，其中静态染色时，可以定义哪些实例标签作为请求标签透传到链路上，比如
SCT_METADATA_CONTENT_TRANSITIVE=IDC,ENV就能将key为IDC和ENV的标签透传。 可能没真正明白您的意思，还请再解释解释。
比如说有个请求的头部包含 x-uid=100，使用者想将这个头部往下游传递，并且保持头部为 x-uid，而不是 SCT_METADATA_CONTENT_TRANSITIVE=x-uid0 的方式。
为什么我觉得这像是已有的功能呢？在元数据路由中，可以给流量染色，其中静态染色时，可以定义哪些实例标签作为请求标签透传到链路上，比如
SCT_METADATA_CONTENT_TRANSITIVE=IDC,ENV就能将key为IDC和ENV的标签透传。 可能没真正明白您的意思，还请再解释解释。比如说有个请求的头部包含
x-uid=100，使用者想将这个头部往下游传递，并且保持头部为x-uid，而不是SCT_METADATA_CONTENT_TRANSITIVE=x-uid0的方式。
那作者@andrewshan提出的实现方式“用户可以在pod中，增加一个环境变量，指定需要透传的标签，SCT识别到这个标签后，就进行传递”，应该怎么理解？就是因为这个，我才觉得像SCT_METADATA_CONTENT_TRANSITIVE=x-uid0。
为什么我觉得这像是已有的功能呢？在元数据路由中，可以给流量染色，其中静态染色时，可以定义哪些实例标签作为请求标签透传到链路上，比如
SCT_METADATA_CONTENT_TRANSITIVE=IDC,ENV就能将key为IDC和ENV的标签透传。 可能没真正明白您的意思，还请再解释解释。比如说有个请求的头部包含
x-uid=100，使用者想将这个头部往下游传递，并且保持头部为x-uid，而不是SCT_METADATA_CONTENT_TRANSITIVE=x-uid0的方式。那作者@andrewshan提出的实现方式“用户可以在pod中，增加一个环境变量，指定需要透传的标签，SCT识别到这个标签后，就进行传递”，应该怎么理解？就是因为这个，我才觉得像
SCT_METADATA_CONTENT_TRANSITIVE=x-uid0。
主要思想应该是不想带有 SCT 开头的标签，而是用更通用的方式，以兼容其他语言和框架。
是的，提这个issue的初衷主要是，当前SCT透传的时候，是会带上透传的前缀的，比如如果我需要透传消息头env=xxxx，那么实际上在service-to-service的调用中，env是放在消息头中，以x-polaris-metadata-env=xxx的方式来透传，在下游拿到的并非原来的消息头报文。
实际使用场景中，还需要一种原报文的透传方式，比如我设置需要透传消息头env=xxx，那么可能我只需要设置一个环境变量：SCT_PROTOCOL_CONTENT_TRANSITIVE_HEADER=env，那么在服务调用中，直接在消息头里面透传的数据就是原文的消息头：env=xxx，不会带上前缀。
阿里MSE也支持这种方式：可以在入口应用A处（最好是所有的入口应用都增加该环境变量，包括基线环境和灰度环境） 增加一个环境变量：alicloud.service.header=x-user-id，其中x-user-id是需要透传的Header，它的作用是识别该Header并做自动透传。
个人理解属于一个通用的需求
如约定设置请求标签透传的环境变量为SCT_PROTOCOL_CONTENT_TRANSITIVE_HEADER，
服务接收到请求时，在DecodeTransferMetadataServletFilter#doFilterInternal(HttpServletRequest, , )逻辑中，根据MetadataContext中SCT_PROTOCOL_CONTENT_TRANSITIVE_HEADER的值列表，解析出HttpServletRequest中的对应的headers，以新的外层key如trans-header将其保存到MetadataContext双层Map结构的fragmentContexts集合中。
服务远程调用下游服务时，
Feign：在EncodeTransferMedataFeignInterceptor#apply(RequestTemplate)中，从MetadataContext.fragmentContexts的trans-header中取出需要传递给下游的头信息，设置到RequestTemplate的header中。
RestTemplate：在EncodeTransferMedataRestTemplateInterceptor#intercept(HttpRequest, , )中，从MetadataContext.fragmentContexts的trans-header中取出需要传递给下游的头信息，设置到HttpRequest的header中。
该思路正确吗？
如约定设置请求标签透传的环境变量为
SCT_PROTOCOL_CONTENT_TRANSITIVE_HEADER，服务接收到请求时，在
DecodeTransferMetadataServletFilter#doFilterInternal(HttpServletRequest, , )逻辑中，根据MetadataContext中SCT_PROTOCOL_CONTENT_TRANSITIVE_HEADER的值列表，解析出HttpServletRequest中的对应的headers，以新的外层key如trans-header将其保存到MetadataContext双层Map结构的fragmentContexts集合中。服务远程调用下游服务时， Feign：在
EncodeTransferMedataFeignInterceptor#apply(RequestTemplate)中，从MetadataContext.fragmentContexts的trans-header中取出需要传递给下游的头信息，设置到RequestTemplate的header中。 RestTemplate：在EncodeTransferMedataRestTemplateInterceptor#intercept(HttpRequest, , )中，从MetadataContext.fragmentContexts的trans-header中取出需要传递给下游的头信息，设置到HttpRequest的header中。该思路正确吗？
可以的👏