共计 7503 个字符，预计需要花费 19 分钟才能阅读完成。
背景
QQ 浏览器信息流（QB）举荐架构撑持了 QQ 浏览器、快报主 feeds 场景、浮层等信息流卡片实时举荐的能力，架构上不仅仅要反对多业务、多产品，如 QB、快报、内部单干等，而且须要可能疾速反对各种类型场景的能力，如主 TL、浮层，且可能疾速扩大反对垂直频道和 APP。那么信息流举荐架构须要做到灵便模块化，程度易扩大。
为了做到海量级实时精准举荐，信息流举荐架构划分为了四层：展控层、排序层（精排 / 粗排）、召回层、索引层，并提供实时级用户画像模型打分模块和特色零碎，进行实时的用户 / 物品特色累积，实时反馈给举荐链路进行千万级索引文章 / 视频的筛选和精准举荐。具体的架构模块图如下所示：
能够看到，举荐架构包容的模块之多，反对的业务模式之多，而且须要撑持亿级用户规模和百亿特色规模，那么须要更好的技术架构体系对于如此宏大的架构服务和存储去进行开发、扩大、治理、保护等。
挑战
挑战一：实时性
（1）特色实时更新
（2）模型在线实时学习
挑战二：超大规模
（1）用户量级：亿级用户
（2）特色规模大：百亿特色、千亿参数（无穷）
（3）样本宏大：精排样本每日样本近百 TB
挑战三：高性能
（1）全链路耗时达到业界领先水平。
解决方案
尽管举荐零碎模块性能泛滥，是一个较为宏大零碎，但咱们以微服务的形式对举荐零碎进行拆分。把一个宏大的零碎划分为成千上万个微服务模块，每个微服务只负责绝对独立的性能，并以近程 RPC 的接口方式提供服务，模块之间能够互相调用，从而造成了一个简单的调用关系网，整体上就组成了一个宏大的举荐零碎。微服务化当前，再联合云原生的相干技术架构体系保障云原生利用的稳定性，并晋升资源的利用率和研发效率。
容器化
在云计算 1.0 的时代里，业界通过虚拟化的形式从硬件级拆散应用程序，而容器的呈现，标记着云计算 2.0 时代的到来，这个阶段利用是通过容器化的伎俩从操作系统级别拆散应用程序。
在容器化的时代中，Docker 的呈现使得隔离的开发测试环境和继续集成环境成为宽泛实际，而 K8s 则让容器利用进入了大规模工业生产的期间。集群也可能最大水平地施展施展容器的良好隔离、资源分配与编排治理的能力。容器化后给企业带来的最大价值是人力和机器老本的节约。下图则从稳定性、可扩展性、资源利用率三大维度上比照了虚拟化和容器化的区别。
云原生时代
云原生（Cloud Native）这个概念最早是由 Pivotal 公司的 Matt Stine 提出的。并随着工夫的推移，云原生的概念也一直在更新迭代，云原生架构曾经成为互联网行业的技术热门，国内外各大厂都开始推动公司业务朝着云原生的方向进行演变，并在很大水平上推动了 IT 老本的升高和企业的倒退。
云原生架构体系简介
云原生是一种技术架构体系和方法论，它容纳了容器化、继续交付、DevOps 和微服务等概念。容器化是微服务的最佳载体，继续交付可频繁疾速交付下升高品质危险，DevOps 将公布部署自动化化，微服务则是外围地可被独立部署、更新、scale 和重启。
CNCF 云原生计算基金会，在 CNCF 全景图中列举了和云原生相干的产品及服务的残缺名单，这 1381 个我的项目独特形成了恢弘宏大的云原生世界。整个全景图依照性能分为 29 个模块，别离归属于 9 种大的类别
- 利用定义与开发（App Definition and Development）
- 编排与治理（Orchestration and Management）
- 运行时（Runtime）
- 配置（Provsioning）
- 平台（Platform）
- 可察看性与剖析（Observability and Analysis）
- 无服务（Serverless）
（原图链接：https://docimg7.docs.qq.com/i…）
QB 云原生架构体系
下图为 QB 信息流举荐架构的整体云原生架构体系。DevOps 承载了代码 / 公布 / 构建治理、流水线、主动部署、监控、CI/CD、集成测试等能力，测试平台负责压力测试 / 接口测试 / 集成测试 / 故障剖析演练等职责，微服务框架通过服务发现 / 路由、负载平衡、动静配置等性能提供便捷无效而稳固的服务链路能力，云平台治理的 redis、mysql、mq、flink 等数据存储保护了业务的数据对立平安的治理和备份，容器服务基于集群 / 容器 / 镜像 / 存储管理提供无状态可主动调节和平行扩大的能力，使得机器资源的利用率达到极优，而日常的链路排查和部署保护则通过配置 / 日志治理和监控告警等串联和及时响应。
在技术选型上，QB 信息流举荐架构在编排和治理上抉择了北极星和 trpc 框架，根底配置管理上抉择了 rainbow 平台，服务部署治理平台抉择了 123 平台，染色监控方面抉择了天机阁和 007。
DevOps
QB 信息流举荐架构服务迁徙至 trpc 框架和 123 平台。123 平台是通用的研发和经营的开放式 DevOps 平台，反对插件式扩大定制业务个性需要。通过 123 平台可进行自动化服务部署和运维，正当调配服务容器资源配比充沛晋升资源池利用率，也通过不同服务部署环境（正式 / 测试等）的隔离，可能稳固平安地进行新版本部署和公布。
在 CI/CD 上，选型了蓝盾流水线严格标准了 git 提交的代码格调 / 标准 / 品质 / 提交日志标准等，并通过编译构建和单测用例通过率 / 覆盖率严格保障 MR 分支和默认主线分支代码的可用性和稳定性，同时也通过构建流水线对立标准构建和镜像公布，从而保障在频繁继续交付过程中有较高的服务和代码品质。
可观测性和剖析
宏大的业务技术架构下，因为包容的业务服务模块多且繁冗，链路之长，更不乏业务间单干的场景，故而一旦须要去把控服务链路的稳定性或者是追究问题时，不足可观测性的伎俩的状况下将会变得复杂且费时费力。在可观测性的组件上，咱们抉择的是天机阁。天机阁旨在解决上述的问题和难点：故障定位难、链路梳理难、性能剖析难。它通过 Log、Trace、Metric 三个维度相辅相成地去给予多方位的监控和串联。通过天机阁，咱们可疾速地染色和排查定位链路问题，也能够进行服务的流量剖析和性能剖析。
配置管理
服务配置管理平台须要可能做到的是配置同步、版本治理、权限治理等几个因素。基于上述理由，且 trpc 框架也反对了七彩石插件，故而咱们选型的是七彩石 rainbow 作为服务配置的治理平台。
云原生利用
传统利用 VS 云原生利用概述
传统利用和云原生利用有什么区别？次要体现在几个方面：研发模式、架构设计、部署形式、运维形式。在部署、运维形式上，云原生利用都是自动化的。
传统利用
传统利用个别领有较长的生命周期，并常常被构建成严密耦合的单体式利用。它们合乎定义时制订的的相干标准，然而这些标准制订的工夫通常远早于利用的交付工夫。业务经营所需的很多基础性利用在设计时都未曾思考提供数字化体验。
传统利用的开发计划大部分都属于瀑布式和渐进式，不仅时间跨度长，而且直到近期才实现了半敏捷性。利用历经开发、测试、平安合规监管、部署和治理阶段，这些阶段被分隔成了不同的性能畛域，每个畛域都由不同的团队负责、施展着不同的作用、肩负着不同的职责，且各方间均通过线性流程来沟通。
对于大多数传统利用来说，基础架构会针对利用所需的峰值容量事后进行置备；还会通过纵向扩大来进步服务器的硬件的相干性能。
云原生利用
因为云原生利用十分重视研发与交付的效率，信息流业务对此也有着迫切的需要。因而，在开发时须要施行更加麻利且基于服务和 API 的计划和继续交付策略。开发时从针对服务器的眼光转为以容器为核心的模式。开发计划从繁多严密的利用，转变成涣散耦合的服务模式，更加强调利用间接口的通信。服务交付周期通常变的更短，须要继续地迭代交付。而这些计划是否胜利施行又取决于以下几点：开发和交付团队间的 DevOps 合作；模块化水平更高的架构；可能按需横向扩大、反对多种环境并实现利用可移植性的灵便基础架构。
云原生利用开发范式
既然云原生利用有诸多的益处，那咱们在开发云原生利用须要关注那些点呢？以下会从微服务、名字服务、数据管理、配置管理和日志治理五方面进行介绍。
微服务
微服务架构是以一组小型服务的形式来开发一个独立的利用零碎，每个服务都以一个独立过程的形式运行，每个服务与其余服务应用轻量级通信机制。这些服务是围绕业务性能构建的，能够通过全自动部署机制独立部署，同时服务会应用最小规模的集中管理能力，也能够采纳不同的编程语言和数据库，实现去中心化的服务治理。微服务的关键词：减速交付筹备，高度可扩大，杰出的弹性，易于部署，易于拜访，更加凋谢。
为什么要切换成微服务的架构设计？信息流传统的举荐架构，是以服务器为外围而搭建的。传统架构中，精排、粗排、展控等模块部署在同一物理机，这样就会面临着可能物理机器挂了，导致相干的零碎整个不可用。运维过程针对单机性能有余的状况，只能运维同学手动对单机容量进行调整。微服务强调的是低耦合 + 高内聚个性。通过将信息流业务的切分成一个个残缺、独立的微服务，每个服务能够作为独立组件降级、灰度或复用等，对整个大利用的影响也较小，每个服务能够由专门的组织来独自实现，依赖方只有定好输出和输入口即可齐全开发，甚至整个团队的组织架构也会更精简，因而沟通成本低、效率高。
业务理论在迁微服务过程中，遇到的问题和思维的转变：
- 版本治理以及一份基准代码，多份部署
信息流业务历史存量代码与资源寄存于集中式版本控制 svn 上繁多门路治理，地方服务器没有做备份的状况下，可能呈现数据失落的情景。为了应答之后迁徙微服务和多人合作开发的大势。引入了 git 版本控制工具，进步了并行开发的生产效率。每一个服务共享一份基准代码，然而能够存在多份部署。通常会将服务的不同版本别离部署在 123 平台提供的不同公布环境，以期测试验证和灰度验证的成果。
- 编译、公布零碎
采纳分布式编译系统减速对源码的编译。123 服务经营平台反对各个团队自定义各自的编译、运行镜像，满足各种丰盛的自定义化需要。同时能够记录编译及公布的相干历史，达到随时能够追溯各个历史版本的成果。
- 显式申明依赖关系以及依赖治理
将业务中的单体利用切分成了各个微服务。保护服务间编译的依赖关系，保障服务依赖关系清晰就成了重中之重。业务首先将利用，依照性能与模块划分成粒度更为粗疏的微服务，并且划分到不同 git 仓库治理。在服务松耦合的根底上，引入了模块依赖管理工具，如 bazel、maven、go modules 等。通过先进的生产力工具，结构更为清晰的依赖关系，也解决了历史利用各种协定版本不统一引发的各种问题。
- 过程与并发性
开发、运维同学将思维转化为过程模型来设计利用架构。分配任务给不同的过程类型，如服务中的 Web、Worker 过程。思考将过程设计成无状态，无共享的模式。利用就能够通过复制其过程来扩容。结构无状态利用还让过程可在不同的计算基础架构之间移植。设计思维逐步向分布式聚拢，这样在整个零碎急需程度扩大时，能够增加更多过程解决当务之急。
名字服务
服务发现的概念是随着计算机体系结构的倒退而演变的概念。网络时代初期，不同的计算机须要互相定位，这是通过一个寰球文本文件 HOSTS.TXT 实现的。因为不常常增加新主机，所以手动保护文件的地址列表。随着互联网的倒退，主机的减少速度越来越快，须要一个自动化，可扩展性的更强零碎，从而导致了 DNS 的创造和宽泛采纳。
服务发现个别是由三个模块组成，主控、客户端、服务端，其中服务端会把以后的结点信息注册到主控，当客户端须要调用服务端时，则从主控获取到服务端的结点信息或者从曾经缓存的数据中拿到服务端的信息，而后进行调用，其关系如下图所示：
当初，微服务架构正在推动服务发现的一直倒退。随着容器化平台或云平台的一直遍及，基于平台的微服务架构部署，服务的生命周期以秒和分钟来掂量。同时，因为微服务的主动扩大、故障和公布降级，导致微服务具备动态变化的地址列表，微服务的灵活性再次推动了服务发现技术的倒退。当初基于容器化平台或云平台的微服务应用程序，须要解决服务地址动态变化的问题。腾讯外部也提供了泛滥优良的平台和组件以供选择，如 cl5 / l5 / 北极星（Polaris）等。以下是传统利用和云原生援用在名字服务上的异同：
业务理论在切换名字服务过程中，遇到的问题和思维的转变：
- 端口绑定
在非云环境中，通常将 Web 利用编写为在利用容器中运行。相比之下，云原生利用不依赖于内部利用容器。相同，它们会将 Web 服务器库打包为利用自身的一部分。互联网利用能够通过端口绑定来提供服务并随时监听所有发送至该端口的申请。123 平台上接入的服务，会主动对接北极星名字服务。123 平台中的每一个服务，都会被北极星通过该服务名能够解析出具体的实例（代表一个 ip port 以及相干配置信息）。在服务下线或者变更时，采纳名字服务的形式，往往能缩小很多人力老本。
数据管理
互联网业务也包含信息流业务，因为数据的量级以及对存取速度要求的不同，免不了应用各式各样的存储系统。随着云原生的推广，传统的数据管理形式也在逐渐向云存储转变。以常见的 NoSql 组件 redis，以及关系型数据库 mysql 为例，也经验了单机本地存储，集群存储以及上云的变迁。
绝对于传统数据管理形式，云原生数据管理有以下几个特点：
- 分布式
用户的存储散布在多台机器上，彻底解脱单机容量和资源限度。
- 高可用性
每个实例均提供主从热备，宕机主动监测，主动容灾。
- 高可靠性
数据长久化存储，可提供冷备和自助回档。
- 弹性扩容
集群版存储往往反对单实例无下限扩容。在扩容过程中不中断服务，真正做到用户无感知。
- 欠缺的监控
能提供残缺的经营零碎，次要包含实时流量、个性的监控以及告警。实时监控各项组件指标，针对阈值配置告警。
以下是分布式存储的监控图
配置管理
信息流业务的举荐零碎被划分为成千上万个微服务模块，其中每个服务在 123 经营平台上又被部署到多个环境中。传统文件配置管理的形式，存在着比拟大的局限性，云原生的配置管理系统应运而生。
业务理论在切换配置管理系统过程中，遇到的问题和思维的转变：
- 在环境中存储配置
信息流业务应用七彩石 rainbow 零碎作为配置管理外围零碎。在 123 平台中，七彩石以插件化的模式存在。业务的配置在不同环境下（如预公布、正式环境）还是有差距的，七彩石以及 123 平台能够针对环境做不同隔离，能够满足业务的需要。
- 环境等价
不同环境的配置会存在差别，而利用要想做到继续部署，保证系统稳固，就得做到配置文件间差别尽可能少。从信息流业务本身登程，通过引入 DevOps，缩短部署上线的工夫，做到尽可能由开发的同学来批改配置文件，这样的动作是值得的。
日志治理
传统的日志治理模式，日志以存储在 Web Server 本地文件模式而存在，单机存储日志文件存在单机容量的局限。业务开发及运维同学，须要剖析数据时，往往只能登录到特定机器能力看到特定的日志。不能总览事件触发的链路，及其他相干模块的日志。
在云原生的日志治理流程下，服务的日志应该是事件流的汇总。日志采集零碎将所有运行中过程和后端服务的输入流依照工夫程序收集起来。日志是以流水的模式追加到所属的日志文件后，开发及运维能够实时在终端跟踪规范输入流的状况。再辅以日志采集跟踪组件，即可残缺地追踪事件产生流程相干模块产生的染色日志。信息流业务目前是通过鹰眼日志零碎，来剖析业务生命周期中的各种可能遇到的问题。
业务理论在切换日志零碎过程中，遇到的问题和思维的转变：
- 集中式近程日志核心
- 集中收集，对立治理
- 方便快捷的日志剖析能力
资源利用率优化
业务应用了 Docker、K8s 等技术后，从实践上来说能够无效地晋升资源利用率，但在简单的业务架构下，微服务数量收缩，大部分业务利用还是存在资源利用率低的问题，究其原因次要是工具平台不够欠缺、业务的独有资源应用形式不同，那如何晋升资源的利用率是云原生架构体系的一个重要命题。
资源节约场景
思考到资源节约，首先咱们来剖析下业务中常见的资源应用形式，从这些场景中能够找到一些优化的方向。
索取大于应用
业务利用在理论的应用过程中，存在资源预留大量节约的问题，比方服务理论运行须要 1 核 CPU，服务负责人对利用应用的内存没有估算到位，为了让利用能稳固地运行，服务负责人会申请过多资源，比方 4 核 CPU，防止前面服务在运行的过程中呈现问题。这势必会造成较大的资源节约。如下图所示，CPU 使用率只有 1%-1.5% 左右。
波峰波谷景象
大多数业务存在波峰波谷景象，比方咱们的业务中，中午饭后、早晨睡前的时间段存在一个波峰，这段时间用户有跟多的闲暇工夫来生产信息流。而凌晨工夫用户在劳动，则呈现了波谷。如下图所示，早晨 10-11 点左右呈现了一个波峰。
利用资源应用差别
不同的业务利用在不同的时段应用的资源存在较大的差别，在信息流业务中较为显著，在线业务白天负载较高，对时延也要求较高，而离线计算业务在凌晨负载较高，对时延要求绝对较低。
优化计划
针对以上提到的资源节约场景，咱们能够采纳手动、主动的形式进行资源利用率调优，比方针对索取大于应用的场景能够采纳手动的形式进行调优，把多申请的资源从新依照实在的应用状况进行缩容，但这种操作形式很大水平上依赖开发的能力和志愿，在理论的操作过程中难以落地，所以须要采纳主动的形式进行优化，尽可能少地依赖开发者。主动的形式有以下几种：
- 依据 HPA、CA 等参数弹性伸缩
- 调度，K8s 提供资源分配机制，主动找到适合的节点
- 在线、离线业务混合部署
这些主动的能力在 TKE 上都反对，具体操作能够查阅 TKE 的相干文档。
监控
尽管主动的扩容、缩容能力能无效地调度资源，使得资源的利用率有所晋升，但对于整个业务的资源应用状况还须要有相应的监控，以下是咱们业务局部的监控模块，通过这些监控数据能够疾速找出优化的方向。
- 整体资源详情
- 业务利用扩缩容阈值
- 模块资源利用率排行榜
后记
云原生架构体系是一个宏大的技术体系，在各个技术方向上都有相干钻研或成熟组件，公司也有 Oteam 在相干畛域进行共建，作为业务更多的是须要借助平台、Oteam 的能力进行整合，站在伟人的肩膀上能力飞得更高。最初感激公司在云原生各个技术畛域上做出奉献的团队和集体。
参考文档
云原生利用之路：https://www.sohu.com/a/211846…
12-factors：https://12factor.net/zh_cn/
【腾讯云原生】云说新品、云研新术、云游新活、云赏资讯，扫码关注同名公众号，及时获取更多干货！！
