点击“技术领导力”关注∆ 每天早上8:30推送
今日头条架构师，夏绪宏在技术大会上分享了头条的架构演进，老K结合大型互联网系统架构实践经验进行分析、整理。
作者，夏绪宏。今日头条架构师，专注对高性能大规模 Web 架构，云计算、性能优化、编程语言理论等方向，PHP committer，HHVM 项目贡献者。2015 年加入今日头条负责基础设施，系统架构设计和优化，解决大流量高并发下的系统性能、可靠性和运维效率等方面的问题。
01
业务高速发展下的架构演进
今日头条作为国民级资讯阅读App，2019年用户规模超6.5亿人，日活1.2亿+，视频播放量占头条整体65%+，头条号文章发布量超1.6亿，视频发布量超1.5亿。
今日头条系统，在稳定性可用性方面压力比较大，一方面需要快速把业务实现，但在另外一方面，类似这些高可用的问题会经常骚扰工程师：上线就挂、运营活动量大服务崩溃、单机性能顶不住、一个小服务上线把核心服务搞挂了……类似这些问题，技术团队需要如何更好的去应对？
架构演进，在不同阶段的公司都会面临各种压力。小公司压力可能是业务没起来，QPS 很低，要做优化也没有环境及条件。当公司大了，服务器可能已经不是问题，但你要不断考虑调优及应对访问压力，改善基础设施以提供更稳定的开发环境。所以说架构演进是持续一个过程，没有终点。
02
今日头条架构发展的三个阶段
第一阶段：传统的三层架构、单体架构
今日头条刚开始做的时候，就是一个简单 Web 应用，搭个数据库，把业务实现就行了。头条最开始的优势是推荐引擎，还有另外一套数据挖掘和离线计算。在线的服务在前端相对来讲模式还是比较清晰的，三层就搞定了。业务刚开始起来的时候，没什么问题，访问增大水平扩展一下就可以解决。
(本文所有图片版权归原作者)
第二阶段：系统拆分、打散
跟大多数的架构演进历史非常类似，系统遇到性能瓶颈后，最简单就做一些拆分。优化的过程中，就是把压力较大的子系统就从代码上进行拆分，分成多个可独立部署、无状态化的服务。
这个阶段可以把SSO、用户中心、文章中心、视频、评论等拆分出来，每个业务中心都可以集群部署，达到加机器就可以解决性能问题的效果。
随着业务的快速发展，代码和架构上的包袱是比较沉重，改造的成本比较高。基于这些问题，就要开始演进到下一个阶段，微服务。
第三阶段，微服务，中台化架构
通过拆分成子系统，大的应用拆成小应用，抽象通用层做代码复用。重点在基础设施，希望通过基础设施提高快速迭代、容灾和一系列的工作，希望各个业务团队能更快做业务上的迭代以及架构上的调整。
（微服务架构）
（微服务架构）
微服务最关键的三点：
1、解耦，一个服务会依赖另外一个服务、模块或子服务的概念。
2、轻量，减轻维护人员的成本。
3、易管理。
03
头条的服务化架构建设思路
立规范。包括部署RPC规范、服务调用规范、服务治理原则、超时重试机制等等，否则规模大了之后就会是个灾难。
打基础。有了规范以后，开始真正落地的服务。比如说基础库，把Ngnix、Redis、MySQL这些库封装起来，统一起来做一些开发框架，做业务系统开发的时候，就不用关注数据层的细节，专心实现业务逻辑。
渐进。先拆离再迭代，逐步把服务优化起来。
一切都是服务。第四点是和其他公司或团队稍不一样的地方，我们的想法是一切都是服务，每个节点都是抽象归属于某一个具体的服务。存储的确是一个服务，但它不只是提供 API 或者提供功能的东西，还需要包括服务质量，需要别人用起来是比较简单的。
平台化。最后的落地是平台化的东西。我们框架是怎么设计，和服务怎么结合？
一切都是服务：
资源是有限的：按需申请，需申请和授权；
简单的使用方式：开发者只需要关注业务；
有唯一定位的方式：用全局资源定位；
核心规范：
必须要有全局的中心，服务统一注册到 consul 中；
服务有唯一的标示、命名范：{产品线}.{子系统}.{模块} P.S.M，公司有很多部门，我们不希望部门之间沟通起来有差异，所以需要有全局规划去追溯它；
业务服务使用 Thrift 描述接口、必须传递标准参数。如果用弱的描述数据，没有强约束，在客户端的数据可能会出现类型错误；
RPC 使用统一收敛的库；
Nginx、Redis、MC、MySQL、etc 都是服务
服务注册：我们服务统一使用 loader 或 wrapper 脚本启动，具体启动由业务决定。服务启动会有一个全局唯一ID，把 app 注册到服务里面。
服务中心
服务中心有服务信息，会同时带上是什么样的服务，其他人比较简单的调这个服务就 OK 了。这个服务到底提供什么样的服务质量，拥有者可以管理这个信息。Redis去服务，负载均衡，服务一个项目，把服务接上去。
服务关系与授权
服务之间有个关键的概念：服务授权。一般我们起一个服务，通过 IP 就可以连上它了。数据库有用户名认证，也可以对 IP 授权。不过内网很多服务限制比较少，不是所有服务都有授权认证。我们希望把服务之间的关联关系，全局拓扑关系记录下来并且可执行。
04
头条服务拓扑架构图
服务依赖和被依赖的全局关系拓扑图，服务变更影响范围评估，服务治理，监控预警基础，需要经常更新维护。
05
头条RPC开发框架设计思路
建设关键点：
1、快速开发，代码生成
2、服务发现，服务的自动发现、服务注册
3、可观测，logid、pprof、admin端口
4、容灾降级，业务降级开关
5、过载保护，熔断器、调用控制
6、多开发语言异构系统
06
基于容器的云原生微服务
基于容器技术的云原生微服务，将敏捷开发、devops完美融合，服务化理念的落地与业务场景结合， 实现端到端的价值交付。
以上介绍了今日头条架构高可用、微服务、容器化等实践，如果觉得本文对您有帮助，请点在看、分享朋友圈，感谢您的支持！
-END-
想看更多BAT大厂架构实践干货分享？
请关注“技术领导力”公众号
想加入社区，跟100位互联网大咖学习？
添加群助理Emma，注明“加群”
技术领导力社群
大家在看：
好看就点在看！
