时隔好久，终于开始写技术思考了。
这个问题，听起来好像很简单，A调用了B，我们加个日志或者加些trace追踪上下游就搞定了。
OK，那trace里面需要什么信息可以明确谁调用了谁?
首先需要考虑，什么信息可以识别一个调用者的身份。
IP port可不可以?这个在以前是可以的，因为IP port不容易变更。包括很多网络协议也是这样的，靠四元组去描述调用与被调用方。但是在云原生环境下，会有IP复用问题，如果你靠IP port去鉴别你对象，那你会有云对象。
我们目前大部分架构都是SOA架构，或者称为微服务。IP，port不行，服务名称serviceID行不行?
这个目前肯定是不行的。因为现在服务和IP port强关联。IP port都不行，服务也是不行的。第二个问题是，现在中间件太多，一个服务看起来是一个服务，但是在这个服务下面，一堆agent辅助进程，侵入式SDK不知道在搞什么小九九。如果追踪，那SDK干的事情能不能算服务头上，agent干的事情能不能算这个服务头上?
我作为鸡架搞中间件的，如果可以。那我就偷乐了。瞎搞，搞完锅都是服务负责人的。
OK，总结一下。身份信息至少不能是IP:port，也不能是服务serviceID。
那调用方身份信息，应该是什么?我认为是需要一个ID来标明某一个进程，或者说是容器。这个是很自然的事情，因为现在云原生下，进程是最小粒度的服务节点。
然后，pod下所有的中间件，应该都以sidecar的形式。一个pod会包含n个服务，包括业务的服务和许多中间件服务。
为什么要这么做?
回到我们谁调用了谁这个问题?回答这个问题，究竟想解决什么东西。一个是能快速找到维护该服务的人。如果按IPport去找上下游，找错人了会很尴尬。一个是安全问题，不该调用的，不要用。
明确容器信息是身份证之后，还有个问题就是鉴权怎么做?token是静态的还是动态的?
如果是静态的，一直不变的，那token信息肯定存在泄露的风险。如果是动态的，那token服务必须考虑高并发高吞吐。这个权衡好需求和工具，该上推拉流上推拉流，该上缓存上缓存。高并发高吞吐问题已经是八股文问题了。
为什么要思考这个问题呢？因为有两个有意思的事情。公司内一般会有报警机制，某个服务有问题，就提醒服务负责人修复。然后呢？告警接收人和应该处理问题的人不是同一个，因为我们不容易正确找到。
另一个事情呢，就是更普遍的问题。基础架构的客服同学和开源软件非常不一样的地方是。开源软件随你用，用坏了用户自己承担代价。基础客服是，用户随便用，用坏了客服承担代价。所以大家必须知道，究竟是谁在用，好推动用户正确使用。我就在做这种事情，结果就是找了一堆业务，因为这些问题，没几个是真正的用户，全是误判。
全部评论
(0) 回帖