搜索推荐整体架构（AI·OS）
ABFS：基础特征服务 iGraph：图引擎 BE/DII：召回引擎 RTP：Rank Service HA3：搜索引擎
AOP：一站式机器学习平台 TPP：灵活业务平台
标准化：从搜索到推荐
TPP: 搜索推荐业务平台
支持算法及业务的快速迭代，让用户真正专注自己的核心逻辑
集团最大业务规模serverless平台：服务集团62+BU，万级别场景
集团最大的JAVA单体应用之一
峰值QPS
阿里在线水位最高的JAVA应用之一
双11百万级QPS，万级别容器
2015201620172018
搜索推荐中台?目标
AI OS
Serverless
图化算子化
新业务创建成本过高 场景/团队爆发式增长 资源调配太难，水位极低 双11挑战巨大
逼出来的Serverless
过万
2011
2013
2014
2015
2016
2017
2018
2019
场景
我的集群
我的集群
我的集群
Serverless 的开始：FAAS
传统应?用
Faas
新业务成本git/aone/应?用分组/vip/服务框
架/业务逻辑
git/业务逻辑
监控ALL ?自建平台提供细粒度多维度监控流量量治理理ALL ?自建平台提供限流/降级/负载均衡/
容灾/切流
资源?手动
全时快速弹性
迭代
?无统?一实验体系/协作成本?高
灵活实验/快速发布/敏?捷协作
专注业务逻辑
关注业务逻辑
剥离业务开发不关心的问题
基于JVM Runtime
面向JAVA高度性能优化
面向在线
百万级低延迟在线服务
快速弹性 全时秒级弹性 快速迭代
快速实验和反馈
产品和体验
一键创建函数和资源就绪 秒级全方位监控
日志分析
监控报警
AI时代永远缺机器
Docker化
更细粒度的隔离：AJDK多租户 高密度部署 代码隔离 资源隔离
双11大促水位50%
热部署：
秒级发布：没有镜像push/pull过程，不再冷启动容器
化解资源之忧：从Docker 到JVM
虚拟化?高密度部署
从同构到异构
同构：
流量稀疏，性能低
隔离性差
调度简单
异构：
流量聚集，性能较优
隔离性强
二层调度：从容器到场景 流量调度：智能负载均衡
混布下的调度
规模：万级别场景
监控：5s级监控反馈 Fiber：10s级扩容
长尾：0->1/1->0能力
智能：多目标弹性
CPU/超时率/降级率/限流率
从运维解脱：全时秒级弹性
算法灵活实验业务逻辑复杂度：
千行到10万行
实验零等待：
AB实验
分层实验
秒级发布
Blink实时效果反馈
GraalVM多语?言：前后端?一体快速迭代Java Runtime is “SideCar”
多语言无缝对接集团Java生态
前后端一体高效研发
团队协作： 工程和算法解耦
信息流多个算法团队的解藕 相比istio/envoy： 基本无性能开销
Java语言生态受众广 丰富的自动降级策略 异构下的流量调度 兜底机制
Service Mesh
：团队协作的利利器?
服务调用只占算法/业务的5%代码 复杂推荐场景代码10w+行
相同逻辑的编码千人千面，交接成本巨大
逢大促全员性能优化
离只关心自己的业务逻辑还有很大距离
Not Only ServerLess
借鉴TensorFlow，PyTorch，Flink设计思路
逻辑层和物理层解耦
同步编程前端语言
零基础编写全异步代码
UDF承接用户业务逻辑
后端全异步执行：高门槛的性能优化下沉平台 AJDK协程
Reactive
业务语义的标准化算子
千人千面的复杂逻辑归一化为高性能平台标准实现 标准化流程模版
真正只扩展自己的业务逻辑
全图化：业务逻辑标准化
同步编程体验 AJDK协程 Reactive
零基础编写全异步化?高性能代码
数据处理理的?高性能抽象
借鉴Blink的优化思路：SQL化
平台优化粒度可以细到Long.parse, String.intern等极致的优化
Faas级协作带来网络/序列化开销 召回，打分衔接数据量太大
在线Latency容忍度低
流程化
定义主流程，部分子图逻辑并行迭代 图合并部署
单机合并部署跨团队大图
代码级跨团队协作
用户开发
流量治理
容器Runtime
调度
搜索推荐业务Serverless
总结
百万级QPS峰值：
算法/业务代码性能缺陷及机器缺口 算法效果和资源的权衡 业务不可准确预估： 预估偏差巨大 业务错峰
性能优化的挑战： 个性化代码
优化的可持续性和可复用性
双11?大促?面临的挑战：资源&
性能
以上数据均为虚构演示数据
中台技术架构概述
目录 1. 什么是中台 (3) 2. 中台和微服务的区别 (5) 3. 为什么要做中台 (6) 4. 深入中台架构 (8) 5. 总结 (10)
这两年中台很火，已经代替微服务成为架构首选，涌现出各种各样的中台名词，业务中台、数据中台、技术中台、算法中台等，让人眼花缭乱，稍微大点的互联网公司都号称在做中台。 1. 什么是中台 既然讲中台，必然还有前台和后台。前台很好理解，指的是面向 C 端的应用，包括前端(如App/ 小程序) 和对应的服务端。至于后台，很多人把它等同于管理后台，比如商品管理后台，负责商品定义/ 上下架等，提供给内部运营人员使用，这可能不够准确。 简单来说，对于一个交易系统，前台对应用户能看到的部分，如商品浏览和下单，属于接单的部分；后台对应履单部分，如仓库拣货/ 配送/ 财务结算/ 采购补货等，属于实际干活的，由企业内部人员负责，处于一个交易处理流程的后端。 在传统企业，没有在线的前台，基本是线下手工接单，内部信息管理系统基本都属于履单范畴，例如ERP、CRM、采购系统、仓库管理系统，财务系统等，这些系统属于一般意义上的后台概念。 在互联网企业，因为系统一般是自己开发，管理后台既包含面向前台销售的功能，如商品上下架和促销管理，也包含面向履单部分，比如配送、采购、财务结算，所以互联网企业的管理后台并不简单等同于履单后台。 接单和履单之间还有一系列事情要做，包括生成订单时的优惠计算/ 创建实际的订单/ 支付/ 库存扣减等, 这部分功能属于交易逻辑的核心。在简单场景下，前台应用包含这部分功能，在复杂的场景下，就有必要把这部分独立出来，构成独立的中台，为前台减负。 一些文章笼统地介绍中台是用来连接前台和后台的，这个值得商榷。如果管理后台就是后台，那没有连接的必要，因为管理后台本身就是系统的附属部分，和前台属于一体两面。至于履单
数据中台的技术架构和方法论 建设企业的数据化引擎
目录 1.前言 (3) 2.为什么大家开始建设数据中台？ (3) 3.什么是数据中台？ (5) 4.数据中台包含什么？ (9) 4.1. 数仓体系 (9) 4.2. 数据服务集 (10) 4.3. BI 平台 (11)
1.前言 数据中台最早是阿里提出的，但真正火起来是2018 年，我们能感受到行业文章谈论数据中台的越来越多。大量的互联网、非互联网公司都开始建设数据中台。为什么很多公司开始建设数据中台？尽管数据中台的文章很多，但是一千人眼里有一千个数据中台，到底什么是数据中台？数据中台包含什么？2017 年开始，当网易严选有了一定量的数据，我们就开始规划建设我们的数据中台，目前我们已经完成了数据中台体系的搭建，我将根据我们建设数据中台的经验和方法论试图解答上面这些问题。 2.为什么大家开始建设数据中台？ 2018 年开始，朋友圈里讲数据中台的文章开始逐渐变多，当然拿着手机看世界并不一定看到真实的世界。我也跟各个行业的一些大公司的CIO 交流，发现很多行业的大公司都开始组建大数据团队，建设数据中台。结合文章和交流获取的信息，我切身感受到宏观经济对技术的影响。2018 年开始经济下行，生意不好做了，粗放的经营已经不行了，越来越多的企业想通过数据驱动来进行精细化的运营和数据化转型。
如上图所示，企业需要数字化转型，需要更多的触点去跟自己的用户/ 客户建立联系，很多企业就需要做自己的公众号、小程序(各家的小程序) 甚至app。我们希望用户更容易找到我们的商品/ 服务，我们就需要搜索。我们希望用户更多的浏览/ 使用我们的商品/ 服务就需要推荐。我们维护用户/ 客户的生命周期，根据生命周期采取不同的营销动作，就需要CRM。我们需要拉来更多的新用户，就需要投放广告，为了更好的投放效果，我们需要建设我们的DMP。当我们生意做大，我们需要对抗黑产(羊毛党)，让我们的优惠能让真正的用户享受，我们需要风控。这一切都需要底层大数据的支持。企业需要精细化运营，就需要不断的提升运营的频次(如下图所示) 和粒度。我们需要把运营的节奏提升到周级、天级甚至实时。我们随时随地了解我们企业经营状况，需要不断的更精细(细粒度) 的分析我们的业务，快速做出业务决策。我们就需要能够快速地构建大量的BI 报表，在一些重要的节点(大促) 时，甚至需要盯着数据大屏。如果我们有能力，还可以建设场景化的数据产品来支持业务的决策。这一切都需要底层大数据的支持。 如何快速地利用底层大数据的支持，让我们的数据化转型、精细化运营能够高频的迭代，这就需要我们的数据中台提供强有力的支持。这里也提醒一点，当我们需要大规模的数据应用时(搜
数据中台技术架构解读
目录 前言 (3) 一当前关于“中台”问题研究存在诸多问题 (3) 二科学界定“数据中台”问题的基本原则 (7) 三小数据是理解数据中台的关键 (11)
前言 数据中台最近特别火，之前还在炒概念，现在突然就看到有的企业已经宣传自家的数据中台了，有的企业向外介绍如何构建自己的数据中台，利用数据中台打造数据驱动的经营能力。大家热衷于讨论什么是“数据中台”，并且还有“有一千个企业，就有一千个数据中台”的说法，但大家真的都理解了什么是数据中台了吗？ 本文基于笔者的个人思考，首先介绍了当前关于“中台”问题研究存在的3个主要问题，然后从3个方面说明了科学界定数据中台的基本原则，最后指出小数据是理解数据中台的关键，以更加科学合理的角度使读者更加清晰、全面的认识数据中台。” 一当前关于“中台”问题研究存在诸多问题 Supercell，芬兰移动游戏巨头，成立于2010年，拥有《部落冲突》、《卡通农场》、《海岛奇兵》、《皇室战争》和《荒野乱斗》等全球热门游戏。据说，2015年12月马云亲自率队到Supercell公司进行商务拜访，马云对Supercell的高效运营无比感慨，将其经营秘密概括为中台战略，要求阿里巴巴按照“大中台、小前台”的组织原则进行公司架构改革。 不管上述“中台”的马云说是否属实，但“中台”的概念确实在近年来不断发酵并从去年开始流行起来，日益成为行业共识，但大家对如何认识这个共识还没有达成一致意见，同时当前关于“中台”问题的研究还存在诸多问题。 1.1对数据中台的定义不清目前关于数据中台的定义很多，笔者根据网上数据中台相关著作或文章，搜集了一些对数据中台的定义，供读者参考，如下表所示。 表1 网上关于数据中台的定义
阿里中台技术架构介绍
目录 1.阿里业务中台架构图 (3) 2.业务中台化-产品形态 (4) 3.业务中台化-全局架构 (4) 4.业务中台化 - 业务创新和智能化 (5) 5.阿里核心业务架构 (6) 6.阿里数据中台架构 (7) 7.阿里技术全栈全景图 (8) 8.阿里技术平台底座 (9) 9.阿里中台组织架构 (10) 10.业务中台建设路径 (11) 11.企业中台战略升级的4个方面 (12) 12.阿里中台的能力开放 (13) 13.阿里业务中台建设方法论 (13) 14.小结 (15)
1.阿里业务中台架构图 基础设施服务，即IAAS层，提供硬件底层支持。 基础服务层，即PAAS层，包括分布式服务框架、分布式数据库、分布式消息、分布式存储、分布式事务、实时监控服务等等。 互联网业务中台，包括各服务中心的抽象出来的各种业务能力，包括交易中心、支付中心、营销中心、结算中心、用户中心、账户中心等等。也包括非业务类服务，如日志分析中心、配置中心、序列中心、基础中心。 业务应用，经过调取业务中台，组装形成独立业务服务能力的业务应用，如 交易来源，就是前台用户使用的各个端，如淘宝App、PC站等。
2.业务中台化-产品形态 阿里的电商生态，就是要根据对商业的理解，把一些基础逻辑梳理出来。例如什么是业务？什么是业务身份？各个业务领域的边界是什么？每个领域提供的基础服务是什么？领域服务和领域服务之间的流程链接标准是什么？再在这些思想的指导下去建立业务平台化的实施标准和业务管控标准。 电商业务中台由一系列：业务能力标准、运行机制、业务分析方法论，配置管理和执行系统以及运营服务团队构成的体系，提供各业务方能够快速，低成本创新的能力。 3.业务中台化-全局架构
数据中台组成及技术架构设计 随着大数据与人工智能技术的不断迭代以及商业大数据工具产品的推出，数据中台的架构设计大可不必从零开始，可以采购一站式的研发平台产品，或者基于一些开源产品进行组装。企业可根据自身情况进行权衡考虑，但无论采用哪种方案，数据中台的架构设计以满足当前数据处理的全场景为基准。 以开源技术为例，数据中台的技术架构如图所示，总体来看一般包含以下几种功能：数据采集、数据计算、数据存储和数据服务；在研发、运维和公共服务方面包括离线开发、实时开发、数据资产、任务调度、数据安全、集群管理。 1.数据采集层 按数据的实时性，数据采集分为离线采集和实时采集。离线采集使用DataX和Sqoop，实时采集使用Kafka Connect、Flume、Kafka。 在离线数据采集中，建议使用DataX和Sqoop相结合。DataX适合用在数据量较小且采用非关系型数据库的场景，部署方式很简单。Sqoop适合用在数据量较大且采用关系型数据库的场景。 在实时数据采集中，对于数据库的变更数据，如MySQL的binlog、Oracle的OGG，使用Kafka Connect进行数据的实时采集。对于其他数据，先将数据实时写
成文件，然后采用Flume对文件内容进行实时采集。将实时采集后的数据推送到Kafka，由Flink进行数据处理。 2.数据计算层 数据计算采用YARN作为各种计算框架部署的执行调度平台，计算框架有MapReduce、Spark及Spark SQL、Flink、Spark MLlib等。 MapReduce是最早开源的大数据计算框架，虽然现在性能相对较差，但它的资源占用比较小，尤其是内存方面。因此在部分数据量过大，而其他计算框架由于硬件资源的限制（主要是内存限制）而无法执行的场景，可以将MapReduce作为备选框架。 Spark及Spark SQL是在批处理方面拥有出色性能的成熟技术方案，适合大部分的离线处理场景。特别是在离线数据建模方面，建议使用Spark SQL进行数据处理，既能保证易用性，又能保证处理的性能。Flink是实时数据处理方面的首选，在处理的时效性、性能和易用性方面都有很大优势。 而机器学习一般采用Spark家族的Spark MLlib为技术底座。Spark MLlib内置了大量的常规算法包，如随机森林、逻辑回归、决策树等，可以满足大部分数据智能应用场景。 同时，数据中台不断进化，也逐渐融入A I能力。如人脸识别、以图搜图、智能客服等能力的实现就需要A I平台。目前较为成熟的A I平台有T en so rFl ow及PyTo rc h。为实现物体的检测和识别，可使用SS D、Y O L O和Re s Ne t等深度学习模型，而在人脸检测和识别中则主要使用M TC NN、Re t inaNe t和Re s Ne t，人脸检索可使用Faceb oo k开源的针对人脸检索的Fai ss框架。 3.数据存储层 数据存储层所有的存储引擎都基于H ad oo p的HD FS分布式存储，从而达到数据多份冗余和充分利用物理层多磁盘的I/O性能。在HD FS上分别搭建H i v e、HB a s e
搜索推荐整体架构（AI·OS）
ABFS：基础特征服务 iGraph：图引擎 BE/DII：召回引擎 RTP：Rank Service HA3：搜索引擎 AOP：一站式机器学习平台 TPP：灵活业务平台 标准化：从搜索到推荐
TPP: 搜索推荐业务平台 支持算法及业务的快速迭代，让用户真正专注自己的核心逻辑 集团最大业务规模serverless平台：服务集团62+BU，万级别场景 集团最大的JAVA单体应用之一 峰值QPS 阿里在线水位最高的JAVA应用之一 双11百万级QPS，万级别容器 2015201620172018
搜索推荐中台?目标 AI OS Serverless 图化算子化
新业务创建成本过高 场景/团队爆发式增长 资源调配太难，水位极低 双11挑战巨大 逼出来的Serverless 过万 2011 2013 2014 2015 2016 2017 2018 2019 场景 我的集群 我的集群 我的集群
Serverless 的开始：FAAS 传统应?用 Faas 新业务成本git/aone/应?用分组/vip/服务框 架/业务逻辑 git/业务逻辑 监控ALL ?自建平台提供细粒度多维度监控流量量治理理ALL ?自建平台提供限流/降级/负载均衡/ 容灾/切流 资源?手动 全时快速弹性 迭代 ?无统?一实验体系/协作成本?高 灵活实验/快速发布/敏?捷协作 专注业务逻辑 关注业务逻辑 剥离业务开发不关心的问题 基于JVM Runtime 面向JAVA高度性能优化 面向在线 百万级低延迟在线服务 快速弹性 全时秒级弹性 快速迭代 快速实验和反馈