网站备案 申请怎么做电商卖东西

目录

一、子网与VPC

1. 子网 vs. VPC 的核心区别

2. 为什么需要 VPC 隔离？

(1) 多租户或多项目隔离

(2) 安全合规要求

(3) 避免 IP 地址冲突

(4) 灵活的网络架构

3. 实际场景示例

(1) 多团队协作

(2) 跨区域灾备

4. 子网隔离的局限性

总结

二、Route53与ELB

1. 核心功能

2. 工作层级

3. 典型场景

4. 协同使用

总结

1. 自定义域名与用户体验

2. 高级流量路由策略

3. 根域名（Zone Apex）支持

4. 健康检查与自动容灾

5. 多服务集成

总结

1. CNAME 记录 vs. Alias 记录

2. 如何实现映射？

(1) 使用 Alias 记录（推荐）

(2) 使用 CNAME 记录（传统方式）

3. 为什么 ELB 需要域名映射？

总结

三、子网与路由表

1. 路由表的基本绑定关系

2. 路由表的默认行为

3. 典型场景示例

场景 1：公有子网与私有子网

场景 2：VPC 对等连接

4. 关键区别总结

5. 操作验证

常见问题

四、Security Group与NACL

  用户问题的澄清

    总结对比表

    最佳实践建议

五、面试题

一、云计算与AWS基础

二、核心服务解析

三、架构设计与高可用性

1. 事件驱动场景

场景示例

架构示例

2. 定时任务（ETL/批处理）

场景示例

架构示例

3. 微服务后端（API 驱动）

场景示例

架构示例

4. 事件总线集成（复杂事件路由）

场景示例

架构示例

是否需要搭配 EventBridge？

架构核心特点

四、安全与合规

五、成本优化

六、故障排查与运维

七、高级话题

八、常见面试场景题

备考建议

补充内容

一、核心服务补充细节

二、架构设计深化

三、安全与合规强化

四、成本与优化细节

五、运维与故障排查

六、高级服务与场景

七、企业级架构

八、面试陷阱题补充

九、实操场景题扩展

补充备考资源

---

一、子网与VPC

在 AWS 中，子网（Subnet） 和 VPC（Virtual Private Cloud） 虽然都涉及网络隔离，但它们的作用范围和设计目标不同。即使子网已经提供了网络分段能力，VPC 仍然是更高级别的隔离单元，尤其是在 1个 AZ 内有多个 VPC 或 多个 AZ 属于 1个 VPC 的场景下。以下是关键区别和实际需求：

---

1. 子网 vs. VPC 的核心区别

​​特性​​	​​子网（Subnet）​​	​​VPC（Virtual Private Cloud）​​
​​隔离层级​​	同一 VPC 内的网络分段（类似局域网内的 VLAN）	完全独立的虚拟网络环境（类似物理数据中心）
​​IP 地址范围​​	子网 CIDR 是 VPC CIDR 的子集（如 10.0.1.0/24）	定义整个 VPC 的 IP 池（如 10.0.0.0/16）
​​跨 AZ 通信​​	子网必须属于单一 AZ，跨子网需通过 VPC 路由表	VPC 可跨多个 AZ，子网间默认互通
​​安全策略​​	依赖 NACL（网络 ACL）和路由表	依赖安全组（Security Group）+ NACL + 路由表
​​多租户/多项目​​	无法隔离不同团队或项目	天然支持多租户隔离（如开发、测试、生产）

---

2. 为什么需要 VPC 隔离？

即使子网能隔离流量，VPC 提供了更高层次的逻辑隔离，适用于以下场景：

(1) 多租户或多项目隔离

• 问题：如果多个团队（如开发、测试、生产）共享同一个 VPC，即使子网不同，仍可能因配置错误导致跨环境访问（如误操作路由表）。

