为什么需要这样的框架？​

• 以低延迟处理高吞吐量。
• 分布式系统中的容错能力。
• 通用抽象以满足多变的业务需求。
• 适用于有界数据集（批处理）和无界数据集（流处理）。

批处理/流处理的简史​

1. Hadoop 和 MapReduce。Google 使批处理在分布式系统中变得简单，如 MR result = pairs.map((pair) => (morePairs)).reduce(somePairs => lessPairs)。
2. Apache Storm 和 DAG 拓扑。MR 无法有效表达迭代算法。因此，Nathan Marz 将流处理抽象为喷口和螺栓的图。
3. Spark 内存计算。Reynold Xin 表示，Spark 使用 10 倍更少的机器 以 3 倍更快 的速度对相同数据进行排序。
4. 基于 Millwheel 和 FlumeJava 的 Google Dataflow。Google 支持批处理和流处理计算，使用窗口 API。

等等……但为什么 Flink 正在获得越来越多的关注？​

1. 它快速采用了 ==Google Dataflow==/Beam 编程模型。
2. 它对 Chandy-Lamport 检查点的高效实现。

如何？​

架构选择​

为了用商品机器满足上述需求，流处理框架在这些架构中使用分布式系统……

• 主从（集中式）：apache storm 与 zookeeper，apache samza 与 YARN。
• P2P（去中心化）：apache s4。

特性​

1. DAG 拓扑用于迭代处理。例如，Spark 中的 GraphX，Apache Storm 中的拓扑，Flink 中的数据流 API。
2. 交付保证。如何保证从节点到节点的数据交付？至少一次 / 至多一次 / 精确一次。
3. 容错能力。使用 冷/热备用、检查点或主动-主动。
4. 无界数据集的窗口 API。例如，Apache Flink 中的流窗口。Spark 窗口函数。Apache Beam 中的窗口处理。

比较​

框架	Storm	Storm-trident	Spark	Flink
模型	原生	微批处理	微批处理	原生
保证	至少一次	精确一次	精确一次	精确一次
容错能力	记录确认	记录确认	检查点	检查点
容错开销	高	中等	中等	低
延迟	非常低	高	高	低
吞吐量	低	中等	高	高

明确需求​

实时计算风险概率分数，并结合规则引擎做出决策，以防止账户接管 (ATO) 和僵尸网络攻击。

通过在线和离线管道训练聚类特征

1. 来源于网站日志、认证日志、用户行为、交易、监控列表中的高风险账户

2. 在 Kafka 主题中跟踪事件数据

3. 处理事件并准备聚类特征

实时评分和基于规则的决策

4. 综合评估在线服务的风险评分

5. 在规则引擎中手动配置以保持灵活性

6. 在在线服务中共享或使用洞察

从易到难检测的账户接管

1. 来自单个 IP

2. 来自同一设备的 IP

3. 来自全球的 IP

4. 来自 100k 个 IP

5. 针对特定账户的攻击

6. 网络钓鱼和恶意软件

挑战

• 手动特征选择

• 对抗环境中的特征演变

• 可扩展性

• 无在线 DBSCAN

高级架构​

核心组件和工作流程​

半监督学习 = 未标记数据 + 少量标记数据

为什么？比无监督学习具有更好的学习准确性 + 比监督学习花费更少的时间和成本

训练：在数据库中准备聚类特征​

• Spark 上的流处理管道：

  • 实时连续运行。

  • 动态执行特征归一化和类别转换。

    • 特征归一化：将数值特征（如年龄、收入）缩放到 0 和 1 之间。

    • 类别特征转换：应用独热编码或其他转换，将类别特征转换为适合机器学习模型的数值格式。

  • 使用 Spark MLlib 的 K-means 将流数据聚类成组。

    • 运行 k-means 并形成聚类后，可能会发现某些聚类中有更多的欺诈实例。

    • 一旦根据历史数据或专家知识将某个聚类标记为欺诈，就可以在推断过程中使用该聚类分配。任何分配到该欺诈聚类的新数据点都可以标记为可疑。

• 每小时定时任务管道：

  • 每小时定期运行（批处理）。

  • 应用 阈值 来根据聚类模型的结果识别异常。

  • 调整 DBSCAN 算法 的参数以改善聚类和异常检测。

  • 使用 scikit-learn 的 DBSCAN 在批量数据中寻找聚类并检测异常值。

    • DBSCAN 可以检测异常值，可能会识别出常规交易的聚类，并将其与可能不寻常、潜在欺诈的交易分开。

    • 在噪声或异常区域（不属于任何密集聚类的点）中的交易可以标记为可疑。

    • 在识别出某个聚类为欺诈后，DBSCAN 有助于即使在不规则形状的交易分布中也能检测到欺诈模式。

