使用Azure云原生构建博客是怎样一种体验?(上篇)

2019-07-22 10:52:12 浏览数 (1)

导语

https://edi.wang

我的网站是在.NET Core 平台上使用 C#语言编写的开源博客系统,运行于微软智慧云 Azure 国际版上。

本文将重点介绍 Azure 的各项服务如何为博客带来丝滑体验与保驾护航。

历史回顾

我博客的历史可以追溯到2003年,而.NET 版博客最初在10年前由 ASP.NET 2.0 WebForm VB Access 数据库构建,逐步维护升级至今,使用 ASP.NET Core MVC Azure SQL 数据库。

目前系统代号为“Moonglade”(月神湖),是对上一版.NET Framework 博客(代号“Nordrassil”)的完全重写。

针对单用户博客,极度精简,去除了上一版本设计中过度的多用户权限管理、多级分类、MetaWeblog 接口、文章审核工作流等无用组件,并针对云原生环境设计。

博客目前部署在微软公有云 Azure 国际版的 East Asia 地区。排除国内网络因素后,访问速度几乎是秒开。服务器响应平均速度6.5 ms,页面加载平均速度4s(受国内网络影响,使用“正常”连接可以达到1.5-2s)。曾经被许多人怀疑说不可能是.NET 写的,(毕竟说好的.NET 性能差呢),Entity Framework 说好的性能差呢。其实这不仅需要.NET 和 SQL 代码优化,Azure 的服务在其中也功不可没。

接下来为大家详细介绍 Azure 如何助力博客实现质的飞跃

WHY AZURE GLOBAL

为什么选择国际版

6年前 Azure 在大中华区落地后,我曾经第一时间把博客系统迁移到国内版,毕竟访问速度明显优于国际版。但却发现大中华区 Azure 的功能相比国际版通常要落后很长一段时间才能落地。一些非常重要功能,如 Application Insight 至今无法使用。

即使功能落地,也经常是部分功能可使用,在网站方面还会受到一些规定的影响。另外,由于博客目前主要面向国外社区,因此我也要考虑全球访问速度的因素,这些让我把网速和钱包的因素抛在脑后,选择世界领先的国际版 Azure。

当然,如果各位的业务主要集中于大中华区,又想充分使用 Azure,最适合的还是国内版 Azure,但国内 Azure 并非微软运营,请仔细慎重评估后再使用。

App Service Azure SQL Database

这两项服务是博客的核心,也是博客系统最早上云时采用的唯一两项服务。能够将 VM 或是本地数据中心部署网站需要的一天或几天,缩短到十几分钟。而且价格上也比使用 VM 方式部署网站便宜不少。

图 | 网络

App Service

App Service 是 Azure 上的一种 PaaS 服务。相比传统虚拟机部署网站,App Service 提供了一个完全托管的平台,让用户无需关心如何安装配置虚拟机,只需要使用上面的 Web 服务即可。至于底层的系统补丁、网站运行环境、Web 服务器配置,都已经由微软自行管理。

因此,程序员和运维人员再也不需要996进 ICU,就能在几分钟内建完网站环境,而传统方式可能需要数小时甚至数天

本地机房/虚拟机部署网站的缺点

✘ 又双叒叕打补丁

✘ 手工安装/升级运行环境(IIS、.NET、Python)

✘手工配置网站程序(环境变量、路径、config)

✘手工连接 CI/CD(安装web deploy、FTP)

✘ 手工配置 IP,网络,生产/ ST 环境、负载均衡

✘ 网站爆了,手工上服务器看文件目录、抓 dump

✘ 难以弹性伸缩

App Service 云原生部署网站

✔ 完全托管的平台

✔ 面向全球拓展业务

✔ 快速构建、部署和缩放

✔ 智能监控、故障定位

✔ 满足严苛的性能、可缩放性、安全性要求

✔ 运维成本低于本地数据中心

Azure Portal 在网页端提供了非常完整的管理界面,可以用来完成所有部署(包括不同环境)、诊断、设置、备份、缩放实例、绑定域名/SSL 等几十种操作。

.NET虽然应当成为正确的选择,但微软并没有只支持自家.NET。你可以选择 Node.js、PHP、Python 或其他语言,同样能使用 App Service 的几乎全部体验,甚至可以选择 Linux/Docker 的底层机器。

