多租户微服务架构实践总结
业务驱动与问题背景
字节跳动业务形态多样（今日头条、抖音、西瓜视频等），随着业务发展，早期共享服务模式面临Noisy Neighbor问题、数据合规与隔离需求（如Sandbox、压测环境等泛化租户场景）。微服务架构下，服务域治理复杂，单个服务域包含上千微服务，上下游服务域租户拆分维度可能不同，微服务链路长且包含异步链路，共享服务后期需拆分，数据隔离需支持db/table/row级别。
核心问题与解决方案
本质问题是复杂微服务架构下的流量和数据治理。解决方案包括：
- 流量身份标识：通过TIM（Traffic Identity Mark）票据在网关层注入，全链路透传，支持RPC、MQ、应用层识别，基于ZTI Token身份识别，非对称加签/验签保证可信。
- 计算流量调度：Mesh流量路由策略下发到Mesh Proxy，动态计算目标逻辑集群，支持RPC、AGW、LB路由，域内流量优先闭环，支持亲和性调度和流量逃逸。
- 流量隔离保证：单元内部流量闭环，支持逃逸，单元有优先级，访问下游服务时优先访问高优单元，支持RPC直接指定单元。
- 存储访问管理：存储代号在不同单元指向不同实例，通过存储访问中间件层实现租户请求路由、数据访问管控和在线拆分，适配异构存储。
存储层解决方案
存储访问中间件提供统一治理和管控，通过query hook动态改写请求/响应完成租户数据路由，pre hook拦截未授权跨租户访问，基于身份+访问规则决策。
延伸场景与平台化方案
租户数据拆分需权衡隔离性与成本，平台化解决方案提供一站式租户单元管理（计算/存储/路由规则/数据迁移），关注标准化、效率和可靠性。
解决的问题与收益
解决了服务能力扩展、租户间流量和数据隔离、研发复杂度、运维复杂度等问题，支持平台租户数量增长、单租户流量持续增长、租户间流量隔离、数据隔离（物理/逻辑）、数据访问管控、按单租户模型开发、不同租户版本和变更差异化、垂直隔离环境搭建、共享租户拆分到独享。
业务场景案例
租户/场景流量隔离案例包括多租户隔离（信息流、账号、IM、电商、支付等）和场景化隔离（封板核心链路隔离、电商Sandbox、UG活动链路等）。
投入考虑因素
是否值得做多租户架构需考虑服务复杂度（微服务规模、链路长、存储多）、租户隔离场景（业务服务多租户、隔离诉求、共享拆分独立环境）、垂直隔离链路（压测、活动）、安全合规要求（租户数据隔离技术保证、跨租户数据访问管控）。
多租户机房内租户隔离
需要业务标识，业务透明路由（业务投屏路由、跨单元拦截），租户数据隔离，租户拆分时需不存在租户间容灾，单元化机房间容灾需业务标识，业务透明路由（业务投屏路由、跨单元拦截），容灾机房间同步不需要容灾切流、强一致性场景切流禁写。
单元化与多租户的演进
多租户和单元化面向不同场景，原子能力有很多重合。
Key Takeaways
- 微服务架构下构建面向多租户解决方案需关注流量和数据治理。
- 复杂微服务架构下的流量和数据治理思路。
- 面向多租户的微服务架构的必要性、投入和收益。
- 字节跳动在面向多租户场景的实践。
- 后续业务架构的演进和投入。
