Azure 入门系列 (第五篇 Azure Storage)
本系列
这个系列会介绍从 0 到 1 搭建一个 Web Application 的 Server. 间中还会带上一些真实开发常用的功能.
一共 6 篇
1. Virtual Machine (VM) 和 SQL Server
3. Publish Web Application to VM (IIS, HTTPS)
5. Azure Storage (with custom domain) <-- 你在这里
6. Computer Vision (smart-cropped thumbnails, OCR)
以前的学记笔记:
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
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 搞定
