长在云原生架构上的小红书

采访嘉宾 | 张雷、高飞

“内容社区”已经成为小红书最被外界认可的“标签”，而作为一家互联网公司，支撑起社区运营、有着很多员工的技术团队更是不可被忽视的存在。小红书的技术团队又细分为后端基础架构、SRE、大数据、AI 算法、端技术、音视频技术和安全技术等团队。其中业务技术团队直接承接业务需求，帮助业务快速奔跑；中台技术团队则侧重更基础和长远的技术研发，并将新技术融合进业务当中。

正是小红书技术团队的多年努力，造就了当前小红书“土生土长”的云原生架构和更为先进的多样化内容分发算法。本文，InfoQ 专访了小红书技术负责人张雷和系统架构负责人高飞，揭开小红书技术团队的神秘面纱。（本文节选自《中国顶尖技术团队访谈录》2021年第四季）

长在云原生架构上

小红书的云原生架构历史可以追溯到这个公司成立之前。

2013 年，Pivotal 公司的 Matt Stine 正式提出了云原生的概念，云原生开始大规模出现在公众视野，市场上也有了可用的 IaaS 产品。同年 6 月，小红书在上海成立。成立之初的小红书在搭建系统架构时便选择了同样刚刚发展起来的云原生，这也成为了小红书架构与众不同的地方。

“创业之初，选择云其实是很自然的事情。”小红书技术负责人张雷说道。

从成本角度考虑，起步阶段自建 IDC 太重。自建机房、自己管理及其高昂的运维成本，这些对于刚刚成立的企业来说是很大的负担，而云可以帮助企业省去这些费用。从业务角度看，虽然当时小红书并未上线电商业务，但电商却是计划中必定要做的事情。电商业务的特点之一就是对系统的弹性要求很高。对一家创业公司来说，为了满足促销活动带来的临时性资源需求而购买机器是不合理的，云却可以很好地解决这个问题。

如今，小红书的基础技术部会承担很多云原生技术的研发，这个部门包含中间件、存储、缓存、DB、SRE 和质量保障等不同团队。土生土长在云上的架构让小红书拥有很好的先发优势，也使得团队在对新技术的采用上少了很多后顾之忧。

经过 8 年不断地发展和升级，小红书整体架构的容器化率已经达到 80%，架构整体迭代效率大幅提高。

云原生架构带来的不止是自身迭代速度的提高，对于小红书这样对算法要求较高的企业来说，其算法模型从实验到上线的速度也得到了极大提升。

首先，得益于云原生架构，任何基于容器化的技术都可以实现硬件资源隔离。算法的模型训练和线上服务大量采用容器化技术后，研发人员可以不用太关心开发环境问题，而是更专注在算法迭代上。

其次，合理的架构与硬件的有机结合可以释放更多算力。随着 GPU、分布式计算架构等利用率的提高，算力也得到极大提高。这些算力无论在训练阶段还是线上服务阶段都可以提供更大的发挥空间。

最后，实时流式数据能够更好地支持算法的时效性。之前传统架构上的算法模型的更新时效性要以“天”为单位，但小红书基于流式数据，通过使用 Kafka 和 Flink，算法模型的更新时效性达到了“分钟”级别。

自研多样化内容分发算法

作为一个多元化的生活方式分享平台，如何做好内容分发是小红书技术团队面临的重要考验。

通常情况下，内容分发流程是这样的：用户上传内容，之后平台做内容理解，理解后做内容审核，审核合格的内容进入内容分发系统，分发系统进行推荐、搜索等操作，这些内容会得到曝光并被用户看见，用户再与这些内容产生交互，如点赞、分享或者评论等。系统通过捕捉到的交互行为，对用户喜好进行分析，之后再优化其内容分发策略。张雷表示，小红书与其他公司不同的地方在于，小红书在每个步骤上都更加重视多样化内容的曝光。

在张雷团队看来，生活方式有成千上万种，但与商品不同，生活方式不会存在“爆款”。因此，小红书拥抱多样化的内容分发是顺理成章的事情。“如果只对头部内容进行分发，那么曝光量多的内容会得到更多的曝光，而用户能感知到的多样性内容就会变少。中长尾内容的多样化分发对于生活方式平台是非常关键的。”

但是，整个过程中存在两个主要的技术难点：

第一，对于中长尾内容的表示和相似性度量。中长尾内容跟头部内容相比，用户交互数据更稀疏。纯基于内容（CB, Content Based）的相似性度量依赖大量标注数据且不一定能反映用户感知的相似性。而稀疏的用户交互数据使得基于协同过滤（CF, Collaborative Filtering）的相似性度量方法也不太准确。

第二，如何去从技术上捕捉和表示用户对内容多样性的感知。之前经典的 DPP 方法是一个基于内容集合的方法，对内容出现的顺序不敏感。但是在 App 实际使用过程中，不同的内容出现顺序会很大程度上影响用户对多样性的感知。

针对上述问题，小红书采用了自己研发的滑动谱分解（SSD, Sliding Spectrum Decomposition）模型，该方法可以捕捉用户在浏览长项目序列时对多样性的感知。与其他多元化推荐方式相比，SSD 将内容序列视为用户观察到的时间序列，在整个序列中组合多个滑动窗口，以此对齐用户在浏览时的感知。

SSD 模型中多窗口堆叠的内容张量