• VPC 解决方案：

  • 每个团队使用独立的 VPC，彻底隔离网络环境。

  • 例如：

    • VPC-Dev（开发）和 VPC-Prod（生产）完全隔离，即使子网 CIDR 相同（如 10.0.1.0/24），也不会互通。

(2) 安全合规要求

• 问题：某些合规标准（如 PCI DSS、HIPAA）要求严格隔离敏感数据环境。

• VPC 解决方案：

  • 将不同安全等级的资源放入不同 VPC（如 VPC-Secure 和 VPC-Public），通过 VPC Peering 或 Transit Gateway 按需可控互通。

(3) 避免 IP 地址冲突

• 问题：在大型企业或并购场景中，不同部门可能使用重叠的 IP 范围（如 10.0.0.0/16）。

• VPC 解决方案：

  • 每个部门使用独立的 VPC，即使 IP 重叠，也不会互相影响。

(4) 灵活的网络架构

• 问题：子网必须属于单一 AZ，而 VPC 可以跨 AZ 设计复杂架构。

• VPC 解决方案：

  • 单 VPC 跨多 AZ：适合高可用应用（如数据库主从跨 AZ 部署）。

  • 多 VPC 单 AZ：适合实验性环境或短期项目（如临时测试集群）。

---

3. 实际场景示例

(1) 多团队协作

• 开发团队：使用 VPC-Dev（子网 10.1.0.0/16）。

• 生产团队：使用 VPC-Prod（子网 10.1.0.0/16，相同 IP 范围但完全隔离）。

• 结果：开发环境的误操作不会影响生产环境。

(2) 跨区域灾备

• 主区域：VPC-Main（子网分布在 us-east-1a 和 us-east-1b）。

• 备份区域：VPC-DR（子网分布在 us-west-2a）。

• 结果：通过 VPC Peering 或 Transit Gateway 实现可控的跨区域通信。

---

4. 子网隔离的局限性

子网仅提供 同一 VPC 内的流量分段，但以下情况仍需 VPC：

• 需要完全隔离的网络边界（如不同公司或部门）。

• IP 地址重叠但需共存。

• 合规要求的强制隔离。

---

总结

• 子网：用于 同一 VPC 内 的 AZ 级流量分段（如 Web 层、DB 层）。

• VPC：用于 跨项目、跨团队、跨合规域 的完全隔离，是 AWS 网络隔离的核心单元。

• 最佳实践：

  • 小型项目：单 VPC + 多子网。

  • 中大型企业：多 VPC + 按需通过 Peering/TGW 连接。

通过 VPC 隔离，AWS 用户可以同时实现 灵活性 和 安全性，而子网仅是其底层实现的一部分。

二、Route53与ELB

Route 53（正确名称，非ROTE53）和ELB（Elastic Load Balancing）虽然都能将流量路由到健康的实例，但它们在功能、工作层级和应用场景上有显著区别：

1. 核心功能

• Route 53：

  • 是 DNS服务，负责域名解析和全局流量管理，支持多种路由策略（如延迟、地理位置、加权、故障转移等）。

  • 通过DNS查询将用户请求路由到最优的AWS区域或资源（如ELB、EC2等），但不直接处理流量转发。

  • 适用于跨区域或全球流量的智能路由（如将欧洲用户定向到法兰克福区域的ELB）。

• ELB：

  • 是 负载均衡器，在单个AWS区域内将流量分发到多个后端实例（EC2、容器等）。

  • 支持应用层（ALB/HTTP）和传输层（NLB/TCP）的流量分发，提供健康检查、会话保持等功能。

  • 不涉及DNS解析，需依赖Route 53将域名映射到ELB的DNS名称。

2. 工作层级

• Route 53：

  • 工作在 DNS层级（OSI第7层），影响用户请求的第一跳（解析域名到IP）。

  • 依赖DNS缓存，更新延迟受TTL影响（通常60秒）。

• ELB：

  • 工作在 传输层（NLB）或应用层（ALB），直接处理请求转发。

  • 实时移除不健康实例，无DNS缓存问题。

