同理心 / 视角转换是最重要的。
选择可持续的架构，以减少每个功能的人力资源成本。
采用模式和最佳实践。
避免反模式
有效的重构
日志与度量：日志是发生的事件，而度量是对系统健康状况的测量。
我们假设该系统的目的是提供度量——即计数器、转化率、计时器等，用于监控系统性能和健康。如果转化率大幅下降，系统应警告值班人员。
构建系统的两种方式：
拉取模型更具可扩展性，因为它减少了进入度量数据库的请求数量——没有热路径和并发问题。
以移动应用的四步注册为例
输入手机号码 -> 验证短信代码 -> 输入姓名 -> 输入密码
每一步都有 IMPRESSION 和 POST_VERIFICATION 阶段。并发出如下度量：
{
"sign_up_session_id": "uuid",
"step": "VERIFY_SMS_CODE",
"os": "iOS",
"phase": "POST_VERIFICATION",
"status": "SUCCESS",
// ... ts, contexts, ...
}
因此，我们可以查询 iOS 上 VERIFY_SMS_CODE 步骤的整体转化率，如下所示：
(counts of step=VERIFY_SMS_CODE, os=iOS, status: SUCCESS, phase: POST_VERIFICATION) / (counts of step=VERIFY_SMS_CODE, os=iOS, phase: IMPRESSION)
Grafana 在数据可视化工作中已经相当成熟。如果您不想暴露整个网站，可以使用 嵌入面板与 iframe。
设计一个类似于 Square Cash（以下称为 Cash App）或 PayPal 的转账后端系统，以实现：
支付数据模型本质上是“复式记账”。每个账户的每一笔入账都需要在另一个账户中有相应的对立入账。所有借方和贷方的总和等于零。
交易：新用户 Jane Doe 从银行向 Cash App 存入 100 美元。这一笔交易涉及以下数据库条目：
记账表（用于历史记录）
+ 借方, 美元, 100, CashAppAccountNumber, txId
- 贷方, 美元, 100, RoutingNumber:AccountNumber, txId
交易表
txId, 时间戳, 状态（待处理/已确认）, [记账条目], 叙述
一旦银行确认交易，更新上述待处理状态和以下资产负债表，均在一笔交易中完成。
资产负债表
CashAppAccountNumber, 美元, 100
与上述情况类似，但没有待处理状态，因为我们不需要慢速外部系统来更改其状态。所有记账表、交易表和资产负债表的更改都在一笔交易中完成。
我们在三个维度上解决国际化问题。
accept-language 头部进行选择。例如，Jane Doe 想以 0.2 的汇率将 1 美元兑换为 6.8 人民币。
记账表
- 贷方, 美元, 1, CashAppAccountNumber, txId
+ 借方, 人民币, 6.8, CashAppAccountNumber, txId, @7.55 人民币/美元
+ 借方, 美元, 0.1, ExpensesOfExchangeAccountNumber, txId
交易表、资产负债表等与存款和支付中讨论的交易类似。主要区别在于银行或供应商提供兑换服务。
轮询：定时作业（SWF、Airflow、Cadence 等）轮询待处理订单的状态。回调：为外部供应商提供回调 API。为什么去重是一个问题？
对于上述 轮询 情况，如果外部网关不支持幂等 API，为了不淹没重复条目，我们必须记录外部系统给我们的订单 ID 或参考 ID，并通过订单 ID 查询 GET，而不是一直使用 POST。
对于 回调 情况，我们可以确保实现幂等 API，并且无论如何我们将 待处理 更改为 已确认。
异步设计 + 重试 + 排队 + 可观察性 + 安全性
订阅由支付状态机或其他服务发布的支付成功事件队列。
一旦调用者接受事件，从用户设置服务获取 webhook URI、密钥和设置。根据这些设置准备请求。为了安全...
所有来自用户设置的 webhook 必须使用 HTTPS。
如果负载很大，预期延迟很高，并且我们希望确保目标接收器是活跃的，我们可以通过携带挑战的 ping 验证其存在。例如，Dropbox 通过发送带有“challenge”参数（一个随机字符串）的 GET 请求来验证 webhook 端点，您的端点需要将其回显作为响应。
所有回调请求都带有头部 x-webhook-signature。这样接收者可以验证请求。
HMAC(webhook secret, raw request payload); Telegram 使用此方法。RSA(webhook private key, raw request payload); Stripe 使用此方法。// POST https://example.com/webhook/
{
"id": 1,
"scheduled_for": "2017-01-31T20:50:02Z",
"event": {
"id": "24934862-d980-46cb-9402-43c81b0cdba6",
"resource": "event",
"type": "charge:created",
"api_version": "2018-03-22",
"created_at": "2017-01-31T20:49:02Z",
"data": {
"code": "66BEOV2A", // 或用户需要履行的订单 ID
"name": "主权个体",
"description": "掌握信息时代的过渡",
"hosted_url": "https://commerce.coinbase.com/charges/66BEOV2A",
"created_at": "2017-01-31T20:49:02Z",
"expires_at": "2017-01-31T21:49:02Z",
"metadata": {},
"pricing_type": "CNY",
"payments": [
// ...
],
"addresses": {
// ...
}
}
}
}
商家服务器应以 200 HTTP 状态码响应以确认收到 webhook。
如果没有收到确认，我们将使用幂等性密钥和指数退避重试，最长可达三天。最大重试间隔为 1 小时。 如果达到某个限制，则短路/标记为损坏。向商家发送电子邮件。
Webhook 调用者服务将状态发射到时序数据库以获取指标。
使用 Statsd + Influx DB 还是 Prometheus？
或者如果您有宽裕的预算，可以使用昂贵的 DataDog 或其他 APM 服务。
买入 和 卖出 订单的订单匹配系统。订单类型：
Order(id, stock, side, time, qty, price)x 轴
y 轴投射到 x 轴上
Id Side Time Qty Price Qty Time Side
---+------+-------+-----+-------+-----+-------+------
#3 20.30 200 09:05 卖出
#1 20.30 100 09:01 卖出
#2 20.25 100 09:03 卖出
#5 买入 09:08 200 20.20
#4 买入 09:06 100 20.15
#6 买入 09:09 200 20.15
来自 Coinbase Pro 的订单簿
如何实现价格-时间 FIFO 匹配算法？
如何实时将订单簿数据传输到客户端？
如何支持不同类型的订单？
卖出或买入：数量 @ 价格，但具有不同的创建设置和匹配条件
架构是软件系统的形状。就好像是一个物理世界的建筑的全景：
它们共同服务于特定的目的，例如医院是为治愈病人而设，学校是为教育学生而设。
每个软件系统为利益相关者提供两种不同的价值：行为和结构。软件开发人员负责确保这两种价值都保持高水平。
==软件架构师由于其工作描述，更加关注系统的结构，而不是其特性和功能。==
架构为软件系统的整个生命周期提供服务，使其易于理解、开发、测试、部署和操作。目标是最小化每个业务用例的人力资源成本。
O’Reilly的书《软件架构模式》由Mark Richards撰写，是对这五种基本架构的简单而有效的介绍。
分层架构是最常见的架构，开发人员广泛熟知，因此是应用程序的事实标准。如果您不知道使用什么架构，请使用它。
示例
优缺点
状态变化将向系统发出事件。所有组件通过事件相互通信。
一个简单的项目可以结合中介、事件队列和通道。然后我们得到一个简化的架构：
示例
软件的职责被划分为一个“核心”和多个“插件”。核心包含最基本的功能。插件彼此独立，并实现共享接口以实现不同的目标。
示例
一个庞大的系统被解耦为多个微服务，每个微服务都是一个单独部署的单元，它们通过RPCs相互通信。
示例
该模式得名于“元组空间”，意为“分布式共享内存”。没有数据库或同步数据库访问，因此没有数据库瓶颈。所有处理单元在内存中共享复制的应用数据。这些处理单元可以弹性启动和关闭。
示例：见维基百科
在 今日头条推荐系统：P1 概述 中，我们了解到内容分析和用户标签的数据挖掘是推荐系统的基石。
内容分析 = 从原始文章和用户行为中提取中间数据。
以文章为例。为了建模用户兴趣，我们需要对内容和文章进行标记。为了将用户与“互联网”标签的兴趣关联起来，我们需要知道用户是否阅读了带有“互联网”标签的文章。
我们这样做的原因是 …
以下是“文章特征”页面的示例。文章特征包括分类、关键词、主题、实体。
文章特征是什么？
语义标签：人类预定义这些标签，具有明确的含义。
隐含语义，包括主题和关键词。主题特征描述了单词的统计数据。某些规则生成关键词。
相似性。重复推荐曾是我们从客户那里获得的最严重反馈之一。
时间和地点。
质量。滥用、色情、广告或“心灵鸡汤”？
我们将语义标签的特征分为三个层次：
为什么要分成不同的层次？我们这样做是为了能够以不同的粒度捕捉文章。
分类和概念共享相同的技术基础设施。
我们为什么需要语义标签？
分类层级
分类器：
我们正在寻找以下最佳 function 以最大化 用户满意度 。
用户满意度 = function(内容, 用户资料, 上下文)
可测量的目标，例如：
难以测量的目标：
找到上述最佳 function 是一个典型的监督机器学习问题。为了实施该系统，我们有以下算法：
一个世界级的推荐系统应该具备 灵活性，以进行 A/B 测试并结合上述多种算法。现在结合逻辑回归和深度神经网络变得流行。几年前，Facebook 使用了逻辑回归和 GBDT。
内容特征与用户兴趣之间的相关性。 显式相关性包括关键词、类别、来源、类型。隐式相关性可以从 FM 等模型的用户向量或项目向量中提取。
环境特征，如地理位置、时间。 可以用作偏见或在其基础上建立相关性。
热门趋势。 有全球热门趋势、类别热门趋势、主题热门趋势和关键词热门趋势。热门趋势在我们对用户信息较少时非常有助于解决冷启动问题。
协同特征，帮助避免推荐内容越来越集中。 协同过滤不是单独分析每个用户的历史，而是根据用户的点击、兴趣、主题、关键词或隐式向量找到用户的相似性。通过找到相似用户，可以扩展推荐内容的多样性。
它们的实现步骤如下：
考虑到所有内容的超大规模，无法用模型预测所有事情。因此，我们需要召回策略来关注数据的代表性子集。性能在这里至关重要，超时时间为 50 毫秒。
在所有召回策略中，我们采用 InvertedIndex<Key, List<Article>> 。
Key 可以是主题、实体、来源等。
| 兴趣标签 | 相关性 | 文档列表 |
|---|---|---|
| 电子商务 | 0.3 | … |
| 娱乐 | 0.2 | … |
| 历史 | 0.2 | … |
| 军事 | 0.1 | … |
内容分析 = 从原始文章和用户行为中推导中间数据。
以文章为例。为了建模用户兴趣，我们需要对内容和文章进行标记。为了将用户与“互联网”标签的兴趣关联起来，我们需要知道用户是否阅读了带有“互联网”标签的文章。
我们这样做的原因是 …
这是“文章特征”页面的示例。文章特 征包括分类、关键词、主题、实体。
文章特征是什么？
语义标签：人类预定义这些标签并赋予明确的含义。
隐式语义，包括主题和关键词。主题特征描述了单词的统计信息。某些规则生成关键词。
相似性。重复推荐曾是我们客户反馈中最严重的问题。
时间和地点。
质量。滥用、色情、广告或“心灵鸡汤”？
我们将语义标签的特征分为三个层次：
为什么要分为不同层次？我们这样做是为了能够以不同的粒度捕捉文章。
分类和概念共享相同的技术基础设施。
我们为什么需要语义标签？
分类层次结构
分类器：
我们正在寻找以下最佳 函数 以最大化 用户满意度 。
用户满意度 = 函数(内容, 用户画像, 上下文)
可测量的目标，例如：
难以测量的目标：
寻找上述最佳 函数 是一个典型的监督机器学习问题。为了实现系统，我们有以下算法：
一个世界级的推荐系统应该具备 灵活性，能够进行 A/B 测试并结合上述多种算法。现在结合逻辑回归和深度神经网络的做法越来越流行。Facebook 多年前就同时使用了逻辑回归和 GBDT。
内容特征与用户兴趣之间的相关性。 显性相关性包括关键词、类别、来源、类型。隐性相关性可以从用户向量或模型如因子分解机中的物品向量中提取。
环境特征，如地理位置、时间。 可以作为偏差或在其基础上建立相关性。
热门趋势。 有全球热门趋势、类别热门趋势、主题热门趋势和关键词热门趋势。热门趋势在我们对用户信息较少时非常有助于解决冷启动问题。
协同特征，有助于避免推荐内容越来越集中。 协同过滤不是单独分析每个用户的历史，而是根据用户的点击、兴趣、主题、关键词或隐性向量找到用户之间的相似性。通过找到相似用户，可以扩展推荐内容的多样性。
它们的实现步骤如下：
考虑到所有内容的超大规模，无法用模型预测所有事情。因此，我们需要召回策略来关注数据的代表性子集。性能在这里至关重要，超时为 50 毫秒。
在所有召回策略中，我们采用 反向索引<Key, List<Article>>。
Key 可以是主题、实体、来源等。
| 兴趣标签 | 相关性 | 文档列表 |
|---|---|---|
| 电子商务 | 0.3 | … |
| 娱乐 | 0.2 | … |
| 历史 | 0.2 | … |
| 军事 | 0.1 | … |
result = pairs.map((pair) => (morePairs)).reduce(somePairs => lessPairs)。为了用商品机器满足上述需求，流处理框架在这些架构中使用分布式系统……
| 框架 | Storm | Storm-trident | Spark | Flink |
|---|---|---|---|---|
| 模型 | 原生 | 微批处理 | 微批处理 | 原生 |
| 保证 | 至少一次 | 精确一次 | 精确一次 | 精确一次 |
| 容错能力 | 记录确认 | 记录确认 | 检查点 | 检 查点 |
| 容错开销 | 高 | 中等 | 中等 | 低 |
| 延迟 | 非常低 | 高 | 高 | 低 |
| 吞吐量 | 低 | 中等 | 高 | 高 |
技术驱动的架构师和企业家，拥有构建高度可扩展的企业级 SaaS 应用程序的深厚专业知识。全栈专家，专注于设计灵活、可扩展的解决方案，以满足复杂和不断变化的需求。
![[object Object]](https://tp-misc.b-cdn.net/tianpan-avatar.jpg){kind=avatar}