今⽇日头条架构演进之路夏绪宏@今⽇日头条!个⼈人介绍• 夏绪宏@reeze• Tags:• PHPGroupCommitter• Web架构、私有云、性能优化• 编程语⾔言⾼高压下的架构演进• 压⼒力来⾃自哪⾥里?• 服务稳定性• 迭代速速• 服务质量⾼高压下的架构演进• 服务器提了个问题...• 上线把服务搞挂了• 运营活动,量太⼤大服务崩溃了• 单机性能顶不住了• ⼀一个⼩小服务把核⼼心服务搞挂了• cache不稳定把数据库搞挂了• etc…⾼高压下的架构演进• There’salwayspressure• There’snoend• 业务驱动⼒力,没有业务就没有压⼒力关于今⽇日头条• 创⽴立于2012年3⽉月• 5亿⽤用户• 4800WDAU• 65+分钟⽇日使⽤用时⻓长⼤大纲01.!头条架构发展简史02.!关于微服务架构03.!头条服务化的现在及未来头条架构发展简史01.!关于架构• 没有完美的架构• 量变-质变:不同的阶段不同的架构• 架构需要改造的迹象?持续的出现各种问题,事故等。• 架构改造的周期⽐比较漫⻓长• 不可避免的会劣化从前...• 故事都是这么开始的• V1• 三层架构• 业务简单• 快速迭代• ItJustwork.然后...• 业务拆分• 拆分部署,隔离• 代码复⽤用问题...• 业务增⻓长⽐比预期快:每次预算都不⾜足• 新业务不停增加:包袱变重• 代码和数据耦合严重,变更困难• ⼈人员增⻓长快:协作效率问题新时代• 微服务架构• 服务拆分• ⼦子系统划分• RPC统⼀一• etc…新时代关于微服务架构02.!规模&复杂度规模&复杂度• 规模越来越⼤大,问题越来越复杂• 使⽤用抽象管理复杂度• 分治法(divedandconquer)微服务App!Monolithic!client!App!service!service!service!service!Microservices!client!service!service!微服务• ownprocess:进程解耦!• lightweight:易于管理和理解!• builtaroundbusinesscapabilities:⾃自包含!• independentlydeployable:部署解耦!• automateddeploymentmachinery:⾃自动化!解耦!轻量!易管理!现实中的微服务• 架构只是⼀一种模式• 服务关键概念是⾃自治• 但是哪些⾃自治也要有界限• 独⽴立但⼜又要协作:复⽤用基础设施、规范等等现实中的微服务• 怎么落地?Itdepends.• 具象的东⻄西:• 开发框架• 流程、规范• ⼯工具、平台头条服务化的现在及未来03.!服务化思路• ⽴立规范:部署,交互的收敛统⼀一• 打基础:基础库,开发框架,⼯工具• 渐进:逐步拆分,逐步替换• 服务化:⼀一切都是服务• 平台化:⾃自动化、流程化服务化的落地规范!框架!平台!规范:⼀一切都(应该)是服务• 资源是有限的:按需使⽤用,需申请和授权• 简单的使⽤用⽅方式:开发者只需专注业务• 有简单唯⼀一的定位⽅方式:全局资源定位• 可靠、简单,有Owner• 规范.exe规范:我们的规范• 服务统⼀一注册到consul中• 服务有唯⼀一的标⽰示、命名范:{产品线}.{⼦子系统}.{模块}P.S.M• 业务服务使⽤用Thrift描述接⼝口、必须传递标准参数• RPC使⽤用统⼀一收敛的库• Nginx、Redis、MC、MySQL、etc都是服务服务注册App!name!loader!• 统⼀一使⽤用loaderwrapper脚本启动具体启动由业务决定• App:监听⼀一个或多个端⼝口的服务• 轻规范,易迁移服务中⼼心:服务信息服务类型Instances其他元信息toutiao.user.info!thrift!10,4,129.10:8080!10,4,129.11:8080!…!owner\docs..etc!redis.toutiao.userinfo!redis!10,4,129.10:8080!10,4,129.11:8080!…!nginx.toutiao.lb!nginx!10,4,129.10:8080!10,4,129.11:8080!…!服务中⼼心:服务关系点:微服务!线:服务授权!服务中⼼心:授权关系服务接⼝口授权访问的服务其他元信息toutiao.user.info!GetUserInfo!toutiao.stream.stream!!max_qps\etc…!toutiao.user.home!max_qps\etc…!nginx.toutiao.lb!*!toutiao.article.article!服务授权认证思路• 基于服务标⽰示,重要服务增加更多认证⽅方式• 协同认证:客户端⾃自⾝身协助认证⽰示例:ThriftClient!服务中⼼心!ThriftServerA!1.是否可以调⽤用服务?!2.发送请求!caller:P.S.M!logid:xx!etc…!业务字段!标准字段!3.请求是否合法?!4.频率是否正常!…!Method!⽰示例:MySQL(WIP)Client!服务中⼼心!Proxy!1.是否可以调⽤用服务?!2.发送请求!/*caller=P.S.Mlogid=123*/select*!3.请求是否合法?!4.频率是否正常!…!MySQL!⽰示例:RedisClient!服务中⼼心!Redis!1.是否可以调⽤用服务?!2.发送请求!服务拓扑App!A!B!C!X!Y!Z!DB!Redis!存储!服务!⼊入⼝口!服务拓扑App!A!B!C!X!Y!Z!DB!Redis!存储!服务!⼊入⼝口!服务拓扑• 服务依赖和被依赖关系全局元信息• 服务变更影响范围评估• 报警的优化• 不会过时的架构图RPC开发框架• 快速开发:代码⽣生成• 服务发现:理解服务化• 可观测性(Observability):logid,pprof,admin端⼝口• 容灾降级:业务降级开关• 过载保护:断路器,频率控制• 多语⾔言⽀支持:Python/GoRPC开发框架微服务和容器化• 完美的组合• 只是跑在容器内远远不够• 设计和实现我们『有态度』的私有云服务• 理解我们服务化的规范和理念定规范!构建RPC框架!基础库规范化!服务规范化!服务发现!部署平台构建!部分业务拆库!部分微服务化!容灾⽀支持!问题定位服务构建!更多服务重构!私有云平台构建!2016!2015!2016-06!打基础!服务平台!服务迁移!∞服务化历程PaaS⼀一体化平台⼲⼴广告还是要的00.!We’rehiring• 云计算• 性能优化• 存储系统• 数据挖掘• xiaxuhong@bytedance.comThanks