3. 典型场景

• Route 53：

  • 跨区域故障转移（如主区域故障时切换到备份区域）。

  • 基于用户地理位置或延迟的路由（如中国用户访问北京区域的ELB）。

• ELB：

  • 单区域内横向扩展（如一个区域的Web服务器集群）。

  • 微服务路由（ALB基于路径/主机头分发到不同目标组）。

4. 协同使用

两者常结合：

• Route 53 将域名解析到不同区域的 ELB，再由ELB在区域内分发流量。

• 例如：Route 53根据延迟选择美国或亚太区域的ELB，ELB再在该区域内均衡负载。

总结

• Route 53：全局DNS路由，决定用户访问哪个区域的资源。

• ELB：区域级流量分发，决定请求由哪个后端实例处理。

• 互补关系：Route 53解决“去哪”，ELB解决“怎么分”。

虽然ELB的域名（如 my-elb-1234567890.us-west-2.elb.amazonaws.com）是固定的，但使用 Route 53 仍然至关重要，主要原因如下：

1. 自定义域名与用户体验

• ELB域名不友好：ELB的自动生成域名复杂且不易记忆（如 my-elb-1234567890.us-west-2.elb.amazonaws.com），不适合直接面向用户。

• Route 53作用：将用户友好的自定义域名（如 example.com 或 app.example.com）通过 Alias记录 或 CNAME 映射到ELB域名，提升品牌形象和访问便捷性。

2. 高级流量路由策略

Route 53提供ELB不具备的智能路由能力：

• 基于延迟的路由：将用户请求自动导向延迟最低的AWS区域（如美国用户访问俄勒冈区域，亚洲用户访问新加坡区域）。

• 地理位置路由：按用户所在国家/地区定向流量（如欧洲用户访问法兰克福区域的ELB）。

• 故障转移与加权路由：根据后端健康状态动态切换流量，或按比例分配流量（如A/B测试）。

3. 根域名（Zone Apex）支持

• ELB限制：根域名（如 example.com）不能直接使用CNAME记录，但Route 53的 Alias记录 支持根域名绑定到ELB，而传统DNS服务无法实现。

4. 健康检查与自动容灾

• ELB健康检查：仅监控实例级别状态。

• Route 53健康检查：可监控整个ELB或外部端点，结合DNS故障转移实现跨区域容灾（如主区域故障时自动切换至备份区域）。

5. 多服务集成

Route 53不仅服务ELB，还支持：

• CloudFront、S3静态网站等其他AWS资源的域名绑定。

• 混合架构：统一管理云上云下资源的DNS解析（如通过条件转发规则）。

总结

• ELB域名固定：仅提供基础的负载均衡功能，依赖DNS解析。

• Route 53扩展能力：实现友好域名、智能路由、全局容灾和多云集成，是构建高可用、高性能架构的关键组件。

若仅用ELB域名，将丧失上述所有高级功能，且无法满足生产级需求。

是的，您可以通过 CNAME 记录 将自定义域名（如 example.com）映射到 ELB 的系统生成域名（如 my-elb-1234567890.us-west-2.elb.amazonaws.com）。但 AWS 更推荐使用 Alias 记录（别名记录），因为它在功能、性能和成本上更具优势。以下是两者的对比和实现方式：

---

1. CNAME 记录 vs. Alias 记录

​​特性​​	​​CNAME 记录​​	​​Alias 记录​​
​​支持根域名​​	不支持（如 example.com）	支持（可直接绑定根域名）
​​额外 DNS 查询​​	需要额外查询解析目标域名	直接指向 AWS 资源，无额外查询
​​费用​​	按查询次数计费	对 AWS 资源（如 ELB）的查询免费
​​适用场景​​	非 AWS 资源或传统 DNS 服务	AWS 资源（ELB、S3、CloudFront 等）

---

2. 如何实现映射？