远程上下文设计

[mengqiang81]

目前 ServiceContext 会保留 http 协议 header 中所有以 Service-Context 为前缀的 key, 并一直传递下去, 比如 Service-Context-CallId, Service-Context-App 等. 而其他前缀的 header, 在向后调用时会被忽略掉无法透传.

而 ServiceContext 本身继承了 Hashmap, 所以要获取上下文的话, 可以调用 serviceContext.get('Service-Context-App')这样的方法, 设置和修改也可以使用 put 方法.
但是如果 key 不是已 Service-Context 为前缀的话, 透传就会出问题, 会被忽略掉.

现在的问题是, ServiceContext 的结构设计. 我希望业务方可以灵活的设置和修改某一个 key, 同时对 httpheader 友好.

现在有两种方案,

1. 目前所采用的, 以 key 的前缀为判断依据. {"Service-Context-App":{},"Service-Context-CallId":{}},缺点是业务方需要按约定 get,put
2. 统一用一个 key {"Service-Context":{"callId":{},"app":{}}}, 缺点是 get,put 方法需要特殊去实现, 也不符合 http 协议header 的惯例用法, 优点是对 key 不需要根据 http 协议特殊要求总长度不超就行

我个人倾向第一种

[pootow]

昨天的讨论结果也记录上来呗

2016-07-12 17:14 GMT+08:00 mengqiang81 notifications@github.com:

目前 ServiceContext 会保留 http 协议 header 中所有以 Service-Context 为前缀的 key,
并一直传递下去, 比如 Service-Context-CallId, Service-Context-App 等. 而其他前缀的 header,
在向后调用时会被忽略掉无法透传.

而 ServiceContext 本身继承了 Hashmap, 所以要获取上下文的话, 可以调用
serviceContext.get('Service-Context-App')这样的方法, 设置和修改也可以使用 put 方法.
但是如果 key 不是已 Service-Context 为前缀的话, 透传就会出问题, 会被忽略掉.

现在的问题是, ServiceContext 的结构设计. 我希望业务方可以灵活的设置和修改某一个 key, 同时对 httpheader 友好.

现在有两种方案,

1. 目前所采用的, 以 key 的前缀为判断依据.
   {"Service-Context-App":{},"Service-Context-CallId":{}},缺点是业务方需要按约定 get,put
2. 统一用一个 key {"Service-Context":{"callId":{},"app":{}}}, 缺点是 get,put
   方法需要特殊去实现, 也不符合 http 协议header 的惯例用法, 优点是对 key 不需要根据 http 协议特殊要求总长度不超就行

我个人倾向第一种

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
#2, or mute the thread
https://github.com/notifications/unsubscribe/AAqCZot7OZ6GkLAscoTaidzSOpEKH8uAks5qU1sAgaJpZM4JKMMX
.

[mengqiang81]

对于上下文, 我们分为两种. 上面说的是远程上下文, 需要跟随服务的调用链条一直传递下去. 还有一种是本地上下文, 由框架的使用者自行设置和读取.

比如很多 facade 接口中需要使用登录用户 id, 可以不体现在接口的输入参数中, 而从本地上下文中获取. 通常可以 aop 该服务, 通过该服务的参数和远程上下文中的信息来生成.

本地上下文的生成和使用不是 nofdev-rpc 框架的职责. 但是本地上下文通常会依赖于远程上下文, 所以我们可以提供简化开发的工具.

这就又引发了另外一个需求, 就是 nofdev-rpc 框架的周边工具集.