程序员最大的幸福是看到自己的代码跑在千万人的设备上，程序员最大的不幸是去维护千万人设备背后的老代码。腾讯新闻，是一个有着十多年历史、海量用户规模的经典业务，其背后的系统走过了门户时代，走到了推荐算法时代。
随着时间的推演，老旧架构面临着那些经典的问题：可用性差，服务不稳定；扩展性差，开发周期长，迭代效率低；200 多个代码仓库，300 多万行代码，编程语言、协议混用……
叠加上推荐算法的时代命题，如何对腾讯新闻的推荐架构做升级成了业务进一步发展的内在要求。本文从业务场景介绍入手，详细介绍了腾讯新闻推荐架构升级过程中的目标设定，架构设计和实践过程，值得仔细品阅，转发点赞收藏一键三连。01
前言我们先来简单回顾下腾讯新闻的发展历程，腾讯新闻源于03年成立的门户网站腾讯网，成立之初，抓住了中国互联网崛起的东风，位列四大门户（搜狐、新浪、网易）之一；2010年伴随着智能手机的普及，也抓住了移动互联网普及的浪潮，第一批推出了腾讯新闻的客户端，经过了一系列交互和内容的创新，于2014年移动端的用户数更是达到了峰值的 DAU2.5亿，位列资讯类 APP 第一位，一度也达到了应用总榜的第一，这是截止到当时唯一触达榜首的资讯类 APP，由于这些傲人的成绩，腾讯新闻在2015年强势拿到了腾讯集团的“名品堂”，该奖项授予那些曾经影响到腾讯集团发展历程的里程碑式的应用，应该算是腾讯新闻最高光的时刻，时至今日腾讯深圳总部大楼上高悬的还是腾讯新闻的 logo：02
腾讯新闻业务介绍2.1 发展阶段谈到腾讯新闻的业务，我的理解里面大致将他划分为三个阶段：第一个阶段：我把它称之为以类目为索引的橱窗式内容陈列阶段，这也是所有门户网站的内容组织形式，就像一个大的“内容超市”，你会看到各类内容，按照一个大的分类体系（按照颗粒度不同少则几十大则几百上千）来组织内容然后呈现给用户：03
新闻推荐架构升级的背景在展开架构升级的过程之前，我们先来思考两个核心的问题：1、当我们的产品处于一个高频、多变的迭代之中的时候，我们如何才能保持我们系统架构的生命力？04
新闻推荐架构升级的目标和演进路线4.1 目标有了前面的铺垫，我们可以用一句话，来概括我们架构升级的目标：在保证业务逻辑独立性的前提下，实现架构的复用，提升系统架构的健壮性（保证用户体验）、可扩展性（提升迭代效率）、可运维性（降低维护成本）。这里面有个非常核心的前提，“保证业务逻辑的独立性”，为什么这个前提很重要，因为我们从历史经验来看，很多公司技术路线演进过程中，是牺牲掉了部分业务逻辑独立性换来的。比如，早些年业界提出了“大中台，小前台”的中台架构理念，但是随着时间推演，业务蓬勃发展下，业务逻辑独立性的诉求逐步增加，中台逐步成为了限制业务独立发展的枷锁，这也就不难理解最近，业界又开始拆中台的风潮了。于我个人而言，我不反对建设一个技术中台，但是这里面有个很重要的原则，就是我们要来定义什么样的组件适合成为一个中台，以及业务和中台的关系如何界定。譬如说：数据资产管理、容器平台、机器学习平台这些作为中台，基本是可以达成共识的。但是长在这些公共组件之上的推荐引擎部分，能不能拿了作为中台，很多公司在这些方面有不同的看法，我个人认为要结合业务的发展阶段来看。如果一个业务早期，需要快速验证业务模型，快速试错，当然接入一个统一的引擎中台，无疑是最快速、成本最低的做法；同样业务如果处于生命周期的中后段，处在一个维稳状态，没有太多的迭代前提下，也比较适合中台这种集中式托管的方式。但是如果这个业务正处在一个快速发展的上升期、以及平台期亟需寻找第二增长曲线的阶段的时候，捆绑在中台，无疑对于业务的迭代效率就会产生制约。这个阶段中台的角色作为一个孵化器往往是比较合适的，给业务提供一些基础的组件，同时类似开源社区的方式，允许业务自己维护自己的代码版本。4.2 路径有了上面的认识之后，我们如何来推进我们的架构升级？我们先要做什么，后要做什么？这里面我想提一个可能在推荐系统架构设计里面不太常被人提及的概念”领域驱动设计（Domain-Driven Design, DDD）”。领域驱动设计（Domain-Driven Design，简称 DDD）是一种软件开发方法论，它专注于创建一个以业务领域为核心的软件模型。DDD 由 Eric Evans 在2004年提出，其核心思想是通过领域模型来定义业务和应用边界，确保业务模型与代码模型的一致性。DDD 的目标是帮助开发人员更好地理解和建模业务领域，将业务领域的知识和逻辑融入到软件设计中，从而提高软件的质量和可维护性。为什么这里要提这个概念，因为我们在实际工作中发现，很多系统设计是缺乏底层理论支撑的，只是为了解决单点的问题。这样随着业务迭代，日积月累，必然导致积重难返。我们架构设计首先需要理解底层的业务逻辑，这跟 DDD 的理念不谋而合，因为 DDD 的第一步就是领域建模。领域模型是 DDD 的核心，它描述了业务领域中的概念、实体、关系和业务流程。通过领域模型，我们可以将业务领域的知识转化为计算机可理解的语言，实现业务逻辑与技术实现的统一。所以我们系统重构的首要问题，是面向数据要素建模。数据基础决定上层架构，历史债务治理，首要进行数据治理，数据收敛带动架构统一推荐系统里面最核心的数据要素是什么：用户、内容、特征、策略。05
架构升级的关键路径平台建设为了实现整个底层数据模型的统一，我们花了接近2年的时间，进行了底层数据平台的建设，并推送了多个场景对底层数据依赖的统一，下面我们找两个有代表性的平台进行一个简单的展开，在建设这些平台过程中遇到的问题以及核心的思考。5.1 索引平台问题与挑战06
系统防劣化原则：制定并且遵循标准、规范和最佳实践，构建防腐层避免新的技术债务的累积。代码规范：大仓的开发模式，统一代码标准：单侧覆盖率大于70%，圈复杂度小于5，代码重复率小于8%。统一协议规范，采用 BG 的 trpc-cpp 协议，替换原有的 brpc、http 等。发布流程规范：所有在线服务发布均接入蓝盾流水线，执行严格的单测、diff 流程。二进制灰度能力建设，建立了金丝雀发布机制，保证端到端的稳定性。策略灰度能力，基于方圆策略平台建设了策略灰度能力，避免错误配置引起全线崩溃。问题排查流程规范:打通伽利略监控到 oncall 平台的通路，自动提单，故障 MTTR<60分钟。针对重点场景建设了监控大盘并制定了相应的问题排查手册。通过企微建立了 slo 长效的跟踪机制，及时发现及时响应。需求开发流程规范：所有的需求开发均接入 Tapd 需求管理平台，通过 Tedi 平台进行迭代效率的监控，及时发现问题，保证迭代效率。建立规范的需求价值衡量机制，避免无效需求对于系统架构的侵蚀。引入技术评审机制，避免垃圾设计对于存量系统的影响。07
总结新闻的架构优化，从21年开始一直持续到现在，系统从不足99%的可用性提升至了99.99%，整体成本下降了60%，取得了一些成果。同时，系统的优化之路又永远都没有终点，因为业务总是在向前的，新的问题不断涌现，我的认知也随着解决问题不断提升，“路漫漫其修远兮，吾将上下而求索”，以此共勉。-End-原创作者｜董道祥参考阅读解密腾讯云ChatBI：智能数据分析的未来
B站稿件生产平台高可用建设分享
视频网站播放全链路压测实践之路
腾讯文档收集表后台重构：改造一个巨石单体！
本文由高可用架构转载。技术原创及架构实践文章，欢迎通过公众号菜单「联系我们」进行投稿
版权声明：除非特别标注，否则均为本站原创文章，转载时请以链接形式注明文章出处。