除了每个网站都会配置的域名、SSL 等基础功能,博客使用了一部分 App Service 的其他功能。

部署槽

该功能的用途是创建和切换不同环境。如我的博客仅有 staging 和 production 两个环境。代码从 Azure DevOps 的持续集成自动发布到非常接近于 production 的 staging 环境,测试完成后,再手动触发 production 环境的部署。Azure 可以做无缝切换两个环境,让你的应用程序几乎是 zero down time,就算爆了,你也可以偷偷切回来,假装没爆过。

图 | 网络

而传统上如果部署爆了,通常需要回滚操作,这段时间内用户肯定会截图给你发微博上庆祝你的爆。所以,我的博客之所以看起来一直非常稳定,并不是每次我写的代码都不爆,而是爆了大家也不知道(手动doge)。

备份

传统 VM 或本地数据中心做备份要么人工操作,要么自己写一套复杂的脚本,或者配合系统定时任务操作,或者购买三方产品,非常麻烦,容易996进 ICU。而 Azure App Service 可以在网页端点点鼠标,几分钟内配置定时自动备份,而且包含数据库一起打包。网站爆掉的时候,可以一键选择备份文件进行回档操作,减少损失。你也可以随时下载备份包,以便还原到本地环境。

扩大

Azure App Service 可以点点鼠标就在几分钟内轻松配置缩放规则。例如,当 CPU 使用率在1分钟内达到平均70%以上,持续10分钟,就自动增加一个实例。而传统 VM 或本地数据中心要配置这样的缩放规则,很容易996进ICU。

高级工具

Kudu 是一个微软的开源工具,由 ASP.NET(可惜不是Core)构建,它正是 App Service 的幕后英雄。可以发布、管理、诊断 IIS 上的网站。微软不仅免费开源了这个工具,也将它整合到了 Azure Portal,通过它,我能查看和操作博客服务器的高级功能。

Kudu 不仅可以查看应用设置、服务器环境变量、浏览或编辑网站目录文件、查看实时 log stream,还能查看 IIS、node、dotnet 等进程,并下载 dump 文件用于本地 debug。简直就是个网站应用的瑞士军刀。

Kudu 项目源代码传送门

https://github.com/projectkudu/kudu

App Service 的其他功能也很实用。例如,你可以在“拓展”里找到能够全自动续命、全自动配置免费SSL证书的 Let's encrypt 服务;在 Web Jobs 里跑定时任务,而不用自己996折腾任务框架进 ICU;还能0代码实现登录验证等等,本文篇幅有限,不逐一介绍。

使用传送门了解 App Service

https://azure.microsoft.com/en-us/services/app-service/


图 | 网络

Azure SQL Database

和 App Service 类似,Azure SQL Database 是一个完全托管的数据库服务,包含 SQL Server 的几乎全部功能,也支持 My SQL。使用 Azure SQL Database 就意味着你也无须关心如何安装和配置数据库运行环境,不用给机器打补丁,不用纠结防火墙配置,所有常用操作都在 Azure Portal 里点点鼠标就能分分钟完成。

Azure托管的SQL Server数据库可以用你熟悉的工具管理,如SSMS、Azure Data Studio。

为了保证数据库安全性,默认情况下,Azure 允许内部服务访问数据库(你可以随时禁用/启用这项设置),但会把其他公网IP排除在外。你可以在网页端,或SSMS、Azure Data Studio中添加IP白名单。

更牛逼的是,SQL数据库并不是只托管就完事了,Azure 还提供了数据安全(包括合规,比如对敏感数据打码)、性能优化服务,可以分析哪些SQL Query最慢,给出准确的调优建议,也能自动找到需要加索引的位置,甚至可以帮你自动加索引。可惜我除了CRUD以外并不了解数据库技术,所以无法给大家深入介绍。

使用传送门了解 Azure SQL Database

https://azure.microsoft.com/en-us/services/sql-database/


图 | 网络

DNS, CDN, Blob Storage, Azure AD, Application Insights, Azure DevOps 等更多精彩内容请听下回分解

微软最有价值专家 汪宇杰

.NET, Windows, Azure 技术分享

博客地址 https://edi.wang

0 人点赞