单位化架构在字节跳动的落地实践

资料来源：火山引擎-开辟者社区
什么是单位化
单位化的焦点理念是将业务按照某种维度划分成一个个单位， 抱负情况下每个单位内部都是完玉成部业务操纵的自包含聚集，能独立处理业务流程，各个单位均有其中一部分数据，全部单位的数据组合起来是完整的数据（各企业实际落地过程中会结合实际业务和基建情况做一些折中）。 流量按照某种分区维度（例如流量所属用户）Sharding 到差别的单位，调治上按照流量携带的分区信息进行调治，包管同一时刻该分区的数据写入都在同一个单位，简化版示意图如下：

为什么要做单位化
业界各企业演进到单位化一般主要都是出于下面几个原因：

• 资源限定：单机房受物理资源上限限定，同城多机房受地域的能评和供电等限定，无法做到机房的无限扩展，随着业务规模的扩大，长期肯定会面对多地数据中心的布局；
  
• 合规要求：全球化产品通常会面对差别地域的合规要求（例如欧盟的 GDPR），会有当地用户数据只能存储在当地的要求，业务自然必要思量围绕差别的合规地区构建单位；
  
• 容灾思量：焦点业务有都会级异地容灾需求，通过单位化方式可以构建异地单位，每个单位都有常态真实流量，流量可以灵活地在单位间进行调治。
  

除了上述最关键的题目外，建设单位化还能有其他方面的收益：

• 业务体验提升：通过结合就近调治，可以或许将用户流量调治到迩来的单位，从而低落哀求耗时，提升用户体验；
  
• 成本方面：相比于异地冷备，两地三中心等传统容灾架构，各个单位都能直接承载流量，镌汰资源冗余；
  
• 隔离方面：在最小的单位范围内去做各种技术演进，可以或许有效控制风险半径。
  

异地单位化的主要挑战
机房延迟题目： 一般同城机房之间物理隔断 <200KM，网络延迟和机房内差别不大，大部分业务场景无需过多思量。 但跨城异地机房之间的延迟会大很多，例如北京和 上海之间 RTT P99 达 40 毫秒，此时跨机房哀求耗时必要慎重思量，特别是单个哀求如果出现多次跨机房，增长的哀求耗时可能是几百毫秒以致更大的。
数据同步题目：

• 容灾单位之间的数据必要互通，以支持一个单位故障时可以或许切流到另一个单位进行容灾，因此必要在单位间进行数据同步；
  
• 数据同步必要思量差别的存储引擎（数据库、缓存、消息队列等），差别引擎特性不一，实现成本和复杂度巨大；
  
• 跨城机房间的延迟大而且是弱网环境，网络的质量很难包管，进一步导致数据同步质量包管难度大。
  

流量路由的题目：所谓流量路由也就是如何将流量调治到正确的单位题目，必要思量在哀求链路哪个环节（客户端、流量入口、内网 RPC、存储层等）、根据哀求什么信息（用户 ID、地理位置等）进行用户归属单位的识别，以及如何进行走错单位流量的纠偏。
数据正确性题目：

• 例如归属 单位1 的用户 A 评论了归属 单位2 的用户 B 的抖音短视频，体系在 单位1 给 B 发了一个通知，但 B 查看评论的流量被按 B 的单位归属调治到了 单位2 ，由于数据同步延迟题目，B 打开抖音后看不到评论。业务上必要感知这类同步延迟带来的正确性题目；
  
• 别的两个单位的数据库构建了双向数据同步后，如果同一个用户短时间在两个单位读写同一份数据，可能会出现数据冲突题目。
  

成本题目：

• 每个单位都必要有完整的业务资源以及支撑这些业务资源（计算、存储、网络）的底子设施（运维平台、观测平台等），必要综合思量对成本的影响；
  
• 异地单位化的改造落地涉及到包括基建、架构、业务多方的配合支持，必要思量人力上的成本。
  

管理复杂度题目：随着单位的增长，差别的单位都必要管理对应的服务和基建，管理和运维的复杂性会有较大增长。
字节跳动异地单位化架构
在本文中，我们仅对字节跳动在中国大陆的单位化架构做讨论，现在我们的单位化摆设架构如下图所示：

我们围绕客户端选路、接入层纠偏、计算层纠偏、存储访问层管控四个维度构建了单位化流量调治和管控本领，通过技术本领确保单位化流量调治的正确性（将流量调治到正确的单位）和数据访问的正确性（数据不写脏），具体来说：

• 客户端：在客户端通过调治组件将用户流量从第一跳开始就调治到正确的单位，镌汰在内网的跨单位流量；
  
• 接入层：在网关通过网关的开放本领实现调治插件，按需对客户端调治出错的流量进行路由信息计算和纠偏；
  