服务​

服务层是将机器学习模型和业务规则转化为实际欺诈预防决策的地方。其工作原理如下：

• 欺诈检测评分服务：

  • 提取来自传入请求的实时特征

  • 应用两种聚类模型（流处理中的 K-means 和批处理中的 DBSCAN）

  • 将分数与流计数器（如每个 IP 的登录尝试次数）结合

  • 输出 0 到 1 之间的统一风险评分

• 规则引擎：

  • 作为系统的“头脑”

  • 将 ML 分数与可配置的业务规则结合

  • 规则示例：

    • 如果风险评分 > 0.8 且用户从新 IP 访问 → 需要 2FA

    • 如果风险评分 > 0.9 且账户为高价值 → 阻止交易

  • 规则存储在数据库中，可以无需代码更改进行更新

  • 为安全团队提供调整规则的管理门户

• 与其他服务的集成：

  • 暴露用于实时评分的 REST API

  • 将结果发布到流计数器以进行监控

  • 将决策反馈到训练管道以提高模型准确性

• 可观察性：

  • 跟踪关键指标，如误报/漏报率

  • 监控模型漂移和特征分布变化

  • 为安全分析师提供调查模式的仪表板

  • 记录详细信息以进行事后分析

免责声明：以下所有内容均来自公共资源或纯粹原创。 这里不包含优步的涉密内容。

要求​

• 为全球的交通运输市场提供服务
• 大规模的实时调度
• 后端设计

架构​

为何要微服务？​

==Conway定律== 软件的系统结构会对应企业的组织结构。

	单体 ==服务==	微服务
当团队规模和代码库很小时，生产力	✅ 高	❌ 低
==当团队规模和代码库很大时，生产力==	❌ 低	✅ 高 (Conway定律)
==对工程质量的要求==	❌ 高 (能力不够的开发人员很容易破坏整个系统)	✅ 低 (运行时是隔离的)
dependency 版本升级	✅ 快 (集中管理)	❌ 慢
多租户支持 / 生产-staging状态隔离	✅ 容易	❌ 困难 (每项服务必须 1) 要么建立一个staging环境连接到其他处于staging状态的服务 2) 要么跨请求上下文和数据存储的多租户支持)
可调试性，假设相同的模块，参数，日志	❌ 低	✅ 高 (如果有分布式tracing)
延迟	✅ 低 (本地)	❌ 高 (远程)
DevOps成本	✅ 低 (构建工具成本高)	❌ 高 (容量规划很难)

结合单体 ==代码库== 和微服务可以同时利用两者的长处.

调度服务​

• 由geohash提供一致的哈希地址
• 数据在内存中是瞬态的，因此不需要复制. (CAP: AP高于CP)
• 分片中使用单线程或者锁，以防止双重调度

支付服务​

==关键是要有异步设计==, 因为跨多个系统的ACID交易支付系统通常具有非常长的延迟.

• 利用事件队列
• 支付接口集成 Braintree, PayPal, Card.io, Alipay 等
• 通过详尽的 log 来记录所有 event
• 使用具有等幂性、指数退避和随机抖动的API

用户档案服务和行程记录服务​

• 使用缓存降低延迟
• 随着 1) 支持更多的国家和地区 2) 用户角色（司机，骑手，餐馆老板，食客等）逐渐增加，为这些用户提供用户档案服务也面临着巨大的挑战。

通知推送服务​

• 苹果通知推送服务 (不可靠)
• 谷歌云消息服务GCM （它可以检测到是否成功递送) 或者
• 短信服务通常更可靠

安迪格鲁夫强调：==管理者最重要的责任是激发他的下属做出最佳的表现==。

不幸的是，没有一种管理风格适合各种场景下的所有人。找到最佳管理风格的基本变量是下属的任务相关成熟度（TRM）。

部属的工作成熟度	有效的领导风格
低	组织化; 以任务为导向; 面向细节; 准确地指出“什么时候-什么事情-怎么做”的细节模式
中	以人为本; 给予支持，“双向沟通”模式
高	以目标为导向的“监控”模式

一个人的任务相关的成熟度取决于具体的工作项目，它的改进需要时间。 当任务相关的成熟度达到最高水平时，这个人的知识水平和积极性就会达到一定高度，让他的管理者能够顺利地把工作委派给他。

