Azure 入门系列 (第五篇 Azure Storage)

本系列

这个系列会介绍从 0 到 1 搭建一个 Web Application 的 Server. 间中还会带上一些真实开发常用的功能.

一共 6 篇

1. Virtual Machine (VM) 和 SQL Server

2. Backup & Recovery Disaster

3. Publish Web Application to VM (IIS, HTTPS)

4. Azure Key Vault

5. Azure Storage (with custom domain) <-- 你在这里

6. Computer Vision (smart-cropped thumbnails, OCR)

以前的学记笔记:

Data protection

Azure Storage

Secret 和 Data Protect Azure key-vault & Storage Account 第 2 篇

When to use it?

Serve static files

网站最佳实践说, 静态文件 (图片, js, css 等) 尽可能分开处理.

一是为了减轻服务器压力, 二是可以做 CDN 优化速度, 所以 storage 自然就是首选方案了.

这里提一下它的代价. 在关于磁盘里有提到 VM Disk, Azure 默认的 VM OS Disk 是 125GB (可以增加).

如果使用 storage 处理静态文件, 意味着 OS Disk 的 100 GB 基本上是空着的 (有点浪费), storage 要配上 custom domain https 的话, 一定要 CDN

那边又是一笔费用了. 我个人的意见是, 如果 VM 没有需要减压, 也没有要 CDN 做优化. 那不推荐使用 storage, 把 static file 让 VM 处理就好了呗.

除了解压和 CDN 优化, 还有一种情况必须要用 storage 就是 files 太多, 企业应用需要保存很多 document pdf, 又不可以丢掉, 日子久了就会非常多. 这时用 disk 很不划算.

但是如果把整个文件管理换成 storage 也很伤 (下面会讲到几个难点). 所以比较 trade-off 的方案是, 做定时器, 把比较旧的资料搬过去 storage. 然后 server as 一个代理.

这样降低了 VM disk -> storage 的负面影响和 migration 代价, 只有在访问旧文件的时候才可能出现不好的情况. 这样就比较可以接受了.

参考:

Why you should use a Cookie-less domain for serving your static content (CDN)

Serve static content from a cookieless domain

一文看懂CDN加速原理

SEO Help us discover all your images

Data Protection

Data protection 需要一个地方存放 Keys 的 xml 文件. 如果有多台 VM 的话, 就需要把这个 xml 存在一个中心, 好让所有 VM 可以一直访问.

Storage 自然就是好地方. 但如果只有 1 台 VM 的话, 把 xml 存在 VM 里也是 ok 的.

VM Disk -> Storage 遇到的难点

VM disk 在 ASP.NET Core 就是直接 static files 获取就对了, 一切简简单单.

转去 Storage 会遇到不少问题

Domain 换了

这个问题不大, 有些大公司也不 care. 比如

https://s3.amazonaws.com/cdn.freshsales.io/130644/documents/17000031818/original/1642066047884495_avatar_yangmi.jpg

这个是 freshworks 的图片路径, 用的是 AWS 的 storage, 如果真的不喜欢也可以换成 custom domain. 下面有教

权限访问

Storage 比较难做权限管理, 图片嘛, 要做权限有 2 个方式, 第一个是用 cookie, 第二个是用 query params.

没办法用 header bearer token 搞.

cookie 的话需要搞 Azure AD 让用户登入.. 这个有点...大工程了

query params 就需要维护一个 SAS 创建. 但是 cache 方面就不太能做了. 毕竟 query params 做权限的话, 最多 1 天就得换了. 而游览器缓存是基于 full url 的, 所以多少影响到.

freshworks 也是用 SAS 方式做的哦.

Pre-process

pre-process 主要是讲 upload 的时候, 通常会做一些缩略图, 压缩, convert to webp 之类的动作.

方案 1 就是先 upload 到 VM 处理了在存入 storage.

方案 2 是让 browser js 处理, 或者让 Azure Function 处理, Storage 可以 set 一个 on uploaded run Azure Funtion 的

我选方案 1

性能

read file 走 CDN 会比 disk 快, 这也是它主要的好处啦. 但是如果 server as proxy 的话就慢多了.

browser -> CDN -> storage = 快

browser -> server -> disk = 普通

browser -> server -> storage 比 to disk 慢一倍左右, 我拿了 100mb 的 file 做测试, 直接读 disk vs get from storage. (disk maybe < 1 sec, storage 大概 2-3 sec)

upload 的话也是 t

browser -> server -> disk = 普通

browser -> server -> storage 比 to disk 慢一倍左右, 我拿了 100mb 的 file 做测试, 直接写入 disk vs upload to from storage. (disk 1 sec 左右, storage 3sec 左右)

Storage 小知识

1. Storage 是独立的 server, 即使没有 VM 我们也可以访问到 Storage 里面的资料

2. Storage 结构是 Account > Container > Blob

3. Container 不是 folder, folder 是通过创建 blob 的时候给 path 来实现的

4. Blob 主要分 3 种, 用于图，视频，文件, 用于 DIsk, 用于 Log

5. Storage 有自己的 url 访问, 可以使用 Custom domain, 如果要 HTTPS 就要配上 Azure CDN

Storage Account & CDN & Custom Domain & HTTPS

参考:

Integrate an Azure Storage account with Azure CDN

Access storage blobs using an Azure CDN custom domain over HTTPS

Add a custom domain to your endpoint

Map a custom domain to an Azure Blob Storage endpoint

Configure HTTPS on an Azure CDN custom domain

Set up the Standard rules engine for Azure CDN

Create Storage Account

storage 的 redundancy 是 GRS, 所以不需要另外在 Recovery Services Vault 做 Disaster Recovery

它有一个 version control 的功能, 所以也不需要另外在 Recovery Services Vault 做 Backup

Create container

Create Blob

进入 container 就可以 upload blob 了, folder 是在这个阶段创建的哦, container 不是 folder

进入 blob 就可以拿到访问 blob 的 url 了.

Create CDN

Add Custom Domain To CDN

到 DNS 添加 CNAME record

到 endpoint 里创建 Custom domain

Enable HTTPS on Custom Domain

进入 custom domain 打开 HTTPS

这个过程需要大概 30 分钟, 等就对了

Add Rule Engine Enforce HTTPS

访问 https://static.jbreviews.com.my/static/images/yangmi.jpg 搞定