• 计算层：计算层通过研发框架和 Mesh 的开放本领实现流量切面，确保对未经过网关的内部 RPC 流量的路由信息计算和纠偏；
  
• 存储层：通过存储访问中间件和 Mesh 的开放本领实现流量切面，确保对存储层路由出错 / 异常单位化流量进行审计和拦截。
  

现在包括抖音、抖音电商、抖音支付、抖音直播、抖音当地生存等业务均启动了异地单位化改造落地，生产环境已接入数千个焦点微服务、超过 100 万实例。
单位化架构落地的关键题目
如何选择单位的维度
单位维度的选择很洪流平上决定了单位化架构的水平扩展本领、运维成本和容灾方式，必要结合业务推进单位化架构想要办理的焦点题目（资源、合规、容灾）和业务特性来选型。业界实践大部分是围绕物理维度（例如 Region、机房）构建单位，也有少部分是逻辑维度的。
结合我们面对的业务特性：

• 同时有包括社交、电商、当地生存、直播、支付等多种类型的业务，差别业务在单位化架构上有差别思量；
  
• 存在大量中台，各中台同时支持差别类型的业务，这些中台必要适配好差别上游业务的单位化流量和数据；
  
• 业务之间有比力复杂的依靠，例如电商和当地生存有从抖音入口进来的流量，也有本身独立入口的流量。
  

综合思量，我们认为字节跳动的单位应该是物理维度的，单位的建设随着基建的规划和建设去演进，而不是业务自行构建，这种物理意义上的唯一调治依据可以或许包管差别的业务长期演进中可以或许在一个单位内闭环，制止调治杂乱。
同时思量我们现在最焦点要办理的题目是资源和容灾题目，因此我们最终选择是 Region 维度构建单位，形成当前的 同城容灾+异地多活 容灾架构。
如何选择分区维度
分区维度决定了数据和流量在单位间的划分标准，选择分区维度的时间必要重点思量：

• 每个分区对应的数据相互不能重叠，以包管同一时刻同一个分区维度的数据写只在一个单位；
  
• 分区的粒度必要能支撑流量调治的灵活性要求，确保流量能按预期分布到各个单位；
  
• 路由信息的计算必要充足轻量；
  
• 确保单位内调用逻辑尽可能闭环，制止产生跨单位调用。
  

一般 ToC 类业务最常见的就是以用户作为分区维度，我们现在大部分业务选择用户（UserID）作为分区维度（抖音、电商等业务），少部分选择 Region 维度（搜索等业务）。
如何进行流量的单位化调治
管理分区和单位的映射
分区和单位的映射也就是对于一个哀求我们找到它应该调治到哪个单位的依据，必要综合业务上对管理成本和灵活性的要求来思量，我们通过以下两种方式结合来管理：

• 映射表：通过 UserID -> Set 的映射表管理，面向 QA 测试、高代价用户群灰度等明白指定归属单位场景；
  
• 表达式：通过流量分片的方式，按比例将流量在单位间分配，以支持比力低的管理和计算成本，例如 0 <= Hash(UserID) % 100000 < 70000 -> Set1、70000 <= Hash(UserID) % 100000 < 100000 -> Set2 。
  

计算路由信息和纠偏
路由信息的计算逻辑一般不复杂，更关键的是决定必要在哪些环节计算以及怎么纠偏（把走错单位的流量调治到正确单位），一般来说，整个哀求链路包括客户端、接入层、计算层和存储层四层，必要结合公司基建情况和业务要求来决定落地方式，以下是我们对于各层实现纠偏本领的须要性和实现方式上的思考和建议。
客户端：

• 须要性分析：在客户端直接计算流量归属单位并调治，可以镌汰在内网出现跨单位访问的情况，镌汰跨单位导致的耗时影响；
  
• 实现方式：可以在客户端集成调治组件来实现，具体调治逻辑必要结合单位的维度来设计，例如最简单可以差别单位对应差别域名，按 UserID 映射到对应域名。
  

接入层（负载均衡、网关）：

• 须要性分析：客户端由于改造依靠用户升级、同时网络环境复杂导致设置变更时生效时间无法包管，因此存在无法 100% 包管流量调治正确的情况，必要在接入层兜底计算路由信息并对走错单位的流量进行纠偏；
  
• 实现方式：在流量入口，结合 LB / 网关的开放本领，实现路由信息的计算和流量纠偏本领。
  

计算层：

• 须要性分析：实际业务上，存在很多内部的 RPC 流量，例如消息队列的 Consumer 发起哀求、后台定时任务发起的哀求等，这种流量不经过接入层，必要在计算层 RPC 接口兜底进行路由信息计算并对走错单位的流量进行纠偏；
  
• 实现方式：可以结合研发框架大概 Service Mesh 的开放本领实现。
  

存储层：

