服务网格GPRC协议多种编程语言实践.5.GPRC协议Headers网格实践-阿里云开发者社区

开发者社区> 六翁> 正文

服务网格GPRC协议多种编程语言实践.5.GPRC协议Headers网格实践

简介: 在服务网格的流量管理和可观测性实现上,Headers发挥着非常关键的作用。相比而言,HTTP协议的Headers实现较为容易,因为HTTP是同步阻塞式的请求响应模式,可以很容易在GET/POST/UPDATE/DELETE方法中定义和使用读写Header的API。GPRC协议的Headers则要复杂一些,各种编程语言在4种不同通信模型中,读写Header的形式的差异化很大,同时还要考虑流式和异步的
+关注继续查看

在服务网格的流量管理和可观测性实现上,Headers发挥着非常关键的作用。相比而言,HTTP协议的Headers实现较为容易,因为HTTP是同步阻塞式的请求响应模式,可以很容易在GET/POST/UPDATE/DELETE方法中定义和使用读写Header的API。GPRC协议的Headers则要复杂一些,各种编程语言在4种不同通信模型中,读写Header的形式的差异化很大,同时还要考虑流式和异步的编程实现。

本篇首先介绍4种编程语言的Headers编程实践,然后讲述在服务网格实践中,GPRC协议Headers的两个重要实践:流量管理和可观测性。

1 GPRC协议Headers编程实践

服务端获取Headers

GRPC通信模型编程语言 Java Go NodeJs Python
基本方法 实现拦截器ServerInterceptor接口的interceptCall(ServerCall<ReqT, RespT> call,final Metadata m,ServerCallHandler<ReqT, RespT> h)方法,通过String v = m.get(k)获取header信息,get方法入参类型为Metadata.Key<String> metadata.FromIncomingContext(ctx)(md MD, ok bool)MD是一个map[string][]string call.metadata.getMap(),返回值类型是[key: string]: MetadataValueMetadataValue类型定义为`string Buffer` context.invocation_metadata(),返回值类型为2-tuple数组,2-tuple的形式为('k','v'),使用m.key, m.value遍历获取键值对
Unary RPC 对Headers无感知 在方法中直接调用metadata.FromIncomingContext(ctx),上下文参数ctx来自Talk的入参 在方法内直接调用call.metadata.getMap() 在方法内直接调用context.invocation_metadata()
Server streaming RPC 同上 在方法中直接调用metadata.FromIncomingContext(ctx),上下文参数ctx从TalkOneAnswerMore的入参stream中获取:stream.Context() 同上 同上
Client streaming RPC 同上 在方法中直接调用metadata.FromIncomingContext(ctx),上下文参数ctx从TalkMoreAnswerOne的入参stream中获取:stream.Context() 同上 同上
Bidirectional streaming RPC 同上 在方法中直接调用metadata.FromIncomingContext(ctx),上下文参数ctx从TalkBidirectional的入参stream中获取:stream.Context() 同上 同上

客户端发送Headers

GRPC通信模型编程语言 Java Go NodeJs Python
基本方法 实现拦截器ClientInterceptor接口的interceptCall(MethodDescriptor<ReqT, RespT> m, CallOptions o, Channel c)方法,实现返回值类型ClientCall<ReqT, RespT>start((Listener<RespT> l, Metadata h))方法,通过h.put(k, v)填充header信息,put方法入参k的类型为Metadata.Key<String>v的类型为String metadata.AppendToOutgoingContext(ctx,kv ...) context.Context metadata=call.metadata.getMap()
metadata.add(key, headers[key])
metadata_dict = {}
变量填充metadata_dict[c.key] = c.value
最终转为list tuple类型list(metadata_dict.items())
Unary RPC 对Headers无感知 在方法中直接调用metadata.AppendToOutgoingContext(ctx,kv) 在方法内直接使用基本方法 在方法内直接使用基本方法
Server streaming RPC 同上 同上 同上 同上
Client streaming RPC 同上 同上 同上 同上
Bidirectional streaming RPC 同上 同上 同上 同上

Propaganda Headers

由于链路追踪需要将上游传递过来的链路元数据透传给下游,以形成同一条请求链路的完整信息,我们需要将服务端获取的Headers信息中,和链路追踪相关的Headers透传给向下游发起请求的客户端。这就是"Propaganda Headers"的概念。

如上表格所示,除了Java语言的实现,其他语言的通信模型方法都对header有感知,因此可以将"服务端读取-传递-客户端发送"这三个动作顺序地在4种通信模型方法内部实现。

Java语言读取和写入Headers是通过两个拦截器分别实现的,因此Propaganda Headers无法在一个顺序的流程里实现,且考虑到并发因素,以及只有读取拦截器知道链路追踪的唯一ID,我们无法通过最直觉的缓存方式搭建两个拦截器的桥梁。

那么只能借助上下文了。幸好Java语言的实现提供了一种Metadata-Context Propagation的机制。

propagation.png

在服务器拦截器读取阶段,通过ctx.withValue(key, metadata)将Metadata/Header存入Context,其中keyContext.Key<String>类型。然后在客户端拦截器中,通过key.get()将Metadata从Context读出,get方法默认使用Context.current()上下文,这就保证了一次请求的Headers读取和写入使用的是同一个上下文。

有了Propaganda Headers的实现,基于GRPC的链路追踪就有了机制上的保证。

2 网格拓扑

完成GRPC的Headers处理后,我们进入部署和验证目录tracing。该目录下包含4种编程语言的部署脚本。我们以go版本为例,执行如下脚本进行部署和验证。

