在这篇文章中，我们将讨论以下话题：
- 反向代理 vs API 网关 vs 负载均衡器
- 典型 AWS 网络架构图
- 15 个改变世界的开源项目
- 6 大数据模型
- 我们如何在分布式系统中检测节点故障？
AWS 网络架构
Amazon Web Services（AWS）提供全面的网络服务套件，旨在为企业提供安全、可扩展和高可用的网络基础设施。AWS 的网络架构组件实现了互联网、远程工作者、企业数据中心和 AWS 生态系统内部的无缝连接。
核心组件
VPC（虚拟私有云）：AWS 网络服务的核心是 Amazon VPC，它允许用户在 AWS 云中配置一个逻辑隔离的部分。在这个隔离环境中，用户可以在他们定义的虚拟网络中启动 AWS 资源。
AZ（可用区）：AWS 中的 AZ 指的是一个或多个具有冗余电源、网络和连接的离散数据中心，位于 AWS 区域内。
网络连接
现在让我们逐一了解网络连接：
连接到互联网 - 互联网网关（IGW） IGW 作为你的 AWS VPC 和互联网之间的门户，促进双向通信。
远程工作者 - 客户端 VPN 端点 AWS 提供客户端 VPN 服务，使远程工作者能够通过互联网安全地访问 AWS 资源或本地网络。它提供了一个安全且易于管理的 VPN 解决方案。
企业数据中心连接 - 虚拟网关（VGW） VGW 是你的网络与 VPC 之间的站点到站点 VPN 连接在 Amazon 一侧的 VPN 集中器。
VPC 对等 VPC 对等允许你连接两个 VPC，使你能够使用私有 IPv4 或 IPv6 地址在它们之间路由流量。
Transit Gateway AWS Transit Gateway 充当网络传输枢纽，使你能够将多个 VPC、VPN 和 AWS 账户连接在一起。
VPC 端点（网关） VPC 端点（网关类型）允许你私下将 VPC 连接到支持的 AWS 服务和由 PrivateLink 供电的 VPC 端点服务，而无需互联网网关、VPN。
VPC 端点（接口） 接口 VPC 端点（由 AWS PrivateLink 供电）在 VPC 和支持的 AWS 服务、其他 VPC 或 AWS Marketplace 服务之间启用私有连接，而无需 IGW、VGW 或 NAT 设备。
SaaS Private Link 连接 AWS PrivateLink 在 VPC 和托管在 AWS 或本地的服务之间提供私有连接，非常适合安全访问 SaaS 应用。
15 个改变世界的开源项目
为了列出这个列表，我们试图查看这些项目对行业和相关技术产生的整体影响。此外，我们专注于导致世界各地许多软件开发人员日常生活发生重大变化的项目。
Web 开发
- Node.js：跨平台服务器端 JavaScript 运行时，将 JS 带到服务器端开发
- React：成为许多 Web 开发框架基础的库
- Apache HTTP Server：企业和初创公司都喜爱的高度多功能 Web 服务器。多年来启发了许多其他 Web 服务器
数据管理
- PostgreSQL：开源关系数据库管理系统，为昂贵的系统提供了高质量的替代方案
- Redis：超级多功能的数据存储，可用作缓存、消息代理，甚至通用存储
- Elasticsearch：搜索、分析和可视化大量数据的可扩展解决方案
开发者工具
- Git：免费开源版本控制工具，允许全球开发者协作
- VSCode：世界上最流行的源代码编辑器之一
- Jupyter Notebook：允许开发者共享实时代码、方程、可视化和叙述文本的 Web 应用
机器学习和大数据
- Tensorflow：利用机器学习技术的首选
- Apache Spark：大数据处理和分析平台的标准工具
- Kafka：构建实时数据管道和应用的 стандарт平台
DevOps 和容器化
- Docker：开源解决方案，允许开发者以一致和便携的方式打包和部署应用
- Kubernetes：云原生架构的核心和管理多个容器的平台
- Linux：民主化软件开发世界的操作系统
6 大数据模型
下图显示了前 6 大数据模型。
平面模型：平面数据模型是最简单的数据库模型形式之一。它将数据组织成一个单一表，其中每行代表一个记录，每列代表一个属性。此模型类似于电子表格，易于理解和实现。然而，它缺乏有效处理数据实体之间复杂关系的能力。
层次模型：层次数据模型将数据组织成树状结构，其中每个记录有一个父节点但可以有多个子节点。此模型在数据实体之间有清晰的”父子”关系的场景中是高效的。然而，它在处理多对多关系时会遇到困难，并且可能变得复杂和僵化。
关系模型：由 E.F. Codd 于 1970 年引入，关系模型在表（关系）中表示数据，由行（元组）和列（属性）组成。它通过使用键和规范化支持数据完整性并避免冗余。关系模型的优势在于其灵活性和查询语言 SQL（结构化查询语言）的简单性，使其成为传统数据库系统使用最广泛的数据模型。它有效地处理多对多关系并支持复杂查询和交易。
星型模式：星型模式是数据仓库中用于 OLAP（在线分析处理）应用的专用数据模型。它包含一个中央事实表，其中包含可测量的定量数据，周围是包含与事实数据相关的描述性属性的维度表。此模型针对分析应用中的查询性能进行了优化，通过最小化查询所需的连接数量提供简单性和快速数据检索。
雪花模式：雪花模式是星型模式的变体，其中维度表被规范化成多个相关表，减少冗余并提高数据完整性。这导致类似雪花的结构。虽然雪花模式由于连接数量增加可能导致更复杂的查询，但它在存储效率方面提供优势，并且在维度表很大或频繁更新的场景中可能是有利的。
网络模型：网络数据模型允许每个记录有多个父节点和子节点，形成可以表示数据实体之间复杂关系的图结构。此模型通过有效处理多对多关系克服了层次模型的一些限制。
分布式系统中的心跳检测机制
下图显示了前 6 个心跳检测机制。
心跳机制在分布式系统中对于监控各种组件的健康和状态至关重要。以下是分布式系统中常用的几种心跳检测机制：
推送式心跳：最基本的心跳形式涉及从一个节点到另一个节点或到监控服务的周期性信号。如果心跳信号在指定间隔内停止到达，系统假定节点已故障。这很简单，但网络拥塞可能导致误报。
拉取式心跳：节点不主动发送心跳，中央监控器可能定期从节点”拉取”状态信息。它减少网络流量，但可能增加故障检测延迟。
带健康检查的心跳：这包括心跳信号中关于节点健康的诊断信息。此信息可以包括 CPU 使用率、内存使用率或应用特定指标。它提供关于节点的更详细信息，允许更细致的决策。然而，它增加了复杂性和潜在的网络开销。
带时间戳的心跳：包括时间戳的心跳可以帮助接收节点或服务确定节点是否存活，以及是否有网络延迟影响通信。
带确认的心跳：心跳消息的接收者必须在此模型中发送回确认。这不仅确保发送者存活，而且发送者和接收者之间的网络路径也是功能性的。
带法定人数的心跳：在一些分布式系统中，特别是涉及如 Paxos 或 Raft 等共识协议的系统，使用法定人数（大多数节点）的概念。心跳可能用于建立或维持法定人数，确保有足够的节点运行以供系统做出决策。这在实现和管理节点加入或离开系统时的法定人数变化方面带来复杂性。
本文为学习目的的个人翻译，译文仅供参考。
原文链接：EP103: Typical AWS Network Architecture in One Diagram。
版权归原作者或原刊登方所有。本文为非官方译本；如有不妥，请联系删除。