这其中的关键是==管理方式无所谓好坏，只有有效和无效==。

什么是“变化厌恶”？​

总的来说，“变化厌恶”就是每当你改变人们经常在产品中使用到的东西时，用户中会出现骚动和反对的声音。这种骚动几乎会出现在如 Gmail，YouTube，iPhone 等产品的每一个版本中。

如何减轻甚至避免“变化厌恶”？​

1. 让用户能够事先知晓、事后理解。事先把新版本的重大改变告知用户，并向其阐述做出这些改变的原因，事后要给出如何过渡的指导。
2. 允许用户自由切换。不要断绝用户切换回原版本的渠道，不要让他们落入孤立无助的境地。
3. 持续跟进用户的反馈。

不要让“变化厌恶”成为没把事情做好的借口​

随着时间的推移，产品的改变究竟是好是坏，人们终究会得到答案。

安迪·格罗夫强调，==管理者最重要的责任是激发下属的最佳表现。==

不幸的是，一种管理风格并不适合所有人和所有场景。寻找最佳管理风格的一个基本变量是下属的任务相关成熟度（TRM）。

TRM	有效管理风格
低	结构化；任务导向；注重细节；准确指导“什么/何时/如何模式”
中	个人导向；支持，“相互推理模式”
高	目标导向；监控模式

一个人的 TRM 取决于特定的工作项目。提高 TRM 需要时间。当 TRM 达到最高水平时，个人的知识水平和动机都已准备好让她的管理者委派工作。

关键在于将任何管理模式视为有效或无效，而不是好或坏。

• 品牌 / 广告主：希望向客户发布广告信息的个人或组织。

• 代理机构：帮助品牌与生态系统的其他部分互动，并管理广告信息的整个生命周期，包括规划、创建和分发广告活动。

• 交易台：简化媒体购买流程。

• 需求方平台 (DSP)：自动化在线广告库存和购买，帮助代理机构通过一个平台管理不同账户和广告活动。

• 数据管理平台 (DMP)

  1. 基于广告的分析：流失率、定位、画像、会话回放等。
  2. 反欺诈
  3. 基于市场的分析

• 广告交易所 / 实时竞价 (RTB)：将广告供应商与买家匹配。

• 广告网络：聚合出版商库存并将其出售给广告主。

• 供应方平台 (SSP)：监控整个广告库存并为广告空间建议价格。

• 出版商：广告空间的拥有者，如网站运营商。

自1990年以来，互联网的 402 Payment Required 的状态码早就设计好了，但是过了接近三十年，互联网支付还没有做到无缝体验。

1. 我在网上看到篇文章只是想交个钱支持一下，你偏要我创建账户，创建密码，填信用卡号，完了还要收没完没了的垃圾邮件
2. 支付应该像浏览器一样方便，一键交钱，不用填账号，用 crypto token 就成，但是中心化的支付会被大公司垄断
3. 内容创造者不得不和广告绑定，只有大玩家能赢，他们还变得要钱不要脸
4. 互联网亟需能够激励创意、保护隐私的基础构架。 虽然 Bitcoin 不是答案，blockchain 会有机会

什么是变更厌恶？​

一般来说，任何时候你改变人们在产品中常用的东西，他们都会产生强烈反应。这几乎发生在每一次产品发布中，比如 Gmail、YouTube、iPhone 等等。

如何避免或减轻变更厌恶？​

1. 让用户提前和之后了解。提前警告他们重大变化，并沟通这些地方为何发生变化。之后提供过渡说明。
2. 让用户切换。不要关上门，让他们孤立无援。
3. 让用户提供反馈并跟进。

变更厌恶不是借口​

产品的变化可能会变得好或坏。

这里是一些不成熟的小看法，我没有在中国工作过，所以按照我在学校的所闻所见填写到中国人这一栏里面。

异​

美国人看重	中国人看重
说服力 公开演讲是民主社会的基础	桃李不言下自成蹊 君子欲讷于言而敏于行
情绪化是令人羞愧/不专业的事情 虚伪/专业化	性情中人 撕破脸
开会是为了决定事情	开会是为了最后拍板
喜欢钻石	喜欢玉
自信 不行也得说行 我比其他人厉害	谦虚 行也得说不行 其他人比我厉害
独立思考 挑战权威	团队精神 服从力和执行力

同​

美国人中国人都看重

• 商业嗅觉
• 愿景和战略决策能力
• 团结就是力量 (我过去所共事的中国人都非常团结，虽然很多人对此有偏见)
• 人比事情重要，关系决定事情
• 应对VUCA的灵活性