• 须要性分析：业务上会存在例如一个用户去读写另一个用户的数据（例如社交场景的点赞、评论）这类不经过 RPC 接口调治的场景，必要在存储访问的时间兜底计算路由信息并对走错单位的流量进行纠偏；
  
• 实现方式：一般可以结合存储访问中间件大概 ServiceMesh 开放本领实现。实际落地的时间，思量到存储访问层实现纠偏成本和风险偏高（例如毗连数风险），实际业务落地上可以思量只做拦截，推动业务进行改造。
  

一个比力完整的分层示例：

如何适配复杂的业务调治场景
抱负的单位化架构是全部服务都能在单位内闭环，不出现跨单位的流量，但是在实际业务场景下很难满意抱负的单位化架构。以电阛阓景为例，如果用买家作为分区维度，那商家的数据必然会被多单位读写，因此肯定存在部分服务的流量不能单位化调治的情况，单位化架构必要能做好适配。和业界基本思路类似，我们对服务类型做了区分：

• 当地服务/LocalService：单位化拆分后可以或许当地闭环读写的业务服务，比如在电阛阓景的买家业务相关服务。业务的大部分微服务应当都是 LocalService 类似，否则倾向于摆设单 vRegion 摆设；
  
• 中心服务/CentralService：无法进行单位化拆分的业务，固定在某个单位摆设，通常是一些对于数据一致性要求非常高的服务，例如电商的商家、商品库存等服务。
  

服务类型决定了流量调治方式和服务访问的数据的同步方式。基于此，研发焦点必要关注业务上服务类型的界说即可，其他包括数据同步管理、流量调治的细节都可以由框架/平台内部收敛办理，极大低落业务上的明白和管理复杂度：

实际业务落地过程中，以致会出现同一个服务差别接口的访问行为不一致的情况，必要细化到接口维度区分类型，和服务类型类似设计即可，这里不赘述。
如何进行多单位数据管理
单位间数据同步
单位化架构下的数据同步有两种场景：

• 中心服务访问的数据在单位间单向同步，支持延迟敏感且接受肯定水平数据不一致的业务场景当地只读；
  
• 当地服务访问的数据在容灾单位间的双向同步，支持一个单位出现故障的时间可以或许将流量切到容灾单位进行容灾，数据同步必要思量好防回环和唯一 Key 冲突处理。
  

数据同步一致性比对
数据对账一般是全增结合，实时增量比对确保 Diff 发现的实时性，但写入 TPS 高时会有误差，周期全量比对兜底包管团体一致率，常见的一致性比对流程如下：

设计增量数据一致性比对本领的时间，必要重点思量对热键的检测和处理，部分热键一直在 Update 的话必要能识别出来，否则会导致持续有不一致误报警，一个简单的基于重试比对的实现如下：

如何包管数据多活的正确性
日常态：异常单位化流量的识别和拦截
以 UserID 作为单位化分区维度的话，在实际业务场景可能出现两种异常情况：

• 从哀求里面无法解析到正常的 UserID 大概未接入流量调治组件导致未正常计算路由信息；
  
• 一个用户的流量在代码逻辑层直接访问数据库，写了另一个非归属本单位的用户的数据。
  

这两种情况我们都认为是异常单位化流量，在存储访问层通过管控中间件支持了识别和拦截本领，兜底保障数据不被写脏：

切流态：制止数据同步延迟导致脏写
在做单位间切流的时间，由于下面两个题目，可能导致数据出现脏写：

• 跨城异地单位之间的数据同步延迟一般接近或到达秒级，用户流量从一个单位切换到另一个单位的时间可能由于数据还未同步完成从而出现脏写；
  
• 单位间切流本质上是分区和单位映射设置的变革和重新下发的过程，在大规模分布式架构下，这份设置必要下发到多个独立的实例上去生效，这些差别的实例生效时间无法完全一致，就导致同一个用户的流量短时间可能进入差别单位从而导致数据脏写。
  

我们对切流过程引入 两阶段设置变更+存储访问禁写 来办理上述数据脏写题目，团体切流流程如下：

得益于我们团体单位化调治和存储访问中间件设计，我们的禁写是 UserID 维度的，可以或许控制到每次切流仅禁写切流中的用户，将切流的影响做的尽可能小。
如何确保切流的可靠性和风险控制
优化设置下发时效
结合前面关于切流期间通过 两阶段设置变更+存储访问禁写 来制止数据出现脏写的阐明，可以看到设置下发生效的时间对于禁写时长是一个非常大的影响因素，而禁写生效时长直接影响切流那部分用户的使用体验，因此我们必要尽可能提升设置下发时效。
现在字节接入单位化的 Pod 数已超过 100万，在这么大规模的实例数下快速下发调治设置的挑战是非常大的，我们通过 长毗连主动推送+定时轮询拉取 的方式进行设置分发，提高设置收敛速率，镌汰设置不一致中间态的时间：