针对中长尾内容相似性度量的问题，小红书研发并采用了通过内容学习行为的方法：CB2CF （Content Based to Collaborative Filtering）。

ECB2CF 模式

CB2CF 通过神经网络，从内容本身出发去学习用户协同过滤的交互数据，并依此判断是否内容相似性。模型输入上仅使用内容，这样即使对于新内容和中长尾内容也能依赖模型的泛化能力得到较好的结果。模型目标上学习全体用户的协同过滤的结果，使得模型能够在统计上学习用户感知的相似性。

通过线上 A/B 测试，与 SOTA 的 DPP 模型相比，小红书 SSD 和 CB2CF 模型下的用户浏览时长提高 0.42%、互动率提高 0.81%，而 ILAD（用户浏览笔记之间的平均距离，即曝光多样性）提升 0.32%，MRT（用户平均阅读类目数，即消费多样性）提升了 0.68%。

在张雷看来，多样化内容分发从长远角度考虑会是一种趋势，但是否采用多样化内容分发还要取决于企业具体的业务形态。有的业务需要打造爆款，有的需要多元化，不同的产品和业务对内容分发方式的偏好是不同的。

去年 2 月，小红书美食类消费 DAU 一度超过美妆，成为小红书社区第一大垂直品类。在内容运营和多元化内容分发机制的共同作用下，其他中长尾内容数量也迅速增长。公开数据显示，教育类同比增长 400%，科技数码类同比增长 500%，体育赛事同比增长 1140%，运动健身增长 300%。过去一年，小红书用户全年笔记总体发布量同比增长超 150%。同时，截至 2020 年 6 月，小红书月活跃用户数已经过亿。

向多云架构转型

随着业务规模的不断增长，小红书已经开启了从单云架构到多云架构的转型之路。

当前小红书对整体架构的目标有三点：第一，架构可以很好地支撑业务快速发展带来的规模的持续扩张，比如能够稳定支撑亿级 DAU 的规模；第二，能够做到较高的可靠性和可用性，这主要表现在跨地域容灾能力和跨云基础设施的容灾设计等方面；第三，架构必须是高效率的，这包括相对低廉的成本和较高的资源利用率。

这三个目标也是小红书做多云架构转型的动力。小红书架构负责人高飞表示，多云可以更加灵活地支撑更大的业务规模。不同的云技术特点不同，小红书可以根据不同云厂商的特点部署不一样的技术，如离线和在线的混布等。另外，多云对资源的冗余要求也更低一些，在容灾上有一定的效率优势。

“先进的架构和理念可以帮助一个起步较晚的企业实现弯道超车。”张雷表示。

据高飞透露，现在小红书团队基本用两个月的时间就可以完成搜索、推荐等核心业务在另外一个云上的验证，同时小红书很多机器学习模型已经至少在四家云上进行训练。

当然，一旦拥抱多云架构，很多技术挑战也会接踵而至。

首先，多云架构需要统一的资源管理。多云上的资源管理需要做到像单云一样容易管理，否则很难统筹调配。其次，如何保证不同云之间数据的及时同步和一致性也是问题，尤其那些对数据一致性要求较高的业务对此要求更加急迫。最后，多云架构怎么做好稳定性、高可用，做好不同云之间的流量调度也是一个挑战。此外，小红书还有自己的要求：让自己的技术栈做到云独立，即不绑定在特定的云上，业务无论部署在哪朵云上都可以跑得通。

面对这些技术挑战，除了利用现有的开源技术外，小红书也会进行自主研发。

针对资源管理问题，小红书联合华为、工商银行和中国一汽开发了 Karmada 开源项目。Karmada 是一个 Kubernetes 管理系统，可跨多个 Kubernetes 群集和云来运行云原生应用程序，而无需更改应用程序。对于数据一致性问题，小红书会在数据存储和缓存层基于分布式一致性协议，结合不同的业务场景，进行自主架构设计和研发。

为加强多云架构稳定性，小红书使用混沌技术定期进行故障演练，保证一个机房出现故障时可以快速切换到其他机房，同时对不是特别重要的服务进行降级处理。而对于云独立问题，由于要摆脱对单个云厂商的依赖，一些 PaaS 能力必须自研。小红书的 KV 存储、控制面，甚至整个微服务架构都是自研。

管理层面，小红书由各个专业方向的架构师们组成了技术专业委员会，根据不同技术领域制定相应的技术规划和规范，以此来提高迭代效率并保证产品质量。

对于未来，小红书的目标很清晰：随着业务的增长，多云架构必将登上舞台。真诚的、令人向往的、多元化的内容规划一直没变，更注重 UGC 中长尾内容分发的策略也没变。技术团队的主要任务就是努力完成这些目标。

“一切都在进行中。”张雷说。

迷你书推荐

中国顶尖技术团队访谈录（2021 年第四季）开放下载

本期《中国顶尖技术团队访谈录》精选了腾讯科恩、金蝶、海尔集团 IT、小红书、网易、阿里等技术团队在技术落地、团队建设方面的实践经验及心得体会。InfoQ 希望通过这样的记录，向外界传递顶尖技术团队的做事方法/技术实践，让开发者了解他们的知识积累、技术演进、产品锤炼与团队文化等，并从中获得有价值的见解。

如果你身处传统企业经历了完整的数字化转型过程或者正在互联网公司进行创新技术的研发，并希望 InfoQ 可以关注并采访你所在的技术团队，可以添加微信：caifangfang842852，请注明来意及公司名称。