cd go
# 部署
sh apply.sh
# 验证
sh test.sh

部署后的服务网格拓扑如下图所示。

grpc-tracing-topology.png

3 流量转移

在VirtualService中通过定义Header键值的匹配条件,可以实现根据请求动态地进行流量转移。如果再结合前一篇中讲述的按API切流、按版本切流的实践,就可以完成应用级的精细化流量管理

进入服务网格(ASM)实例,新建VirtualService,将如下内容复制保存。这个VirtualService定义了Header中server-version=go的请求100%流量路由到go版本服务。

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  namespace: grpc-best
  name: grpc-server-vs
spec:
  hosts:
    - "*"
  gateways:
    - grpc-gateway
  http:
    - match:
      - headers:
          server-version:
            exact: go
      route:
        - destination:
            host: grpc-server-svc
            subset: v2
          weight: 100

4 链路追踪

进入服务网格(ASM)实例,在功能设置中勾选启用链路追踪,采样方式选择阿里云XTrace。

在本地执行如下请求脚本,向Ingressgateway发起多次请求。

USER_CONFIG=~/shop_config/ack_bj
alias k="kubectl --kubeconfig $USER_CONFIG"
INGRESS_IP=$(k -n istio-system get service istio-ingressgateway -o jsonpath='{.status.loadBalancer.ingress[0].ip}')

docker run -d --name grpc_client_node -e GRPC_SERVER="${INGRESS_IP}" registry.cn-beijing.aliyuncs.com/asm_repo/grpc_client_node:1.0.0 /bin/sleep 3650d
client_node_container=$(docker ps -q)

echo "Test in a loop:"
for i in {1..100}; do
  docker exec -e GRPC_SERVER="${INGRESS_IP}" -it "$client_node_container" node mesh_client.js ${INGRESS_IP} 6666
done

在服务网格(ASM)实例的左侧菜单中点击"链路追踪",查看请求链路信息。如下图所示,完整的链路包括:本地请求端-Ingressgateway-grpc-server-svc1-grpc-server-svc2-grpc-server-svc3

tracing_app_topology.png

tracing_app_waterfall.png

tracing_app_waterfall0.png

版权声明:本文内容由阿里云实名注册用户自发贡献,版权归原作者所有,阿里云开发者社区不拥有其著作权,亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容,填写侵权投诉表单进行举报,一经查实,本社区将立刻删除涉嫌侵权内容。

相关文章
阿里云服务器怎么设置密码?怎么停机?怎么重启服务器?
如果在创建实例时没有设置密码,或者密码丢失,您可以在控制台上重新设置实例的登录密码。本文仅描述如何在 ECS 管理控制台上修改实例登录密码。
4068 0
Http协议中的Header与Body
Http协议中的Header与Body Header的每行最后要加\r\n Header与Body之间要用\r\n隔开 Body后无需加\r\n ACSII码中 '\n' 10 换行 '\r' 13 回车 也可以表示为'\x0a'和'\x0d'.(16进制) 示例:HTTP开始部分为header,部分为body。
972 0
vscode插件快餐教程(4) - 语言服务器协议lsp
在有lsp之前,存在三个主要问题: 一是语言相关的扩展都是用该语言母语写的,不容易集成到插件中去。毕竟现在大量的语言都带有运行时。 二是语言扫描相关的工作都比较占用CPU资源,运行在vscode内部不如放在独立进程,甚至远程服务器上更好。
2788 0
Swift 面向协议编程入门
本文讲的是Swift 面向协议编程入门,这个教程也是为了那些不知道类和结构体根本区别的人写的。我们都知道在结构体里是没有继承的,但是为什么没有呢?
959 0
阿里云服务器端口号设置
阿里云服务器初级使用者可能面临的问题之一. 使用tomcat或者其他服务器软件设置端口号后,比如 一些不是默认的, mysql的 3306, mssql的1433,有时候打不开网页, 原因是没有在ecs安全组去设置这个端口号. 解决: 点击ecs下网络和安全下的安全组 在弹出的安全组中,如果没有就新建安全组,然后点击配置规则 最后如上图点击添加...或快速创建.   have fun!  将编程看作是一门艺术,而不单单是个技术。
4479 0
《UNIX网络编程 卷1:套接字联网API(第3版)》——2.13 常见因特网应用的协议使用
接下来5个是基于UDP的网络应用,然后是7个TCP网络应用和4个同时使用UDP和TCP的网络应用,最后5个是IP电话网络应用,它们或者独自使用SCTP,或者选用UDP、TCP或SCTP。
1082 0
Dubbo 在跨语言和协议穿透性方向上的探索:支持 HTTP/2 gRPC 和 Protobuf
本文整理自刘军在 Dubbo 成都 meetup 上分享的《Dubbo 在多语言和协议穿透性方向上的探索》。 本文总体上可分为基础产品简介、Dubbo 对 gRPC (HTTP/2) 和 Protobuf 的支持及示例演示三部分,在简介部分介绍了 Dubbo、HTTP/2、gRPC、Protobuf 的基本概念和特点;第二部分介绍了 Dubbo 为何要支持 gRPC (HTTP/2) 和 P
605 0
+关注
六翁
阿里云容器服务&middot;六翁
98
文章
0
问答
文章排行榜
最热
最新
相关电子书
更多
文娱运维技术
立即下载
《SaaS模式云原生数据仓库应用场景实践》
立即下载
《看见新力量:二》电子书
立即下载