C1-03-01-为什么需要统一案例？
与GlobalShop-是什么？
与用户范围与核心业务模块与流量模型与用户第一次访问网站与全球用户为什么不能全部直接访问东京？
与用户请求进入系统以后与Web-和业务计算与为什么不能只用一台-EC2？
与双十一怎么自动加服务器？
与商品图片存哪里？
与EC2-自己的系统盘怎么办？
与订单存哪里？
与所有数据都应该放-RDS-吗？
与热门商品访问太多怎么办？
与下单为什么需要-Message-Queue？
与一条消息发给很多系统怎么办？
与GlobalShop-怎么管理员工权限？
与数据怎么加密？
与怎么知道系统快不快？
与怎么知道谁改坏了-Security-Group？
与怎么知道资源以前是什么配置？
与GlobalShop-怎么处理全球故障？
与公司以前还有本地机房怎么办？
与GlobalShop-怎么知道钱花在哪里？
与GlobalShop-一张总业务图与本章小结
本篇是《C1-03-GlobalShop全球电商业务模型》的第1个分篇，主要包含：为什么需要统一案例？
GlobalShop-是什么？
用户范围、核心业务模块、流量模型、用户第一次访问网站、全球用户为什么不能全部直接访问东京？
用户请求进入系统以后、Web-和业务计算、为什么不能只用一台-EC2？
双十一怎么自动加服务器？
商品图片存哪里？
EC2-自己的系统盘怎么办？
订单存哪里？
所有数据都应该放-RDS-吗？
热门商品访问太多怎么办？
下单为什么需要-Message-Queue？
一条消息发给很多系统怎么办？
GlobalShop-怎么管理员工权限？
数据怎么加密？
怎么知道系统快不快？
怎么知道谁改坏了-Security-Group？
怎么知道资源以前是什么配置？
GlobalShop-怎么处理全球故障？
公司以前还有本地机房怎么办？
GlobalShop-怎么知道钱花在哪里？
GlobalShop-一张总业务图、本章小结。
1-为什么需要统一案例？
如果学习 AWS 时不断看到：A公司、B公司、一家媒体公司、一家银行、一家医院、一家游戏公司。
技术虽然很多，但很难形成系统。
因此整套教材采用统一的：作为主业务。
2-GlobalShop-是什么？
【教学示例】。
GlobalShop 是一家虚构的全球电子商务企业。
可以把业务规模想象成：Amazon + 淘宝 + 京东。
的某种简化教学模型。
不是在描述任何真实公司的技术架构。
3-用户范围
GlobalShop 面向：日本、韩国、新加坡、美国、加拿大、英国、法国、德国、...。
的消费者。
主要团队位于东京。
4-核心业务模块
GlobalShop
│
├── 用户中心
│ ├── 注册
│ ├── 登录
│ ├── Profile
│ └── 地址
│
├── 商品中心
│ ├── 商品
│ ├── 分类
│ ├── SKU
│ ├── 价格
│ └── 商品状态
│
├── 媒体中心
│ ├── 商品图片
│ ├── 商品视频
│ └── 用户上传图片
│
├── 搜索
│
├── 推荐
│
├── 购物车
│
├── 优惠券
│
├── 订单
│
├── 库存
│
├── 支付
│
├── 物流
│
├── 消息通知
│ ├── Email
│ ├── SMS
│ └── Push
│
├── 客服
│
├── 商家后台
│
├── 风险控制
│
├── 日志
│
└── 数据分析
这一套业务足够覆盖 CLF-C02 中绝大多数技术。
5-流量模型
普通工作日：
日活：
1,000,000
同时在线：
50,000
Web请求：
相对稳定
双十一：
日活：
30,000,000
瞬时请求：
可能是平时几十倍
20:00抢购：
出现流量尖峰
因此 GlobalShop 必须解决：★★★★★ Scalability。
可扩展性。
★★★★★ Elasticity。
弹性。
★★★★★ High Availability。
高可用性。
6-用户第一次访问网站
第一件事不是访问 EC2。
浏览器首先需要知道：
这个域名应该去哪里？
所以出现：★★★★★ Amazon Route 53。
负责：DNS。
完整英文：Domain Name System，中文为：域名系统。
以后会详细讲：
domain
域名
DNS record
DNS记录
routing
路由策略
7-全球用户为什么不能全部直接访问东京？
假设所有原始商品图片都存储在东京。
美国用户每次看商品：
美国用户
│
│ Internet
│
│ 跨太平洋
▼
Tokyo
│
▼
S3
│
▼
原图返回美国
这会增加：Latency，中文为：网络延迟。
于是出现：★★★★ Amazon CloudFront。
它属于：CDN = Content Delivery Network，中文为：内容分发网络。
GlobalShop 可以把商品图片缓存到更靠近用户的网络节点。
8-用户请求进入系统以后
简化：
Users
│
▼
Route 53
│
▼
CloudFront
│
▼
WAF / Shield
│
▼
Load Balancer
│
┌┴───────────┐
▼ ▼
EC2 EC2
这里已经出现四类完全不同的问题：
Route 53
→ 地址在哪里
CloudFront
→ 怎么让全球访问更快
WAF / Shield
→ 怎么保护入口
Load Balancer
→ 请求怎么分给多台服务器
9-Web-和业务计算
GlobalShop 的：商品服务、订单服务、库存服务、后台系统。
需要计算资源。
最经典：★★★★★ Amazon EC2。
EC2 = Elastic Compute Cloud，中文为：弹性计算云。
可以运行：Java、Node.js、Python、Go、.NET、...。
应用。
10-为什么不能只用一台-EC2？
如果
Users
│
▼
EC2
一旦这台 EC2：Crash、宕机。
整个网站：X。
因此：
Users
│
▼
Load Balancer
│
┌┼──────┐
▼▼ ▼
EC2 EC2 EC2
形成冗余。
11-双十一怎么自动加服务器？
★★★★★ AWS Auto Scaling。
平时：EC2 × 20。
高峰：EC2 × 200。
凌晨：EC2 × 20。
这就是后续理解：Elasticity、Auto Scaling、Load Balancing。
的统一业务场景。
12-商品图片存哪里？
GlobalShop 有：5亿张商品图片如果全部塞进数据库：问题很多。
商品图片适合：★★★★★ Amazon S3。
S3 = Simple Storage Service，中文为：简单存储服务。
它属于：Object Storage，中文为：对象存储。
基本模型：
Bucket
桶
│
├── object-a.jpg
├── object-b.mp4
└── object-c.pdf
13-EC2-自己的系统盘怎么办？
运行服务器还需要类似磁盘的东西。
于是：★★★★ Amazon EBS。
EBS = Elastic Block Store，中文为：弹性块存储。
典型关系：
EC2
│
▼
EBS
后续会详细解释：
S3 = Object Storage
EBS = Block Storage
EFS = File Storage
为什么是三个完全不同的模型。
14-订单存哪里？
订单数据通常有：订单ID、用户ID、商品、价格、状态、支付状态、地址、创建时间，而且存在：关系、事务、查询。
因此传统关系数据库非常合适。
GlobalShop 可以使用：★★★★★ Amazon RDS。
RDS = Relational Database Service，中文为：关系型数据库服务。
或者：★★★★★ Amazon Aurora。
AWS 的关系数据库产品。
15-所有数据都应该放-RDS-吗？
不是。
GlobalShop 可能还有：用户Session、购物车、高规模Key-Value访问。
某些业务更适合：★★★★★ Amazon DynamoDB。
一种 AWS 托管的 NoSQL 数据库。
所以以后真正的问题不是。
RDS 是什么？
而是
订单为什么适合RDS/Aurora？
什么数据适合DynamoDB？
为什么S3不能代替RDS？
为什么Redis/ElastiCache又不是数据库的简单替代？
16-热门商品访问太多怎么办？
一个爆款商品：iPhone。
一分钟可能被查询数百万次。
如果每个请求都直接：
Application
│
▼
Database
数据库压力很大。
可以增加：★★★★ Amazon ElastiCache。
内存缓存。
结构：
Application
│
▼
ElastiCache
│
命中
├────────→ 返回
│
未命中
▼
Database
17-下单为什么需要-Message-Queue？
一个用户点击：购买。
背后可能发生：创建订单、扣库存、发送邮件、更新积分、通知物流、数据分析、风控、推荐更新。
如果所有步骤串行：
A
↓
B
↓
C
↓
D
↓
E
任何一步慢，都可能让用户一直等。
所以系统需要：★★★★ Amazon SQS。
SQS = Simple Queue Service，中文为：简单队列服务。
实现：
订单创建成功
│
▼
SQS
┌───┼─────┬──────┐
▼ ▼ ▼ ▼
邮件 库存 物流 数据分析
后续会系统解释：
Queue
消息队列
Asynchronous
异步
Decoupling
解耦
18-一条消息发给很多系统怎么办？
可以考虑：★★★ Amazon SNS。
SNS = Simple Notification Service，中文为：简单通知服务。
典型：
订单事件
│
▼
SNS
┌─┼─────┐
▼ ▼ ▼
SQS Email SMS
这涉及：Publish / Subscribe。
简称：Pub/Sub，中文为：发布 / 订阅模式。
19-GlobalShop-怎么管理员工权限？
不可能让所有员工都拥有：Administrator。
权限。
于是：★★★★★ AWS IAM。
IAM = Identity and Access Management，中文为：身份与访问管理。
例如：
开发人员
→ 可以查看开发环境
DBA
→ 管理数据库
财务人员
→ 查看账单
EC2
→ 只能读取指定S3 Bucket
题库甚至直接有：
EC2 应该通过 IAM Role 获取访问 S3 的权限，而不是把 Access Key 硬编码到程序里。
20-数据怎么加密？
GlobalShop 存：用户地址、订单、支付相关信息、商业数据。
加密会涉及：★★★★ AWS KMS。
KMS = Key Management Service，中文为：密钥管理服务。
核心不是。
KMS 存文件。
而是
管理 Encryption Key —— 加密密钥。
21-怎么知道系统快不快？
GlobalShop 运维人员想看：CPU、请求量、错误率、Latency、资源指标、Logs。
于是：★★★★★ Amazon CloudWatch。
Cloud + Watch：可以直观理解成：**观察云中的系统。
**。
22-怎么知道谁改坏了-Security-Group？
假设凌晨：
Security Group
从：
443 only
变成：
0.0.0.0/0
all ports
安全团队需要知道：
谁改的？
这时候不是 CloudWatch。
而是 ★★★★★ AWS CloudTrail。
Trail：足迹 / 轨迹。
记录 AWS API 活动。
23-怎么知道资源以前是什么配置？
如果想知道：
这个 Security Group
昨天是什么样？
今天是什么样？
是否满足公司规则？
则：★★★★ AWS Config。
Config 来自：Configuration，中文为：配置。
所以形成第一组极高频对比：
CloudWatch
→ 系统运行得怎么样？
CloudTrail
→ 谁做了什么AWS操作？
Config
→ AWS资源是什么配置、怎么变化？
24-GlobalShop-怎么处理全球故障？
主要业务在：Tokyo Region。
内部至少跨：AZ-A、AZ-B。
部署：
Load Balancer
│
┌─┴────────┐
▼ ▼
AZ-A AZ-B
EC2 EC2
这叫：★★★★★ Multi-AZ，中文为：多可用区架构。
用于高可用。
更进一步可能：
Tokyo Region
│
│ replication / backup
▼
Osaka Region
用于更大范围的：★★★★ Disaster Recovery。
灾难恢复。
25-公司以前还有本地机房怎么办？
GlobalShop 不一定一夜之间全部迁 AWS。
旧系统可能仍在东京自己的：On-Premises Data Center、本地数据中心。
于是出现：VPN、Direct Connect、Storage Gateway、DataSync、DMS、Application Migration Service、Snow Family。
这就是：Hybrid Cloud，中文为：混合云。
以及：Cloud Migration，中文为：云迁移。
26-GlobalShop-怎么知道钱花在哪里？
双十一扩容之后：本月AWS账单：、$1,000,000。
财务部门马上会问：
钱花哪儿了？
对应：★★★★ AWS Cost Explorer。
成本分析工具。
如果问：
本月超过 80 万美元就提醒我。
对应：★★★★ AWS Budgets。
预算管理。
如果问：
双十一系统还没上线，先估算大概要多少钱。
对应：★★★★ AWS Pricing Calculator。
定价计算器。
27-GlobalShop-一张总业务图
Global Users
Japan / US / Europe / Asia
│
▼
Route 53
│
▼
CloudFront
│
WAF / Shield
│
▼
Load Balancer
│
┌────────────────┴─────────────────┐
│ Tokyo Region │
│ │
│ VPC │
│ │
│ AZ-A AZ-B │
│ │ │ │
│ EC2 EC2 │
│ │ │ │
│ └────────┬──────────┘ │
│ │ │
│ Auto Scaling │
│ │ │
│ ┌──────────┼───────────┐ │
│ ▼ ▼ ▼ │
│ Aurora DynamoDB ElastiCache │
│ │
└──────────────────────────────────┘
│
▼
S3
商品图片 / 文件 / 日志
订单异步链路：
Application
│
▼
SQS
┌──┼────┬─────┐
▼ ▼ ▼ ▼
通知 库存 物流 分析
安全与治理：
IAM
KMS
GuardDuty
Inspector
监控：
CloudWatch
CloudTrail
Config
成本：
Cost Explorer
Budgets
Pricing Calculator
后面的所有章节，本质上都是在逐渐把这张图展开。
28-本章小结
GlobalShop 的意义在于：
AWS服务
不再是：
EC2 / S3 / RDS / IAM / VPC
一堆单词
而变成：
用户访问
↓
网络
↓
计算
↓
存储
↓
数据库
↓
异步消息
↓
安全
↓
监控
↓
成本
本篇概述
- 本篇梳理了为什么需要统一案例？
相关的核心知识、适用场景与判断要点。
- 本篇梳理了GlobalShop-是什么？
相关的核心知识、适用场景与判断要点。
- 本篇梳理了用户范围相关的核心知识、适用场景与判断要点。
- 本篇梳理了核心业务模块相关的核心知识、适用场景与判断要点。
- 本篇梳理了流量模型相关的核心知识、适用场景与判断要点。
- 本篇梳理了用户第一次访问网站相关的核心知识、适用场景与判断要点。
- 本篇梳理了全球用户为什么不能全部直接访问东京？
相关的核心知识、适用场景与判断要点。
- 本篇梳理了用户请求进入系统以后相关的核心知识、适用场景与判断要点。
- 本篇梳理了Web-和业务计算相关的核心知识、适用场景与判断要点。
- 本篇梳理了为什么不能只用一台-EC2？
相关的核心知识、适用场景与判断要点。
- 本篇梳理了双十一怎么自动加服务器？
相关的核心知识、适用场景与判断要点。
- 本篇梳理了商品图片存哪里？
相关的核心知识、适用场景与判断要点。
- 本篇梳理了EC2-自己的系统盘怎么办？
相关的核心知识、适用场景与判断要点。
- 本篇梳理了订单存哪里？
相关的核心知识、适用场景与判断要点。
- 本篇梳理了所有数据都应该放-RDS-吗？
相关的核心知识、适用场景与判断要点。
- 本篇梳理了热门商品访问太多怎么办？
相关的核心知识、适用场景与判断要点。
- 本篇梳理了下单为什么需要-Message-Queue？
相关的核心知识、适用场景与判断要点。
- 本篇梳理了一条消息发给很多系统怎么办？
相关的核心知识、适用场景与判断要点。
- 本篇梳理了GlobalShop-怎么管理员工权限？
相关的核心知识、适用场景与判断要点。
- 本篇梳理了数据怎么加密？
相关的核心知识、适用场景与判断要点。
- 本篇梳理了怎么知道系统快不快？
相关的核心知识、适用场景与判断要点。
- 本篇梳理了怎么知道谁改坏了-Security-Group？
相关的核心知识、适用场景与判断要点。
- 本篇梳理了怎么知道资源以前是什么配置？
相关的核心知识、适用场景与判断要点。
- 本篇梳理了GlobalShop-怎么处理全球故障？
相关的核心知识、适用场景与判断要点。
- 本篇梳理了公司以前还有本地机房怎么办？
相关的核心知识、适用场景与判断要点。
- 本篇梳理了GlobalShop-怎么知道钱花在哪里？
相关的核心知识、适用场景与判断要点。
- 本篇梳理了GlobalShop-一张总业务图相关的核心知识、适用场景与判断要点。
- 本篇梳理了本章小结相关的核心知识、适用场景与判断要点。