2018年快手服务治理平台KESS的设计理念和实战.pdf

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：多地多活长连接会话缓存服