欢迎阅读daxnet的新博客：一个基于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提供的这些服务都很赞，我没选不是说它们很差用，而是出于本身的实际状况考虑：

1. 某些服务的学习成本
2. 经济成本
3. 暂时不必作到99.99999%的高可用率
4. 即便应用挂了，恢复的成本很小：数据彻底不须要恢复，托管的SQL Database、Blob Storage会保证个人数据不丢失，应用程序恢复也很简单：从新运行Docker容器就完事儿

OK，从总体架构上看，个人选择便是如此而已，这样的选择固然不必定彻底正确，但我以为至少合适，仅供参考。下面附上本站点的总体架构图。

做几点注解：

1. 三台VM位于同一个Virtual Network的subnet中，每台VM的虚拟网卡上都套有独立的Network Security Group（NSG），在NSG上设置了Inbound/Outbound Endpoints，严格限制了端口访问的IP地址。三台VM之间使用subnet IP地址访问
2. Windows Server 2012 VM宿主了Jenkins Master，以及Seq日志服务。它向公网暴露8080端口和5342端口，分别用于访问Jenkins服务和Seq管理界面
3. 第一台Ubuntu VM运行了Jenkins Slave，它不向公网暴露任何端口，仅向Jenkins Master机器暴露22端口，用于Jenkins Slave Agent的执行调度
4. 第二台Ubuntu VM运行了博客系统的两个Docker容器：前端应用程序blog-web和后端RESTful API服务程序blog-service。web经过子网IP地址访问service，VM仅向公网暴露80端口，后台service没法从公网访问
5. 两个Docker容器所运行的应用（blog-web和blog-service）均可以访问托管的Azure SQL database、Azure Storage blob和SendGrid Account服务
6. 整个部署的拓扑结构有可能不太合理，好比没有作负载均衡，没有使用托管的应用宿主服务（好比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，对我来讲，这样选择的缘由有如下几个：

1. 相对而言对ASP.NET MVC比较熟悉，更容易尽快完成开发任务
2. 自己站点逻辑不是太复杂，暂时没有必要使用这些前端框架
3. 打算体验一下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语句。下面的代码正是这个框架的使用代码：

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是否成功（去年贡献量感受不是过高），我仍将继续坚持为社区多作贡献，真正作到“专业、求是、解惑”。