推荐系统相关
新闻的推荐系统是为了给信息流的用户推荐资讯 feed。接口返回的信息不一定会被外显曝光。
在瀑布流式的外显曝光场景下，重排能够减少用户的疲劳度。
这就涉及到推荐系统的设计，流量要经过什么样的链路呢？
接入层、推荐中控、画像、召回、粗排、精排、重排。这些系统会形成星型架构和树形架构。
不同的架构之间有一个典型的优缺点需要取舍：链路长度会影响网络传输的最终效率，也会影响推荐系统的性能。
All articles on this blog are licensed under CC BY-NC-SA 4.0 unless otherwise stated.
Related Articles
2019-09-05
《应用架构之道》笔记
架构师的职责 化繁为简。架构师是职责就是把复杂的问题简单化，使得其他人能够更好地在架构里工作。 架构师要努力训练自己的思维，用它去理解复杂的系统，通过合理的分解和抽象，做出合理的设计。 软件架构 软件架构是一个系统的草图。软件架构描述的对象是直接构成系统的抽象组件。各个组件的链接则明确和相对细致地描述组件之间的通信。 软件架构为软件系统提供了结构、行为和属性的高级抽象。，由构件的描述、构件的相互作用、指导构件集成的模式以及这些模式的约束组成。软件架构不仅显示了软件需求和软件结构之间的对应关系，而且指定了整个软件系统的组织和拓扑结构，提供了一些设计决策的基本原理。 软件架构的核心价值应该只围绕一个核心命题：控制复杂性。 软件架构分类 业务架构：由业务架构师负责，也可以称为业务领域专家、行业专家。业务架构属于顶层设计，其对业务的定义和划分会影响组织结构和技术架构。 应用架构：由应用架构师负责，他需要根据业务场景的需要，设计应用的层次结构，制定应用规范、定义接口和数据交互协议等。并尽量将应用的复杂度控制在一个可以接受的水平，从而在快速的支撑业务发展的同时，在保证系统的可用性和可维...
2022-01-10
面向不确定性编程
本文是如何写《复杂业务系统》和《我眼中的阿里经济体的中台架构演进》的续篇。 本文探讨到底不确定性和复杂性源于何处，并引出互联网业务系统的一种“可适应性架构”，适用于平台型业务系统。 定义问题 软件难写，是软件工程师的共同感觉。 特别地，对于中国的互联网公司的“业务团队”的工程师而言，“业务系统”在业务的复杂度堆积到一定程度以后，软件本身的“熵增效应”会特别严重：一个业务系统的内部会充满了难以理解的分层、堆积如山的 if-else 分支，以至于很多工程师都不愿意进入密密麻麻复杂逻辑深处，去做高风险的维护工作。但是，只要公司正常发展，业务总会越做越大/复杂，所以要维持系统的可维护性，成为了一门很重要的学问。 现实中的系统的高复杂度问题，可以简单表述为“不确定性矛盾”：需求具有高度不确定性，一直都在高速变化；而工程师高度倾向于确定实现（因为高度抽象、反复抽象的成本很高），所以具体的实现难以变更，这两种相反的特性难以调和。 其实我们现在遇到的困境，历史上发生过很多次，比如我们现代的很多软件工程理论，就是从历次的软件危机中诞生的。归根结底，软件之所以叫软件（Software），是因为相...
2021-08-25
基本业务架构设计方法
如何实现自己的 validation 123456789101112131415161718192021222324252627282930313233343536373839// 抛出异常private void validateParam(Map<String, String> paramValues) { boolean validate = MapUtils.isEmpty(paramValues) || !paramValues.containsKey(ParamConstant.CUSTOMER_N0) || StringUtils.isEmpty(paramValues.get(ParamConstant.CUSTOMER_N0)); if (validate) { throw new DataBusinessException(ResultCodeEnum.PARAM_NULL); } ...
2022-01-19
Gergely Orosz 文章翻译-软件架构被高估，简明设计被低估
原文链接：《Software Architecture is Overrated, Clear and Simple Design is Underrated》
2020-12-02
服务治理组件笔记
背景 service-centric architecture 以服务为中心的架构，和 SOA 的区别是？ 服务治理的模式 server-side pattern：容易集中管控，易单点失败。 client-side pattern：不容易集中管控，不易单点失败。 演化流程 基础治理能力：通信协议统一、命名服务的统一、监控预警、运营平台 高性能/易用性：通信框架高性能/通信框架轻量化/分布式链路追踪/测试工具可视化 全方位的治理能力：全链路压测平台/深度服务化 SOA/链路级流量治理/易用化平台构建 业界前言探索：SET 化高扩展架构/云原生架构治理 治理体系 该有的治理能力都要有。 注册中心 服务注册 服务概要 提供者 消费者 监控报警 节点监控 性能监控 业务监控 异常监控 服务运营 配置管理 服务分组 节点管理 服务鉴权 数据分析 性能指标 来源去向 主机分析 数据报表 调用链路 关键组件-本地代理 比如 LocalAgent，能够做到：策略下沉，解耦功能，对业务服务侵入性低。 但 Provider/Consumer 还需要使用自己的 sdk，它和远端的 ...
2020-09-02
异地多活与单元化
核心结论 单元化不是“多建几套机房”，也不是把应用复制到多个城市就结束。它解决的是一个更具体的问题：当业务规模大到单机房、单库、单服务集群都无法继续水平扩展时，如何让一部分用户或一部分业务身份的请求，从接入层、服务层、中间件到数据层，都尽量闭环在同一个逻辑单元里。 一个成熟的单元化系统，至少要把四个域对齐： 域 需要对齐的内容 失配后的结果 流量域 请求能按用户、商家、地域、订单等分片标识进入指定单元 入口正确，内部调用仍然乱跳 数据域 核心数据按同一分片规则落到对应单元 服务闭环，数据库跨城访问 故障域 单元故障只影响该单元承载的流量和数据 一个局部故障拖垮全站 治理域 路由规则、注册中心、发布、监控、演练都理解单元 规则靠人工同步，切换时失控 这个定义能把几个常被混用的词分开： 概念 隔离对象 是否要求存储隔离 常见用途 AZ（Availability Zone） 基础设施故障域 不要求 机房级容灾、容量冗余 Set / Cell 业务流量和业务数据 通常要求 容量扩展、故障隔离、异地多活 RZone / GZone / ...
