一个基于Microsoft Azure、ASP.NET Core和Docker的博客系统
2008年11月,我在博客园开通了个人帐号,并在博客园发表了自己的第一篇博客。当然,我写博客也不是从2008年才开始的,在更早时候,也在CSDN和系统分析员协会(之后名为“希赛网”)个人空间发布过一些与编程和开发相关的文章。从入行到现在,我至始至终乐于与网友分享自己的所学所得,希望会有更多的同我一样的业内朋友能够在事业上取得成功,也算是为我们的软件事业贡献自己的一份力量吧,这也是我在博客园建博客时候的愿景:专业、求是、解惑。因此,我在撰写博客文章的时候,都是以客观严谨的态度来阐述技术知识,并尽可能地以更好的内容组织形式来提高文章的可读性,同时尽可能地回答网友的提问。有很多博客园的粉丝跟我提过意见,有的说我的博客更新太慢,也有的说我有些系列文章有烂尾现象,对于粉丝们的提问,我只有一个回答,那就是业余时间太有限,我没有办法凭靠自己一个人的力量,在有限的业余时间里,在保证文章品质的前提下,为社区提供越来越多的支持。在这一点上,我选择的是宁缺毋滥:宁可发布周期变长,也不希望把没有质量的文章分享出来。另一方面,我也发布了很多开源项目,有些项目属于我自己一些个人小工具的代码备份,也有一些项目,比如Apworks、Byteart Retail、WeText,甚至是我的新博客daxnet.me的源代码项目daxnet-blog,都在我的Github Repo里。说实话我真的没有时间把每个项目中的细节技术以博客的方式一一介绍清楚,因此,一般我基本完成了自己比较满意的开源项目时,我都会写一篇博客来介绍项目的内容和所使用的技术,同时引导读者直接克隆我的项目代码进行参阅,或者直接folk(不用太担心许可协议问题,除了Raspkate项目之外,其它绝大部分项目都是MIT或者Apache的许可协议)。总而言之,不管形式如何,我始终没有放弃过最初的愿景。
也是出于这样的坚持,我希望能够更好地组织我的博客文章,甚至是其它的一些原创作品,以更为集中和高效的方式为读者提供更好的学习交流体验,一直以来我都想过搭建属于自己的博客服务,我也经过了很多尝试。早在2012年,我使用Word Press在一个国外站点建立过博客系统,可是后来因为国外服务供应商的原因,网站没能继续维持下去,之后我也经过好几次的尝试,包括使用BlogEngine.NET等开源项目,可是也都没能做好。出于对技术的热衷与追求,这一次,我终于下定决心,使用自己所学的知识,依托微软的.NET平台,开发并部署了我自己的新博客系统:【http://daxnet.me】。
站点功能
首先简要介绍一下目前的站点功能吧。右图就是本站的主页效果,我做得很简洁,没有用太多花哨的图片,也没有用走马灯。明眼人一看就知道这是基于ASP.NET MVC而开发的Web应用程序,使用了Bootstrap。不错,基本答对!需要强调的是,这个博客站点以及后端的RESTful服务,全部都是基于ASP.NET Core完成的,.NET Core运行时版本为1.1.0,运行在Docker容器中。哎,说着说着又到技术上了,功能还没介绍完呢。说到功能,目前功能很简单:主页列出了我自己原创或者翻译的所有文章,读者可以注册用户帐号,注册用户可以发表评论,也可以在用户管理页面中更改自己的昵称。好了,目前功能就这么多,别看功能少,我可是前前后后陆陆续续花了2个月的时间,才做到目前这个样子。当然,我会继续更新这个站点,让它的功能变得更加完善。
提到ASP.NET Core,有没有吊起你的技术胃口呢?不用着急,接下来我就介绍一下整个站点中各部分的技术选型,看完后,或许你会知道为什么我花了2个月的业余时间,才整出来这么个简单的玩意儿。
站点技术介绍
整体架构
整个网站所采用的所有基础设施全部运行在微软云(Windows Azure)中,使用了部分托管资源,以及一些非托管的Azure VM。大致情况如下:
图片存储服务:由Azure Blob Storage Service托管
数据库系统:由Azure SQL Database托管(未启用Geo-Replication,因为没钱)
邮件服务:由Azure SendGrid Account托管(Pricing Tier为F1,每月可以免费发送25000封邮件)
应用服务器:基于Azure构建的Ubuntu 16.04.1 LTS虚拟机,运行了两个Docker容器:blog-web和blog-service,分别托管前端Web站点和后端RESTful服务。后端RESTful API服务没有做任何认证和授权,Web站点通过内部子网访问RESTful API服务,Docker容器运行在非托管环境中
持续集成系统:Jenkins,基于Azure构建的Windows Server 2012 R2一台(Master),和一台Ubuntu 16.04.1 LTS(Slave)。站点的前端和后端都在后者(Ubuntu)中完成编译、打包以及Docker镜像的发布,实现了一步到位的部署方式
代码库:Github
有人会问:为什么使用了非托管的Azure VM环境运行应用系统?我也考虑过这个问题,理论上讲,基于云的系统架构最好选用托管的PaaS服务,这样不仅可以得到纯天然的高可用性(包括灾备,比如AWS的跨AZ部署,某些服务跨区域的可用性,以及负载均衡),而且还可以得到专业的技术支持。只有当存在老系统向云迁移的需求,并需要迎合老系统的特定运行环境要求时,才考虑使用IaaS服务。虽然虚拟机等这些资源是由Azure负责创建并运行的,在这一层面Azure可以保证虚机的可用性,但虚机内部运行的任何程序的状态,以及所使用的数据,Azure等云服务是无从得知的,对这部分东西的监控也会变得很麻烦。出于安全考虑,通常云服务供应商是不会,也不应该获得类似虚机内部的客户程序的运行数据的,使用虚拟机服务所产生的程序运行风险,客户需要自己承担。这也就是著名的责任共担原则。
看起来用虚拟机运行应用不是太靠谱嘛,然而我却选择这么使用了。有几个原因:
为何不使用Azure Web App?一方面Jenkins做自动化部署,直接把编译好的应用推送到Azure Web App中好像不是太顺手,要写一些PowerShell的代码,可是我的编译系统是Linux,不过现在已经有Linux版的PowerShell了,而且Azure SDK Command Line Interface也有Linux版,所以这个理由有点牵强,更合理的解释是:劳资不会!另一方面,我没有在服务端做认证和授权,仅通过子网向外界提供服务,所以我希望我的Web App也运行在子网内部,然后向外暴露80端口供外界访问。这样一来,Azure Web App又如何部署到我自己的子网内?这是一个技术问题,我相信一定有解决方案,但是我也没太多时间和精力去细究如何实现,自己的第一反应也无非是将前后端全部部署在Azure Web App中,然后打开后端的认证机制。但这样做又要花一些额外的工夫。好吧,还是这个理由:劳资不会
为何不使用Azure Container Service?Azure Container Service会在你指定的Resource Group(资源组)中创建一整套网络部署,包括好几台虚拟机、公网IP、两个负载均衡器等等,我想你一定知道我为什么没有选择Azure Container Service了,原因就是:劳资没钱
理由够充分吧?微软Windows Azure提供的这些服务都很赞,我没选不是说它们不好用,而是出于自己的实际情况考虑:
某些服务的学习成本
经济成本
暂时没必要做到99.99999%的高可用率
即使应用挂了,恢复的成本很小:数据完全不需要恢复,托管的SQL Database、Blob Storage会保证我的数据不丢失,应用程序恢复也很简单:重新运行Docker容器就完事儿
OK,从整体架构上看,我的选择即是如此而已,这样的选择当然不一定完全正确,但我觉得至少合适,仅供参考。下面附上本站点的整体架构图。
作几点注解:
三台VM位于同一个Virtual Network的subnet中,每台VM的虚拟网卡上都套有独立的Network Security Group(NSG),在NSG上设置了Inbound/Outbound Endpoints,严格限制了端口访问的IP地址。三台VM之间使用subnet IP地址访问
Windows Server 2012 VM宿主了Jenkins Master,以及Seq日志服务。它向公网暴露8080端口和5342端口,分别用于访问Jenkins服务和Seq管理界面
第一台Ubuntu VM运行了Jenkins Slave,它不向公网暴露任何端口,仅向Jenkins Master机器暴露22端口,用于Jenkins Slave Agent的执行调度
第二台Ubuntu VM运行了博客系统的两个Docker容器:前端应用程序blog-web和后端RESTful API服务程序blog-service。web通过子网IP地址访问service,VM仅向公网暴露80端口,后台service无法从公网访问
两个Docker容器所运行的应用(blog-web和blog-service)都可以访问托管的Azure SQL database、Azure Storage blob和SendGrid Account服务
整个部署的拓扑结构有可能不太合理,比如没有做负载均衡,没有使用托管的应用宿主服务(比如Azure Web App、Container Service等),没有使用Scaleset。因为目前没必要而且没钱
接下来,回到代码上,我向大家介绍一些框架的技术选型,以及几个ASP.NET Core可用的开源库项目。
前端
如今的前端技术日新月异,各种Javascript的框架和JSX的技术,使得前端开发变得更加方便高效,所获得的用户体验也变得越来越好。例如Angular JS(包括1和2两个版本)、React + Redux、Knockout.JS、Backbone等等。在实际项目中,我们也运用了这其中绝大部分技术,然而,在我的这个博客系统中,我没有使用单页面应用的解决方案,而是继续使用前端Razor+后端C#代码的方式,对啦,这就是ASP.NET Core MVC!我没有使用任何MVVM的框架,只是简单地使用了Bootstrap和jQuery,对我来说,这样选择的原因有以下几个:
相对而言对ASP.NET MVC比较熟悉,更容易尽快完成开发任务
本身站点逻辑不是太复杂,暂时没有必要使用这些前端框架
打算体验一下ASP.NET Core的新特性
当然,为了实现一些特定的功能,我还是选用了一些开源代码和框架,现给大家大致介绍一下。
关于首页的分页实现
首页实现了博客文章的服务端分页,每次仅向服务器请求有限量的数据。分页控件是自己写的一套算法实现的,并套用了Bootstrap的pager样式,实现了响应式用户体验。分页控件使用了ASP.NET Core MVC中新的Tag Helper技术,从算法上根据每页的大小和总博客数量,对页号进行分段处理,使得整个分页功能有个很好的用户体验。
关于验证码生成
验证码的生成在经典的ASP.NET应用程序中能够非常容易地实现。经典ASP.NET应用程序基于Full .NET Framework,运行于Windows的IIS上,依赖于Windows的图形库,可以很方便地产生图片。然而,ASP.NET Core应用程序则完全不同,为了实现跨平台,就无法使用System.Drawing命名空间下的类型(当然你可以指定你的ASP.NET Core应用程序使用net45,但是这样无法跨平台)。在这里我使用了CoreCompact.System.Drawing这个库,可以通过nuget搜索到 。它会依赖于Microsoft.Win32.Primitives库,这个库定义了一些与Drawing相关的数据结构,但是没有提供任何图形库的实现。有兴趣的读者不妨一试。
关于回复编辑器
没什么好说的,使用了著名的CKEditor作为编辑器,当然,我选择性地启用/禁用了某些功能。
关于博客文章中的代码高亮
使用了著名的Alex Gorbatchev的SyntaxHighlighter,博客园也是使用的这个库,不过我用的可能不是最新版本。
关于回复中的时间信息
在每篇博客文章后面会显示网友的回复内容。这些内容会显示回复时间与当前时间的关系信息,比如:
上图显示这则回复内容是发表于25天前的。可别小看了这个部分的实现,我是采用了一个叫做Humanizer的库。这个库很有意思,它能提供一些非常实用的API,比如给它一个英文名词,它可以返回复数形式;给它一个日期,它能返回一个更贴近人类自然语言的表述。它还有很多其它的有趣的功能,大家可以去了解一下。
关于博客发布的MetaWeblog API
博客系统支持使用Windows Live Writer发布博客,它通过Shawn Wildermuth提供的WilderMinds.MetaWeblog实现了MetaWeblog API。通过Windows Live Writer可以直接将站点添加到帐号中:
基本上前端所使用的一些技术和第三方框架就如上所述。下面来看看后台的一些技术选型。
后台
数据库与数据访问组件
正如上所述,新博客系统后台使用Azure SQL Database,也就是托管的SQL Server关系型数据库。为什么选择SQL Server而不选择MongoDB等目前流行的NoSQL方案?作为一个博客网站,我没有找到选择NoSQL的理由,Azure上也有托管的MongoDB服务,仅管它是委托由Bitnami负责运维的。另一方面,虽然我选择了Azure SQL Database,但我没有使用任何第三方的数据访问框架,没有使用ORM,包括目前流行的Dapper。没有选择ORM的理由,一方面感觉ORM在这个场景里还是太重,另一方面,截止我进行技术选型时,Entity Framework Core无法满足我的需求,至少它无法从领域模型的角度去支持多对多的映射。那为何又没有选择Dapper呢?主要原因还是一样:无法满足我的需求。原生的Dapper类库需要写一些SQL脚本,虽然轻量了,但失去了对代码重构的支持,Dapper.Contrib增加了一些更友好的API,但仍然无法满足自己的需求。
几番思考,我决定自己写一个小框架,既可以支持自己定义的简单领域模型,又可以支持基于Lambda的语法、支持数据库事务、支持异步API、支持多种类型的关系型数据库。这个小框架的代码位于DaxnetBlog.Common.Storage命名空间下,使用了一些非常巧妙的技巧,比如,开发者可以使用Lambda表达式来定义查询条件,框架会通过ExpressionVisitor(访问者模式)将Lambda表达式转换成SQL语句。下面的代码正是这个框架的使用代码:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
|
var rowsAffected = await this .storage.ExecuteAsync(async (connection, transaction, cancellationToken) => { var account = (await this .accountStore.SelectAsync(connection, acct => acct.UserName == userName, transaction: transaction, cancellationToken: cancellationToken)).FirstOrDefault(); if (account == null ) { throw new ServiceException(HttpStatusCode.NotFound, Reason.EntityNotFound, $ "未能找到帐号名称为{userName}的用户帐号。" ); } account.DateLastLogin = DateTime.UtcNow; return await this .accountStore.UpdateAsync(account, connection, acct => acct.UserName == userName, new Expression<Func<Account, object >>[] { acct => acct.DateLastLogin }, transaction, cancellationToken); }); |
这段代码用于更新指定帐号名称的用户的登录时间,代码中没有穿插SQL语句,而是使用Lambda表达式进行表述。代码中storage对象指代关系型数据库的实体,而accountStore则表示对某种实体(在此处是帐号实体)的存储,有点像领域驱动设计中的Repository的概念。这样的设计是为了实现职责分离:accountStore不会依赖于storage(也就是关系型数据库类型)的实现。
日志
无论是前端还是后端,我都使用了Serilog作为日志框架,并将日志推送到Seq系统。具体做法我会在另外的博客文章中详细介绍,在此就不多介绍了。下图就是本博客的日志输出,为了省钱,在Docker容器启动时,通过环境变量将日志级别设置为Warning。
API文档
不多说,Swagger。具体实现方式我也会在另外的文章中介绍。
缓存
暂时未使用缓存,下一步会增加。
好了,整个博客的架构以及前后端技术大概就介绍这么多,如果要深入技术实践的每一个细节,我想,估计几个系列文章都讲不完。还是如本文最开始的时候所述,博客代码开源,大家可以学习交流。今后我仍然会争取多写一些文章来介绍相关技术。
我还会继续在博客园发表博客吗?
当然会!博客园一直是我与大家交流的主要场所,将来也是。可以理解,为了向大家提供更多高质量的“干货”,博客园对博主们所发文章都会有一些限制,博客主题行文也会有一些约束。作为我本人来说,在博客这种形式下,我或许应该可以以更多的方式来表现我的技术生涯,甚至是自己的一些对生活中事物的思考,这或许对他人的技术发展也会是一种启发,在获得大家的反馈和回复以后,我也能继续提高自己。与这些相关的内容,我会发表在自己的博客中,当然,我想,我自己的博客仍然会以技术类文章为主吧。
目前这个新博客显示了我曾经在博客园发表的博客(当然只是为了充数,使得主页不显得那么单调,所有图片中还是保留博客园的链接)。我打算给这个新博客定下三个月的试运营阶段,这个过程准备考察一下系统的运行状况,并总结一下微软Azure云的使用心得,当然最重要的是衡量一下自己能否支付得起运营的这笔开销。整个试运营阶段我还会继续往系统加入更多功能。
如果运营失败,也请大家多多包涵,权当是我为社区多贡献了一个开源项目吧。
总结
本文首先阐述了我对社区贡献的一些实际情况,并由此引出我自己全手工打造的基于ASP.NET Core实现的博客系统;接下来介绍了这个系统的整体架构和部署,以及前后端的一些技术选型;最后对大家可能提出的问题进行了简要解答。马上又要进入新的一年了,也快到了自己MVP Renew的时间,无论Renew是否成功(去年贡献量感觉不是太高),我仍将继续坚持为社区多做贡献,真正做到“专业、求是、解惑”。
原文地址: http://www.cnblogs.com/daxnet/p/6139317.html
一个基于Microsoft Azure、ASP.NET Core和Docker的博客系统的更多相关文章
- 基于Microsoft Azure、ASP.NET Core和Docker的博客系统
欢迎阅读daxnet的新博客:一个基于Microsoft Azure.ASP.NET Core和Docker的博客系统 2008年11月,我在博客园开通了个人帐号,并在博客园发表了自己的第一篇博客 ...
- 欢迎阅读daxnet的新博客:一个基于Microsoft Azure、ASP.NET Core和Docker的博客系统
2008年11月,我在博客园开通了个人帐号,并在博客园发表了自己的第一篇博客.当然,我写博客也不是从2008年才开始的,在更早时候,也在CSDN和系统分析员协会(之后名为"希赛网" ...
- eShopOnContainers 是一个基于微服务的.NET Core示例框架
找到一个好的示例框架很难,但不是不可能.大多数是小型Todo风格的应用程序,通常基于SimpleCRUD.值得庆幸的是,Microsoft已经为eShopOnContainers创建了一个基于微服务的 ...
- 构建基于asp.net core 的docker应用并发布
发布Docker镜像的方法有很多种,asp.net core的发布需要在windows系统中 开门见山,首先保证已经在Centos上安装好了Docker.创建一个asp.net core的webapi ...
- .NET Core微服务之ASP.NET Core on Docker
Tip: 此篇已加入.NET Core微服务基础系列文章索引 一.Docker极简介绍 1.1 总体介绍 Docker 是一个开源的应用容器引擎,基于 Go 语言 并遵从Apache2.0协议开源.D ...
- [翻译] ASP.NET Core 利用 Docker、ElasticSearch、Kibana 来记录日志
原文: Logging with ElasticSearch, Kibana, ASP.NET Core and Docker 一步一步指导您使用 ElasticSearch, Kibana, ASP ...
- 自动部署Asp.Net Core到Docker
原文链接:个人博客:自动部署Asp.Net Core至Docker 本文简介 最近在开发一个管理系统,代码框架是用的前后台分离的方式 后台使用的是Asp.Net Core平台,开发所有业务,向前台提供 ...
- ASP.NET Core的路由[2]:路由系统的核心对象——Router
ASP.NET Core应用中的路由机制实现在RouterMiddleware中间件中,它的目的在于通过路由解析为请求找到一个匹配的处理器,同时将请求携带的数据以路由参数的形式解析出来供后续请求处理流 ...
- ASP.NET Core开发-Docker部署运行
ASP.NET Core开发Docker部署,.NET Core支持Docker 部署运行.我们将ASP.NET Core 部署在Docker 上运行. 大家可能都见识过Docker ,今天我们就详细 ...
随机推荐
- ABP源码分析二十七:ABP.Entity Framework
IRepository:接口定义了Repository常见的方法 AbpRepositoryBase:实现了IRepository接口的常见方法 EfRepositoryBase:实现了AbpRepo ...
- ABP框架 - 领域服务
文档目录 本节内容: 简介 例子 创建一个接口 实现服务 使用应用服务 相关论述 为什么不只用应用服务? 如何强制你使用领域服务? 简介 领域服务(或服务)用来执行领域操作和业务规则.Eric Eva ...
- Fiddler--一、HTTP协议简介
在学习Fiddler之前,最好先学习一下HTTP协议. HTTP协议简介 什么是HTTP协议 超文本传输协议(HTTP)是一种通信协议,它允许将超文本标记语言(HTML)文档从Web服务器传送到客户端 ...
- 网站就必须用响应式布局吗?MVC视图展现模式之移动布局
本文先引入给读者一个自己研究的机会,下次深入说明一下: 废话不多说,直接上图 新建一个mvc的项目 在视图里面添加一个移动端视图 正常访问一下 Bootstrap自带的响应式的方式(页面代码并没有改变 ...
- 【JS】javascript 正则表达式 大全 总结
javascript 正则表达式 大全 总结 参考整理了一些javascript正则表达式 目的一:自我复习归纳总结 目的二:共享方便大家搜索 微信:wixf150 验证数字:^[0-9]*$ 验证n ...
- .NET Core的文件系统[2]:FileProvider是个什么东西?
在<读取并监控文件的变化>中,我们通过三个简单的实例演示从编程的角度对文件系统做了初步的体验,接下来我们继续从设计的角度来继续认识它.这个抽象的文件系统以目录的形式来组织文件,我们可以利用 ...
- SQL Server 并行操作优化,避免并行操作被抑制而影响SQL的执行效率
为什么我也要说SQL Server的并行: 这几天园子里写关于SQL Server并行的文章很多,不管怎么样,都让人对并行操作有了更深刻的认识. 我想说的是:尽管并行操作可能(并不是一定)存在这样或者 ...
- struts2工作流程
struts2的框架结构图 工作流程 1.客户端请求一个HttpServletRequest的请求,如在浏览器中输入http://localhost: 8080/bookcode/Reg.action ...
- [Asp.net 5] Caching-缓存预告
本节讲Asp.net 5的缓冲.解决方案可以通过网址:https://github.com/aspnet/Caching下载 也是Asp.net 5开源代码介绍的第6部分,前5部分链接如下: 1. D ...
- Windows进程间通信—命名管道
命名管道是通过网络来完成进程间的通信,它屏蔽了底层的网络协议细节.我们在不了解网络协议的情况下,也可以利用命名管道来实现进程间的通信.与Socket网络通信相比,命名管道不再需要编写身份验证的代码.将 ...