转载

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

正文到此结束