Uber在微服务架构中如何利用多租户玩转生产现场测试?

在面向租户的微服务体系结构中,将租户上下文如tenant-id附加到传入请求,并在请求的整个生命周期中传播该上下文,这使用户能够基于该上下文路由请求。当请求调用链中任何服务收到请求时,某些服务可能会评估请求上下文以绕过某些业务逻辑。例如,验证用户电话号码的审核服务可能希望绕过测试流量的检查,因为测试请求中涉及的用户是测试用户。此外,通过交易处理服务运行测试流量时,需要与银行网关进行通信以为用户转移资金,我们可能希望将银行网关存根,或者与银行的登台网关(如果可以进行测试)进行通信,以便防止任何真实的资金转移。

当然,可以使用诸如 OpenTracing
和 Jaeger之
类的开源工具来实现租用上下文传播,但是这些工具可以以某种语言和传输不可知的方式进行分布式上下文传播。

租户上下文如tenant-id还应传播到其他传输中的数据对象,例如 Apache Kafka
消息传递队列中的消息。较新版本的Kafka支持添加标头,并且可以使用开源跟踪工具向消息添加上下文。对于像Kafka这样的消息传递队列系统,我们可以透明地为某个tenant-id推出一个新主题,也可以为tenant-id专门分配一个单独的Kafka集群

通过租户上下文如tenant-id可以隔离数据存储,划分不同数据库,一种是真正生产数据库,另外一种是用于生产测试数据库,或金丝雀阶段的数据库。

每个基础架构组件都可以理解租期并能够基于tenant-id路由隔离流量,从而允许在我们的平台内进行更大的控制以运行不同的微服务,例如度量和日志。微服务架构中使用的典型基础架构组件是日志记录,指标,存储,消息队列缓存配置。根据其tenant-id隔离数据需要分别处理基础结构组件。这有助于开发人员根据tenant-id进行筛选,这可能有助于避免错误警报或防止启发式或训练数据出现偏差。

Uber的多租户实施带来了各种好处,例如使代码自动发布和配置安全,从而提高了开发人员的速度。多租户架构的隔离保证使Uber可以出于各种目的(包括测试流量)重新利用同一微服务堆栈。

banq注:虽然多租户带来灵活方便,但是常在河边走哪有不湿脚?将设计开发测试推迟到生产实施阶段,风险异常放大。

原文 

https://www.jdon.com/53921

本站部分文章源于互联网,本着传播知识、有益学习和研究的目的进行的转载,为网友免费提供。如有著作权人或出版方提出异议,本站将立即删除。如果您对文章转载有任何疑问请告之我们,以便我们及时纠正。

PS:推荐一个微信公众号: askHarries 或者qq群:474807195,里面会分享一些资深架构师录制的视频录像:有Spring,MyBatis,Netty源码分析,高并发、高性能、分布式、微服务架构的原理,JVM性能优化这些成为架构师必备的知识体系。还能领取免费的学习资源,目前受益良多

转载请注明原文出处:Harries Blog™ » Uber在微服务架构中如何利用多租户玩转生产现场测试?

赞 (0)
分享到:更多 ()

评论 0

  • 昵称 (必填)
  • 邮箱 (必填)
  • 网址