防止路由死循环
设置发布过程中，同一个 PSM 差别单位实例的生效时间不一样，可能导致流量纠偏到目标单位后由于目标单位重新计算纠偏回来，出现路由死循环的情况。我们通过单位化调治组件在流量上下文中记录并通报纠偏次数，拦截重复纠偏的流量，及时阻断回环流量：

切流过程业务架构各层状态查抄

• 多实例设置生效版本观测查抄：每次设置发布会分配一个递增的版本号，数据面组件通过长毗连上报 Pod 当前设置版本号给设置中心，从而支持单位化控制面查询和观测设置收敛情况：
  

• 数据同步延迟观测查抄：由于我们的切流禁写是用户维度的，不是整个数据库禁写，禁写过程中数据库并不是完全没有新的写流量，因此我们是根据 数据实时的同步延迟+禁写等候时间 结合来判断切流范围的用户禁写后的数据是否已经同步：
  

• 业务焦点指标观测查抄：切流过程中对业务乐成率、负载、延迟等指标的观测。
  

如何包管跨地域 RPC 质量
单位之间通常物理隔断较远，网络专线建设难度大成本高，网络质量（延迟、丢包、可用带宽）也差于同城机房间。前面先容的各种单位路由纠偏都会产生跨单位 RPC，相比单位内 RPC 其乐成率/耗时指标有所劣化。为了提升跨单位 RPC 质量，除了网络专线本身的稳定性建设（属于网络基建范畴，此处不展开），也可以在架构设计和带宽使用策略上进行针对性的优化。
跨单位 RPC 通道收敛：在单位化流量路由场景，某个流量很大的 RPC 服务可能仅小比例命中跨单位纠偏，此时由于卑鄙实例数量很多可能导致毗连复用效果较差。此时如果让全部跨单位 RPC 先同一经过当地界限网关，然后传输到其他单位的界限网关，最后再转发给实际卑鄙，则建连过程拆分成了 3 段，中间段（网关之间）被全部跨单位 RPC 共用，可以保持较高的链接复用率; 别的 2 段为当地建连，即使毗连复用率低，带来的耗时增长也较少。此外收敛到网关通道也更轻易会合对跨单位 RPC 进行其他优化，比如按接口等级进行 QoS 管控、在专线完全故障情况下对重要的控制信令做加密后 Fallback 到公网传输等：

跨单位网络分级 QoS 管控：长隔断专线建设成本高，带宽有限，也更轻易因为各类异常导致可用带宽变少，无法满意全部场景的跨单位网络传输的需求，因此必要对差别类型的跨单位流量进行分级 QoS 管控。跨机房 RPC 失败要么直接影响用户体验，要么导致故障无法操纵止损，应在跨单位网络传输中给予更高的优先级; 离线数据传输轻易短时间大量占用带宽，异常对用户感知相对不明显，应给以较低优先级，严格限定上限，须要时还应让出带宽：

未来演进思考
多单位研发成本和效率优化
字节跳动从原本的单 Region 内同城容灾架构演进到多 Region 异地单位化架构周期比力短（一年半左右），底子设施对多 Region 视角的支持还比力不足，对业务的团体研发和业务管理成本偏高，必要将多 Region 的研发和业务管理成本打平到单 Region。
极致的成本优化
从计算资源成本视角：在原来三机房同城容灾模式下，每个机房必要预留 50% 的 Buffer 用于机房故障容灾，演进到异地单位化架构后，基于两个容灾单位间的六个机房，部分业务机房故障可以将流量分摊到其他五个机房，此时各机房仅需 20% 的 Buffer。
从存储资源成本视角：我们现在是 同城容灾+异地多活 的容灾模式，各单位都支持同城容灾，因此部分业务可以直接进行数据的单位化拆分，单位内各自只有一部分数据（加起来是全量数据），抱负情况下存储成本镌汰一半。
更复杂的单位化架构演进
未来字节跳动在国内会有更多的地区，差别业务在各单位的排布模型会越来越复杂，结合我们复杂的业务依靠关系，这里的流量调治模型、数据单位化和同步模型都必要演进。
未来地区增多后，业务随着发展机房排布会调解，可能会必要在非容灾单位之间调解流量，此时存在数据单位化拆分和用户维度数据单位间搬迁本领，必要办理用户维度数据的识别和低成本搬迁题目。
更完善的数据多活本领
字节跳动现在的存储对 AP 场景更友好（偏重抖音这种社交类场景），主要围绕单 Region 构建，在多单位场景下对于电商、支付类（对数据一致要求非常高）的业务支持较弱，在异地单位化架构下强依靠数据同步本领来支持多单位数据多活本领，业务上的限定偏大（例如写只能同一在一个单位），有跨 Region 强一致数据库的需求。

免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。