1、快手服务治理平台 KESS的设计理念和实战快手服务架构和服务化背景服务治理方案选型痛点分析和设计理念应用现状和未来的计划快手，记录世界 记录你80亿条海量视频1.5亿日活独特用户体验解决十亿级“长尾”视频的高效分发极简的前端入口复杂的后台逻辑AI 技术快手背后的技术挑战“爆款”视频“长尾”视频数亿用户多样性内容的分发 v.s.有趣的用户体验Kuaishou ServiceTranscoderBlob StoreUpload APILVSMMUAdAuditAPIRecoPassportMessage FEMessage SrvMCUMedia ServiceUpstream APIVideo

2、CDNStreaming CDN视频播放页面请求、视频上传等直播上行直播下行私信快手服务架构简化示意服务化面临的挑战不断增长的服务规模整体服务质量保证跨地区的业务开发快速扩张的工程师队伍服务发现和配置管理容错容灾和监控支持多地多数据中心保证开发效率和质量服务治理快手服务架构和服务化背景服务治理方案选型痛点分析和设计理念应用现状和未来的计划服务治理基本需求1相对完善的基础平台和组件：2支持多语言：Java,C+,Node.js,Python3高可用，高可伸缩性4支持混合云，尽量兼容原有基础设施配置中心服务发现和路由管理服务质量监控服务开发框架核心痛点1服务治理平台自身的可用性2跨数据中心的路由管

3、理3有状态服务管理4复杂服务调用网络的监控方案选型大量的业内实践经验可供参考与实际需求存在差距，改造成本可能很高基于开源方案二次开发优点缺点可供参考的信息少，容易走弯路可以充分基于实际需求设计方案，可控性强自研方案优点缺点服务治理需求复杂多样，方案也不好简单归类，这里仅为方便介绍，不宜作为严谨参考常见服务治理方案简单基于分布式协调系统Zookeeper,Etcd服务发现和配置管理中心Consul,Nacos集成服务治理的单语言 RPC 框架Spring Cloud,Dubbo集成服务治理的多语言 RPC 框架Tars容器化平台Kubernetes,Istio开源方案不能很好地满足基本需求在一些

4、核心痛点上，开源方案的改造成本过高需要能够快速迭代，跟上业务增长的步伐自研快手服务架构和服务化背景服务治理方案选型痛点分析和设计理念应用现状和未来的计划痛点一：服务治理平台自身的可用性多数据中心架构数据同步和缓存服务治理平台决定了业务可用性的天花板预防各种天灾和人祸Zookeeper 的局限性Division(Central)IDC1(Secondary)Division(KR)BridgeKESSIDC2(Primary)KESSIDC3(Secondary)KESSDivision(IN)KESSMandatorAgentSDKDistributeWriteReportStorage多地多

5、数据中心拓扑Secondary IDCWriteZKMandatorAgentFS/SHMApplicationZKMandatorAgentFS/SHMApplicationPrimary IDC配置分发高可用设计配置数据同步协议 最小同步单元:ConfigDir 修改原子可见 满足 BASEZK 的使用 高可用小数据量 KV 存储 由上层处理多 IDC 数据同步 既推又拉：不依赖于通知机制核心模块去单点 主从热备Report aliveSync route tablesDump raw data write route tables Merge raw data 服务发现高可用设计Remo

6、te ZKLocal ZKConfiguratorApplicationMandator默认就近访问但是也有例外：IDC AIDC AIDC B100%0%就近访问IDC AIDC AIDC B50%50%流量调度痛点二：跨数据中心的路由管理 机器资源不均衡 流量预估不足 突发下游故障主调服务被调服务主调服务被调服务痛点三：有状态服务管理特定领域的有状态服务开发需求消息服务、推荐、多媒体数据分析等业务服务无状态离不开底层的分布式存储随着业务规模扩大，有定制化需求典型案例：有状态服务Crux：多地多活长连接会话缓存服务 持久化，异步写入，入库延迟 10ms，1000万+QPS（读/写）支撑主AP

7、P消息服务：1亿+用户，同时在线 1000万+Connection ManagerS1S2S3Session ManagerL1L2L3S4CruxS1S2S3S4有状态：TCP连接有状态：用户会话无状态：业务逻辑状态管理和路由预分片自动平衡状态迁移数据分片主从多副本平滑扩缩容失效备援多数据中心每个分片的每个副本都有 4 种状态KESS 向业务进程发送状态迁移指令，业务响应事件即可状态迁移：扩缩容及失效备援OfflineSyncSlaveMaster痛点四：复杂服务网络的监控RPC Monitor服务依赖复杂，谁调了我，我又调了谁？单机指标可参考性差，我的服务质量究竟怎么样？出了故障，怎么快速

8、定位？上游大量超时，谁在拖后腿？下游服务容量告急，是因为没有及时扩容吗？实时可用性多维分析调用链分析RPC Monitor 核心功能Micro ServicesLBA1B1C1API1C2D1C4D2API2D3A2A3B2B3API3C3快速故障定位核心指标 QPS、延迟、成功率核心维度 方法、返回值、实例、机房快手服务架构和服务化背景服务治理方案选型痛点分析和设计理念应用现状和未来的计划KESS 平台整体架构回顾SchedulerConfiguratorReplicatorDiscoveryRoute managementDegradeAPIApplication FrameworkGRP

9、CHTTP RedisKConfVersionPolicyRPC MonitorMetric AggregationAlert IntelligenceCall Chain AnalysisService MeshEnvoyPerf logGrafanaFalconCache应用现状1000+微服务10000+服务器（物理机/虚拟机）4 国家/地区分布在 10+数据中心/云机房平台可用性 99.997%跨机房调度次数 100+/月RM 报警数 100+/日50%+故障通过RM发现并定位未来的计划1支持更多编程语言2探索与 Service Mesh 的更好的结合3进一步屏蔽业务对多数据中心的感知