上一家公司倒闭,为什么我又来了创业公司?

一面冰川,一面火山。你在资本的寒冬里繁华落尽,而我在市场的浪潮下激流永进。前不久朋友圈还不断地被冠以 “去年拿到A轮的创业公司现在快倒闭完了” 的文章刷屏,另一面,最近摩拜单车一轮又一轮的融资让人不禁感叹:“这还是不是资本寒冬了!”

获得融资的新闻时常还有,但是,那些怀着改变世界的心愿喊着”我要去创业的人“是真的少了很多。在这个时候还毅然选择投身创业的人,是真的一定要创业的人。你们知道我说的是冯老师?

不是每个人当下都适合创业

最近我面试了几个前创业者,他们都很年轻,90后居多。他们做过了“CEO”、“CTO”之后,又回过头来重新找工作。在15年中间的鼎盛时期,几乎所有的媒体,甚至国家都在鼓吹创业,一大批刚刚毕业的学生就这样被卷进浪潮中。

有一位从牛津读完研回国创业的男生,想重新找一份基本的编程工作,主要是觉得自己还年轻不想丢掉技术,各方面的技能都补齐之后再考虑创业。 考虑到对数据可视化感兴趣,所以想从前端作为切入点,愿意只拿一半的薪水工作,在试用期结束之后重新考核。他很有天份、聪明,基本功也扎实,并且能够重新脚蹋实地的做一些事情。我们很愿意给予这样的机会。

遇到前后反差比较大的人,我都会问他当下的感受。经历磨练心智,同时看待事情的角度会更完整。人与人之间的差距在经历失败时会更加鲜明。我也曾有过失败之后依然看不清方向还不知道自己想要什么的混沌阶段。我不太认同“创业让人成长” 这句话,因为创业本身就有很多运气成份,不同的人创业所面临的挑战也不一样,如果王思聪创业成功了我并不会觉得他有什么特别了不起。我更认同的是“挫折让人成长”。 创业之所以迷人是因为它有太多挫折要经历,但是,你真的能够顺利的解决所有问题吗?

把别人的路走的更漂亮也是一种选择

圈子里面有另外一位90后小哥,大学在阿里实习做前端,毕业之后转正,一路在阿里成长。看起来是一个中规中矩的套路,毋庸置疑的是阿里包括很多一线的互联网公司充斥着这样的人,但是在2〜3年能成长为对行业有影响力的人寥寥无几。90后小哥算一个,这和天份、勤奋还有选择有关。

如果让这个男生毕业之后进入一家快速发展的公司跟着公司一起成长,而不是自己去做CEO,那么现在他的情况会是什么样子?

选择是一件很有意思的事情。每次你的选择都只有一次机会,不可能重来,如果你意识到每一次的选择都会改变你以后的人生轨迹,你还会轻易的做决定吗?我们的理性或者尝试理性的甚至有能力去做理性的决定吗? 这两个问题其实是矛盾的,因为我们需要不停的选择、尝试并进行校正之后才能做出适合自己的选择。到最后才能比较容易的做出理性并正确的选择。

大多数时候,我们之所以会做出我们没能坚持住的事情,皆是源于我们对于自己以及当下环境的了解还不够深刻,而多数是因为对自己的了解还不够。

平凡人如何走出“不平凡”的人生轨迹

我们中的绝大多数人都是平凡人,在智商,毅力和处事的方法上来说都差不多。可能是使用的方法和接受的引导不同而已。在我看来,不管是在任何行业做任何事情,如果需要有所造诣,都必须要经历下面的四个阶段,也包括创业本身。

新手

“万事开头难“ ,如果你想要做好一件事,它会比你想象的复杂很多。需要很多的实践总结不断的学习,才能应付自如。这个阶段有一个在行业内非常有经验的导师,非常重要。多听过来人的话是没错的。

熟手

有没有人在第一个阶段就放弃的? 就是那些因为觉得苦、累、难而选择换一件事情来做的人。创业就很典型,很多人第一次创业没有任何的积累,一切都靠摸着石头过河。又做着最苦、最难、最累的事情,放弃的人也就特别多。

如果跨过新手,在你的领域成为熟手,相当于掌握了应对和解决大多数问题的方法以及规则。就算是没有遇到过的问题,也能凭借经验有路所寻。

如果没有新挑战,此时也容易进入舒适区。

专家

从一个阶段跨到另一个阶段都会是一个坎。比如有些人在成为有经验的熟手之后,就停止向上发展了。最多换一个更好的环境,薪资更高的地方做同样的事情,就把自己放到一个温床,最终是非常容易被行业淘汰的。 在变成熟手之后就容易进入舒适区,但是想再往上又会是一个瓶颈。此时需要结合自身的特点和优势,找到属于自己的方向。

专家与熟手的区别:
带领团队,培育新人
开始建立自己的影响力
成为团队中的leader,找那些最难最有挑战的事情去做,冲在最前面。
将自己所在的领域知识进行总结,并与行业领先的水平对比并靠拢
全面优化自己的处事方法、技能,提高效率
……

大师

专家是那些在专业领域非常出色的人,他们最终都会成为企业的高管以及核心人物。我所理解的大师是那些为行业作出贡献并推动整个行业发展的人。

用几句话来形容:
方方面面追求极致
用作品打动人,影响人
工艺改造、提升(为行业带来新的方法论,以及工具)
行业影响力
以上几个阶段,每个人能够经历到哪个阶段,分别在每个阶段花多长时间?是一个很难有定论的问题,并且也不一定是按照顺序全部经历。对于大多数人来说要做到以上三段并不难,只要认真、专注、持续、虚心它就一定会到来。

放眼一看,说来容易,能做到的人并不多。为什么?

自己创业与加入创业公司

创业路上所遇到的困难是前所未有的,如果未能成功走到最后,则要自己承担时间和经济上的损失包括机会成本。如果实在是有自己的创业梦想去实现,但是在还没有准备好之前倒是可以进入一家初创公司,在一定的安全边际之内进行尝试。

如果说产品经理是CEO的预备班,那么进入初创公司可以说是在拿着工资去做创业实践。

什么时候加入创业公司

我是平凡人中的一个,08年加入“报喜”旗下的一家独立b2c电商网站,几乎与“凡客”同时起步。只是当“凡客”如日中天的时候,我们由于集团不再投入而关闭,后来带领中国的团队负责微软全球在线商城。也是在那里,技术和管理能力都得到了很大的提升,并在那个时候写了一些关于.NET的技术文章得已在圈子内形成了一定的影响力。在此以前我都没有想过会加入一家创业公司。

直到后来,14年到15年和“创业”做了一些接触,参与了一些创业周未和一些线下活动。我看到了这些团队里很多闪耀的东西:激情、活力和创新。 而这些正好是很多大外企里缺少的。创业公司快速发展的节奏,可以让每个人都有机会得以快速成长。

08年那个时段的创业公司,大多都是带着传统公司味道的创新。现今,开放、透明、自由从一开始就植根在部分公司文化里。

保持开放的心态,不带偏见的去尝试一切可以接触到的,甚至是你之前认为自己完全不可能接受的东西,有可能才最适合现在的你。

加入什么样的创业公司?

到现在为止我已经待了三家创业公司,也尝试过自己创业。
第一家是受朋友邀请去杭州一家智能家居的创业公司做技术负责人,因为文化不同,三个星期之后离开。
第二家是之前的“明星”创业公司,担任架构部的开发经理,最终因为公司倒闭而离开。
第三家就是现在所在的公司。

我依然对加入创业公司保持谨慎的态度,如果你真的要去创业公司,要多考察一下这家公司的情况。

看风险

天使轮的创业公司还是很容易死掉的,并且处于创业的初期是属于风险和困难都最大的那一类型的公司。A-B轮之间处于一个调整期,由极速发展业务会慢慢转向流程、规范化,而C轮以后的公司基本上整体文化,各大部门老大,都已经确定下来,去了之后搬砖的可能性还是很大的,只不过上升空间会比那些发展缓慢的外企、传统公司好一些。

看背景

这个背景非常的微秒,背景太多高层之间的方向容易混乱。背景如果来自于传统的公司,就要具体考察一下公司的文化。背景如果太强,需要看一下公司的团队是否能够保持艰苦奋斗的精神。如果没有背景那就看看CEO和初创团队是否有真能力和足够勤奋。

看文化

创业公司吸引人的很大原因之一,是因为它大多有着一套公平、透明的机制,至少不会埋没有能力的人和真正努力进取的人。如果这个保证不了,那基本上也就很难留住人。

到一线去,到困难最多的地方去

在加入现在公司之前,同时还有国内一家旅游OTA准上市公司二级事业部技术负责人的offer。这个团队最开始属于创新中心的孵化项目。随着业务的发展,开发、测试以及前后端人员逐渐接近30人。从薪资、 稳定性、以及预期回报的成功概率、甚至所能够拿到的资源上来讲它都是有明显优势的。那我为什么要选现在的公司?

最多实践的地方

可以说创业公司是严重缺少人才的地方,即使你在某些方面不是很成熟,只要你有想法,都是有可能获得实践机会的。我看到仅毕业两年的女生,她们是设计师,但是她们却承担着用户调研,策划,项目推进上线,上线反馈收集总结等等事情。我看到品牌的同事在负责商城的收入,我看到对数据营销感兴趣的同学在研究增长并做实验。 你想给用户创造惊喜? 那就去轮岗客服吧,在你开心用户也开心的时候,给用户随便送点优惠券或者免费产品吧。

而我,在实践着如何在资源不足,同时业务快速发展的同时逐步实现技术架构的升级以及技术团队的升级。之所有不考虑准上市公司也是因为他们的技术架构以及组织架构、文化等这些都已经成型。比起在一个成型、稳定的架构之上添砖加瓦,更吸引我的是在一团乱麻中找到联系进而重构一个平台。


最考验解决问题能力的地方

在创业公司最不缺的就是发现问题的人,产品上的问题,团队上的问题,市场的问题,甚至商业模式的问题和CEO的问题。所以我们将“办法总比问题多”列为企业slogan。如果你站在一个公司生存的角度去想问题,就会发现有现在的问题(比如产品、运营的)以及发展中的问题(比如技术框架健壮性以及团队扩展性的问题)甚至很长远的问题(我们如何建立核心竞争力,让对手永远无法赶超我们?)

那么我们怎么去解决?没有人可以给你答案,我们只有走过去才知道。所以这段时间的经验才会变得有成倍的价值。

需要不断转换思路的地方

之前我们在别的地方用过的方法已经不行了,几个月前我们在这里用过的方法也可能不行了。比如要从一堆问题中找到第一个能够快速解决并能带来最大回报的问题是哪一个?最近看到一个挺有意思的概念“双环学习”。


双环学习是不同层次的问题解决逻辑。对行动背后的想法加以检视,反思我们看问题的心智模式,进而才能采取真正有效的行动。当发现错误时,其改正方法包括对组织目标,政策和常规程序的修改。双环学习向组织中根深蒂固的观念规范提出质疑挑战,有利于人们提出与以往不同的问题解决办法,并获得巨大的飞跃。

而这个思路的转换就发生在“双环学习”那里,当一种方法解决不了问题或者解决的不是那么好的时候,我们就需要对问题的根源进行反思,找到更合适、更有效的办法。

不能停止学习的地方

我害怕温室,是的。每个人都有自己的安全边际,在达到自己的安全边际之后,就很容易进入舒适区。而这个快速发展的时间,你被时代淘汰可能只需要一年的时间。而那些最能逼迫我们成长的,就是我们遇到的那些问题和挑战。


和舒服相比,开心更重要

这是一个很年轻、自由、开放的团队。尽量少的规章制度和流程,你可以和公司的任何人坦诚沟通提出建议和问题,包括CEO。

我们是谁?做了什么?以及将来要做什么?

生意专家,为实体商户提供一站式开店产品。通过一个账号,管理繁琐的收银记账、客户关系、商品利润,并集成了各种创新的电子商务工具,帮助商家降低经营成本,提升顾客购物体验,增加销售收入。

我们尽量将软件设计的简单、好用。同时集成最新的一些互联网工具(比如微信扫码支付、手机微店等),并可以满足所有零售实体店和大部分服务类店铺的日常管理,比如服装店、精品店、化妆品店、鞋店、鲜花店、蛋糕店、文具店、宠物用品店、西餐厅、咖啡馆、美容美体会所、健身俱乐部等等。

未来我们还会涉及到实体店铺的供应链管理、打通B端和C端、以及第三方的开放平台和更多的开发者代享收益。

打造工程师文化

如今的互联网公司甚至只要是和技术沾边的公司开口必谈极客精神、工程师文化。虽然现在资本市场已经降温,但是技术环境里面浮躁的氛围似乎还在。不信你看看到处举办的各种技术大会,讲来讲去都是那么几个话题。再加上公众号的一些推波助澜,很多人看过几篇关于淘宝、京东之类的大型网站演进方案,就觉得自己也应该是一名架构师,去处理那些高并发的问题。或者对那些新兴的技术抱有莫名的狂热,照着网官的例子写了个小Demo就说自己熟悉了。

在我们内部一直奉行的标准是:

  • 喜欢研究技术,但不盲目崇拜新技术,善于用最合适的技术来解决问题
  • 精益求精,不分大小问题,即使是一个简单的数据导入导出也可以用很优雅的方案解决
  • 在研究那些另人目炫的高大上架构之前,先把代码写漂亮
  • 除了技术,先做到熟悉业务
  • 主动分析问题、解决问题、并善于总结和分享的习惯

我们是一家提供SaaS服务的公司,技术将会一直是我们的核心竞争力之一。我们将努力构建一个开放、透明、公平、自由同时能够为技术社区做点事情的团队。

想为创业的同伙做点事情

我相信有很多在创业的伙伴们和我们一样,面临着资源紧缺,业务快速发展的问题。但同时系统的稳定性以及平台的基础建设又是刻不容缓。有没有可能我们共同做一些事情?比如自动部署、统一日平台,统一任务调试,监控中心等等?这些其实我们已经做过了一些尝试,但还是需要时间来让它们更加健壮,如果你们团队也需要这些东西,不妨我们花时间交流一下(可以在公众号后台留下你的信息和联系方式)。

构建技术团队

我们的后端用ASP.NET实现 ,正在用Web API做前后端分离和SOA化。也有一些基础服务用Node实现,移动端正在用ReactNative做重构, 在前端这块,我们也在积极的尝试Vue。

下面打一个小小的广告〜
生意专家正在进行B轮融资,我们需要更多志同道合的小伙伴来加入我们。牛B的.NET后端工程师、业务架构师、基础平台架构师、DevOps、前端架构师/Leader、iOS以及Android工程师,有兴趣或者有推荐的朋友公众号后台联系。薪资Open、团队年轻、办公地点在外滩SOHO。

JOIN OUR PARTY

ASP.NET Core MVC压缩样式、脚本及总是复制文件到输出目录

前言

在.NET Core之前对于压缩样式文件和脚本我们可能需要借助第三方工具来进行压缩,但在ASP.NET MVC Core中则无需借助第三方工具来完成,本节我们来看看ASP.NET Core MVC为我们提供了哪些方便。

自动压缩样式和脚本

当我们在测试环境中肯定不需要压缩脚本的,如果一旦压缩脚本的话,若在控制台出现错误不利于我们调试,但是在生产环境中我们通过压缩脚本或者样式一来可以减少传输流量,二来可以加速页面加载时间,换句话说,此时我们需要测试环境和生产环境对应的原生版本和压缩版本,那么在ASP.NET Core MVC中该如何做呢?请往下看。

我们将脚本、样式、图片等一些静态文件放在wwwroot网站目录下,此时我们首先需要添加bower.json文件来下载我们所需要的的脚本以及版本,如下:

复制代码
{
    "name": "asp.net",
    "private": true,
    "dependencies": {
    "jquery": "2.2.3",
    "bootstrap": "3.3.6"
  }
}
复制代码

当在此json文件中的一来节点添加我们需要的脚本和样式时,此时会将下载的脚本和样式自动添加到网站目录文件夹下如下

当然我们也可以通过右键->管理Bower程序包来下载同样会自动还原到网站目录文件夹下。此时我们想要的脚本和样式等都有了,接下来则需要在视图中引入脚本和样式。在ASP.NET Core MVC中为我们提供了加载样式和脚本的三种环境:Development、Staging、Production。Development即开发环境,Staging即发布之前的测试版本,Production即发布版本。那么我们在视图中该如何去使用呢?我们通过environment节点上的names来指定以上三个环境,如下:

复制代码
<environment names="Development">
 ..开发环境-加载脚本和样式
</environment>


<environment names="Staging,Production">
 ..准备和发布环境-加载脚本和样式
</environment>
复制代码

我们实际操作来看下是怎样的,如下加载JQuery脚本和Bootstrap样式,如下:

复制代码
<html>
<head>
    <title>学习加载脚本和样式</title>
</head>
<body>
</body>
</html>
<environment names="Development">
    <script src="~/lib/jquery/dist/jquery.js"></script>
    <script src="~/lib/tether/dist/js/tether.js"></script>
    <script src="~/lib/bootstrap/dist/js/bootstrap.js"></script>
    <link href="~/lib/bootstrap/dist/css/bootstrap.css" rel="stylesheet" />
</environment>
<environment names="Staging,Production">
    <script src="~/lib/jquery/dist/jquery.min.js"></script>
    <script src="~/lib/tether/dist/js/tether.min.js"></script>
    <script src="~/lib/bootstrap/dist/js/bootstrap.min.js"></script>
    <link href="~/lib/bootstrap/dist/css/bootstrap.min.css" rel="stylesheet" />
</environment>
复制代码

我们看下页面加载结果,是否如我们期望那样。

有点小尴尬,全加载进来了,怎么个情况,结果发现还需要在页面顶部添加TagHelper,如下:

@addTagHelper *, Microsoft.AspNetCore.Mvc.TagHelpers

这下没毛病,在此之前我们还未说明一点,我们在environment节点上的names设置的值,ASP.NET MVC Core是如何检测到的呢?我们需要在launchSettings.json中下的Profiles节点中指定环境,如下:

复制代码
"profiles": {
    "IIS Express": {
      "commandName": "IISExpress",
      "launchBrowser": true,
      "launchUrl": "Home/Index",
      "environmentVariables": {
        "ASPNETCORE_ENVIRONMENT": "Development"
      }
    },
    "IIS Express (Production)": {
      "commandName": "IISExpress",
      "launchUrl": "Home/Index",
      "launchBrowser": true,
      "environmentVariables": {
        "ASPNETCORE_ENVIRONMENT": "Production"
      }
    }
  }
复制代码

此时我们在运行application时看到如下我们设置的运行环境。

此时又有同学问了,我们在.NET Core之前可以手动写代码来实现加载脚本和样式的版本,在ASP.NET Core MVC中能实现么,既然说到这里了,当然是可以的,如下。

复制代码
<environment names="Staging,Production">
    <script src="~/lib/jquery/dist/jquery.min.js" asp-append-version="true"></script>
    <script src="~/lib/tether/dist/js/tether.min.js" asp-append-version="true"></script>
    <script src="~/lib/bootstrap/dist/js/bootstrap.min.js" asp-append-version="true"></script>
    <link href="~/lib/bootstrap/dist/css/bootstrap.min.css" asp-append-version="true" rel="stylesheet" />
</environment>
复制代码

是不是很美妙,自从有了.NET Core,我们只需要添加asp-append-version=”true”属性,.NET Core自动帮我们完成了添加版本控制,顿时神清气爽啊。讲到这里,算是讲完自动压缩脚本和样式的一大半了,但是,但是不知道看完到这里的你发现么有,我们是添加的程序包,都是自动带了压缩版本的,那么要是当我们自己写脚本和样式后,我们该如何压缩脚本和样式了,请继续往下看。

在手动写我们自己的脚本和样式时之前,我们需要在程序包中搜索Web Essentials程序包并安装,我已经安装完毕,在扩展和更新中可以看到Web Essentials程序包,如下:

我们在网站目录文件夹下创建一个js文件夹并添加JeffckyWang.js的脚本,在里面我们给出如下脚本:

(function ($) {
    "use strict";
     alert("学习自动压缩脚本和样式");
})(jQuery);

由于上述我们已经添加了Web Essentials程序包此时我们右键JeffckyWang.js脚本,你会发现有了自动压缩的菜单,如下:

当进行压缩后,我们展开JeffckyWang.js脚本会有我们压缩的JeffckyWang.min.js脚本,如下:

复制文件到输出目录

在.NET Core之前我们创建一个文件可以通过设置该文件的属性来复制到bin目录下的debug或者release目录。例如我们创建一个install.bat文件,在.NET Core之前版本,我们可以手动通过如下设置,如下:

此时我们设置为始终复制则将其复制到debug或者release目录下。但是在.NET Core中其属性却是如下这样的

在项目中遇到这个问题瞬间懵逼了,想了想,既然在.NET Core一切基于配置,那么是否在project.json是否可以进行一下配置即可呢,功夫不负有心人,进行如下设置即可。

  "buildOptions": {
    "emitEntryPoint": true,
    "preserveCompilationContext": true,
    "copyToOutput": [ "install.bat" ]
  },

我们只需要在buildOptions节点下添加一个copyToOutput节点,该节点为一个数组,添加我们对应的文件路径即可。此时重新生成一下则在debug或者release目录下看到我们的文件,如下:

总结

本节我们讲述了在.NET Core中对脚本和样式如何进行自动压缩以及对文件如何进行自动复制到输出目录,算是项目当中的一点小小总结吧,希望对阅读本文的你有所帮助。

Mac itunes备份的文件在哪里 Mac itunes备份文件路径解析

Mac itunes备份的文件在哪里?想必很多使用Mac的朋友也不知道,今天PC6小编教大家通过两种办法找到Mac itunes备份文件路径,方便大家直接管理自己的iTunes备份文件夹。

一、打开Finder,在菜单栏点击“前往”选项,按住option键会显示“资料库”,点击进入

在资料库中,可以找到“Application support”文件夹,继续前往下级Mobilesync文件夹里面的backup就是备份文件所在的地方了。

二、另外一种更加便捷的方法是在Finder下直接通过快捷键commnd+shift+G打开前往文件夹,直接复制:用户名/Library/application support/mobilesync然后回车,打开backup里面的就是了。

 

大型网站技术架构-入门梳理

罗列了大型网站架构涉及到的概念,附上了简单说明

前言

  • 本文是对《大型网站架构设计》(李智慧 著)一书的梳理,类似文字版的“思维导图”
  • 全文主要围绕“性能,可用性,伸缩性,扩展性,安全”这五个要素
  • 性能,可用性,伸缩性这几个要素基本都涉及到应用服务器,缓存服务器,存储服务器这几个方面

概述

  • 三个纬度:演化、模式、要素
  • 五个要素: 性能,可用性,伸缩性,扩展性,安全

演化历程

图例可参考 大型网站架构演化历程

  1. 初始阶段的网站架构:一台服务器,上面同时拥有应用程序,数据库,文件,等所有资源。例如 LAMP 架构
  2. 应用和数据服务分离:三台服务器(硬件资源各不相同),分别是应用服务器,文件服务器和数据库服务器
  3. 使用缓存改善网站性能:分为两种,缓存在应用服务器上的本地缓存和缓存在专门的分布式缓存服务器的远程缓存
  4. 使用应用服务器集群改善网站并发处理能力:通过负载均衡调度服务器来将访问请求分发到应用服务器集群中的任何一台机器
  5. 数据库读写分离:数据库采用主从热备,应用服务器在写数据时访问主数据库,主数据库通过主从复制机制将数据更新同步到从数据库。应用服务器使用专门的数据访问模块从而对应用透明
  6. 使用反向代理和 CDN 加速网站响应:这两者基本原理都是缓存。反向代理部署在网站的中心机房,CDN 部署在网络提供商的机房
  7. 使用分布式文件系统和分布式数据库系统:数据库拆分的最后手段,更常用的是业务分库
  8. 使用 NoSQL 和搜索引擎:对可伸缩的分布式有更好的支持
  9. 业务拆分:将整个网站业务拆分成不同的应用,每个应用独立部署维护,应用之间通过超链接建立联系/消息队列进行数据分发/访问同一数据存储系统
  10. 分布式服务:公共业务提取出来独立部署

架构演化-分布式服务

演化的价值观

  • 大型网站架构的核心价值是随网站所需灵活应对
  • 驱动大型网站技术发展的主要力量是网站的业务发展

误区

  • 一味追随大公司的解决方案
  • 为了技术而技术
  • 企图用技术解决所有问题

架构模式

模式的关键在于模式的可重复性

  • 分层:横向切分
  • 分割:纵向切分
  • 分布式:分层和分割的主要目的是为了切分后的模块便于分布式部署。常用方案:
    • 分布式应用和服务
    • 分布式静态资源
    • 分布式数据和存储
    • 分布式计算
    • 分布式配置,分布式锁,分布式文件,等等
  • 集群:多台服务器部署相同的应用构成一个集群,通过负载均衡设备共同对外提供服务
  • 缓存:将数据放距离计算最近的位置加快处理速度,改善性能第一手段,可以加快访问速度,减小后端负载压力。使用缓存 两个前提条件 :1.数据访问热点不均衡;2.数据某时段内有效,不会很快过期
    • CDN
    • 反向代理
    • 本地缓存
    • 分布式缓存
  • 异步:旨在系统解耦。异步架构是典型的消费者生产者模式,特性如下:
    • 提高系统可用性
    • 加快网站访问速度
    • 消除并发访问高峰
  • 冗余:实现高可用。数据库的冷备份和热备份
  • 自动化:包括发布过程自动化,自动化代码管理,自动化测试,自动化安全检测,自动化部署,自动化监控,自动化报警,自动化失效转移,自动化失效恢复,自动化降级,自动化分配资源
  • 安全:密码,手机校验码,加密,验证码,过滤,风险控制

核心要素

架构是“最高层次的规划,难以改变的规定”。主要关注五个要素:

  • 性能
  • 可用性(Availability)
  • 伸缩性(Scalability)
  • 扩展性(Extensibility)
  • 安全性

架构

下面依次对这五个要素进行归纳

高性能

性能的测试指标主要有:

  • 响应时间:指应用执行一个操作需要的时间
  • 并发数:指系统能够同时处理请求的数目
  • 吞吐量:指单位时间内系统处理的请求数量
  • 性能计数器:描述服务器或者操作系统性能的一些数据指标

性能测试方法:

  • 性能测试
  • 负载测试
  • 压力测试
  • 稳定性测试

性能测试曲线

性能优化,根据网站分层架构,可以分为三大类:

  • Web 前端性能优化
    • 浏览器访问优化
      • 减少 http 请求
      • 使用浏览器缓存
      • 启用压缩
      • CSS 放在页面最上面,JavaScript 放在页面最下面
      • 减少 Cookie 传输
    • CDN 加速:本质是一个缓存,一般缓存静态资源
    • 反向代理
      • 保护网站安全
      • 通过配置缓存功能加速 Web 请求
      • 实现负载均衡
  • 应用服务器性能优化:主要手段有 缓存、集群、异步
    • 分布式缓存(网站性能优化第一定律:优化考虑使用缓存优化性能)
    • 异步操作(消息队列,削峰作用)
    • 使用集群
    • 代码优化
      • 多线程(设计为无状态,使用局部对象,并发访问资源使用锁)
      • 资源复用(单例,对象池)
      • 数据结构
      • 垃圾回收
  • 存储服务器性能优化
    • 机械硬盘 vs. 固态硬盘
    • B+ 树 vs. LSM 树
    • RAID vs. HDFS

高可用

  • 高可用的网站架构:目的是保证服务器硬件故障时服务依然可用、数据依然保存并能够被访问,主要手段数据和服务的冗余备份及失效转移
  • 高可用的应用:显著特点是应用的无状态性
    • 通过负载均衡进行无状态服务的失效转移
    • 应用服务器集群的 Session 管理
      • Session 复制
      • Session 绑定
      • 利用 Cookie 记录 Session
      • Session 服务器
  • 高可用的服务:无状态的服务,可使用类似负载均衡的失效转移策略,此外还有如下策略
    • 分级管理
    • 超时设置
    • 异步调用
    • 服务降级
    • 幂等性设计
  • 高可用的数据:主要手段是数据备份和失效转移机制
    • CAP 原理
      • 数据一致性(Consisitency)
      • 数据可用性(Availibility)
      • 分区耐受性(Partition Tolerance)
    • 数据备份
      • 冷备:缺点是不能保证数据最终一致和数据可用性
      • 热备:分为异步热备和同步热备
    • 失效转移:由以下三部分组成
      • 失效确认
      • 访问转移
      • 数据恢复
  • 高可用网站的软件质量保证
    • 网站发布
    • 自动化测试
    • 预发布验证
    • 代码控制
      • 主干开发、分支发布
      • 分支开发、主干发布
    • 自动化发布
    • 灰度发布
  • 网站运行监控
    • 监控数据采集
      • 用户行为日志采集(服务器端和客户端)
      • 服务器性能监控
      • 运行数据报告
    • 监控管理
      • 警报系统
      • 失效转移
      • 自动优雅降级

伸缩性

大型网站的“大型”是指:

  • 用户层面:大量用户及大量访问
  • 功能方面:功能庞杂,产品众多
  • 技术层面:网站需要部署大量的服务器

伸缩性的分为如下几个方面

  • 网站架构的伸缩性设计
    • 不同功能进行物理分离实现伸缩
      • 纵向分离(分层后分离)
      • 横向分离(业务分割后分离)
    • 单一功能通过集群规模实现伸缩
  • 应用服务器集群的伸缩性设计
    • HTTP 重定向负载均衡
    • DNS 域名解析负载均衡
    • 反向代理负载均衡(在 HTTP 协议层面,应用层负载均衡)
    • IP 负载均衡(在内核进程完成数据分发)
    • 数据链路层负载均衡(数据链路层修改 mac 地址,三角传输模式,LVS)
    • 负载均衡算法
      • 轮询(Round Robin, RR)
      • 加权轮询(Weighted Round Robin, WRR)
      • 随机(Random)
      • 最少链接(Least Connections)
      • 源地址散列(Source Hashing)
  • 分布式缓存集群的伸缩性设计
    • Memcached 分布式缓存集群的访问模型
      • Memcached 客户端(包括 API,路由算法,服务器列表,通信模块)
      • Memcached 服务器集群
    • Memcached 分布式缓存集群的伸缩性挑战
    • 分布式缓存的一致性 Hash 算法(一致性 Hash 环,虚拟层)
  • 数据存储服务集群的伸缩性设计
    • 关系数据库集群的伸缩性设计
    • NoSQL 数据库的伸缩性设计

可扩展

系统架构设计层面的“开闭原则”

  • 构建可扩展的网站架构
  • 利用分布式消息队列降低耦合性
    • 事件驱动架构(Event Driven Architecture)
    • 分布式消息队列
  • 利用分布式服务打造可复用的业务平台
    • Web Service 与企业级分布式服务
    • 大型网站分布式服务的特点
    • 分布式服务框架设计(Thrift, Dubbo)
  • 可扩展的数据结构(如 ColumnFamily 设计)
  • 利用开放平台建设网站生态圈

网站的安全架构

XSS 攻击和 SQL 注入攻击是构成网站应用攻击最主要的两种手段,此外还包括 CSRF,Session 劫持等手段。

  • 攻击与防御
    • XSS 攻击:跨站点脚本攻击(Cross Site Script)
      • 反射型
      • 持久型
    • XSS 防御手段
      • 消毒(即对某些 html 危险字符转义)
      • HttpOnly
    • 注入攻击
      • SQL 注入攻击
      • OS 注入攻击
    • 注入防御
      • 避免被猜到数据库表结构信息
      • 消毒
      • 参数绑定
    • CSRF 攻击:跨站点请求伪造(Cross Site Request Forgery)
    • CSRF 防御:主要手段是识别请求者身份
      • 表单 Token
      • 验证码
      • Referer Check
    • 其他攻击和漏洞
      • Error Code
      • HTML 注释
      • 文件上传
      • 路径遍历
    • Web 应用防火墙(ModSecurity)
    • 网站安全漏洞扫描
  • 信息加密技术及密钥安全管理
    • 单向散列加密:不同输入长度的信息通过散列计算得到固定长度的输出
      • 不可逆,非明文
      • 可加盐(salt)增加安全性
      • 输入的微小变化会导致输出完全不同
    • 对称加密:加密和解密使用同一个密钥
    • 非对称加密
      • 信息传输:公钥加密,私钥解密
      • 数字签名:私钥加密,公钥解密
    • 密钥安全管理:信息安全传输是靠密钥保证的,改善手段有:
      • 把密钥和算法放在一个独立的服务器上
      • 将加解密算法放在应用系统中,密钥放在独立服务器
  • 信息过滤与反垃圾
    • 文本匹配
    • 分类算法
    • 黑名单

作者@brianway更多文章:个人网站 | CSDN | oschina

编程类开放书籍荟萃

关于开源图书有人在网络上做了大量整理,本文为大家刊载《免费的编程中文书籍索引》

书山有路勤为径,学海无涯苦作舟!

语言无关类

操作系统

智能系统

web服务器

版本控制

NoSQL

MySQL

项目相关

Web

大数据

编程艺术

其他

语言相关类

AWK

C/C++

CSS/HTML

Dart

Fortran

Java

JavaScript

PHP

iOS

Android

Python

Ruby

Shell

Go

Groovy

LaTeX

LISP

Lua

Haskell

R

Scala

Swift

Perl

Prolog

Vimscript

读书笔记及其它

读书笔记

测试相关

性能测试工具 wrk 安装与使用

今天给大家介绍一款开源的性能测试工具 wrk,简单易用,没有Load Runner那么复杂,他和 apache benchmark(ab)同属于性能测试工具,但是比 ab 功能更加强大,并且可以支持lua脚本来创建复杂的测试场景。

wrk 的一个很好的特性就是能用很少的线程压出很大的并发量, 原因是它使用了一些操作系统特定的高性能 I/O 机制, 比如 select, epoll, kqueue 等。 其实它是复用了 redis 的 ae 异步事件驱动框架. 确切的说 ae 事件驱动框架并不是 redis 发明的, 它来至于 Tcl的解释器 jim, 这个小巧高效的框架, 因为被 redis 采用而更多的被大家所熟知.

wrk GitHub 源码:https://github.com/wg/wrk

安装

wrk只能运行于 Unix 类的系统上,也只能在这些系统上便宜,所以我们需要一个Linux或者macOs。

不得不说,使用了 Win10之后方便很多。

必备条件:

  • Win10 RS及以上版本
  • 启用Ubuntu子系统

1、Win10 系统通过bash命令,切换到Ubuntu子系统。
然后需要安装一下编译工具,通过运行下面命令来安装工具:

# 安装 make 工具
sudo apt-get install make

# 安装 gcc编译环境
sudo apt-get install build-essential

安装 gcc 编译环境的时候最好挂一下VPN,速度会快些。
image

2、安装完成之后使用 git 下载 wrk 的源码到本地:

https://github.com/wg/wrk.git

3、切换到git的wrk目录,然后使用make命令:

cd /mnt/盘符/wrk目录

make

image

编译完成之后,目录下面会多一个 wrk 的文件。

image

测试

使用以下命令来测试一下:

./wrk -c 1 -t 1 -d 1 http://www.baidu.com

image

简单说一下wrk里面各个参数什么意思?

  • -t 需要模拟的线程数
  • -c 需要模拟的连接数
  • –timeout 超时的时间
  • -d 测试的持续时间

结果:

  • Latency:响应时间
  • Req/Sec:每个线程每秒钟的完成的请求数
  • Avg:平均
  • Max:最大
  • Stdev:标准差
  • +/- Stdev: 正负一个标准差占比

标准差如果太大说明样本本身离散程度比较高. 有可能系统性能波动很大.

如果想看响应时间的分布情况可以加上–latency参数
image

我们的模拟测试的时候需要注意,一般线程数不宜过多,核数的2到4倍足够了。 多了反而因为线程切换过多造成效率降低, 因为 wrk 不是使用每个连接一个线程的模型, 而是通过异步网络 I/O 提升并发量。 所以网络通信不会阻塞线程执行,这也是 wrk 可以用很少的线程模拟大量网路连接的原因。

在 wrk 的测试结果中,有一项为Requests/sec,我们一般称之为QPS(每秒请求数),这是一项压力测试的性能指标,通过这个参数我们可以看出应用程序的吞吐量。

总结

关于 wrk 已经介绍完毕了,之所以写这篇文章的目的是为了接下来对 ASP.NET Core做一个性能对比测试(Java,NodeJS,Python等)时需要用到该工具,敬请大家期待。


本文地址:http://www.cnblogs.com/savorboard/p/wrk.html
作者博客:Savorboard
欢迎转载,请在明显位置给出出处及链接


ASP.NET Core 性能对比评测(ASP.NET,Python,Java,NodeJS)

性能是我们日常生活中经常接触到的一个词语,更好的性能意味着能给我们带来更好的用户体检。比如我们在购买手机、显卡、CPU等的时候,可能会更加的关注于这样指标,所以本篇就来做一个性能评测。

性能也一直是我们开发人员一直追求的一个目标,我们在做语言选择,平台选择,架构选择的过程中都需要在性能之间做衡量。

同样性能对 .NET Core 团队来说也是至关重要的,一项新技术的诞生,除了对生产力的提高,还有技术团队对性能的追求。

今天,我们就来做一个对比测试,来看看微软的这样新技术性能到底怎么样,俗话说的好:“是骡子是马,拉出来溜溜”。

下面让我开始吧。

目录

测试目标

在测试之前,我们必须要明确我们本次测试想达到的一个目标。本次测试主要是测试应用程序的一个吞吐量。其中QPS,并发数,响应时间是我们衡量吞吐量的几个重要指标。

以下是本次对比测试的任务目标:

编号 对比方 系统环境 宿主环境 测试目标
1 ASP.NET Core vs ASP.NET Core Windows Kestrel vs IIS 相同平台不同宿主间性能差距
2 ASP.NET Core vs ASP.NET Windows IIS vs IIS 相同平台相同宿主不同框架间性能差距
3 ASP.NET Core vs ASP.NET Windows Kestrel vs IIS 相同平台不同宿主不同框架间性能差距
4 ASP.NET Core vs Python Django Linux Kestrel vs uwsgi 相同平台不同语言不同宿主不同框架间性能差距
5 ASP.NET Core vs Java Servlet Linux Kestrel vs Tomcat 相同平台不同语言不同宿主不同框架间性能差距
6-1 ASP.NET Core vs NodeJS Express Linux Kestrel vs self host 相同平台不同语言不同宿主不同框架间性能差距
6-2 ASP.NET Core vs NodeJS Koa Linux Kestrel vs self host 相同平台不同语言不同宿主不同框架间性能差距

测试工具

工欲善其事,必先利其器。

首先我们需要一个压力测试工具,本次我们使用 wrk,有关于wrk的介绍和使用,请查看我的 这篇博客

然后我们需要一个性能监控工具,因为wrk已经会给我们输出吞吐量相关指标,所以我们只需要一个监控CPU,内存等的工具即可。本次我们使用 Windows 自带的性能监视器。

Windows 性能监视器的打开方式:开始-->运行-->perfmon
PS: 在下面的监视器图中如果你发现cpu并没有100%,那是因为使用的虚拟机占用了一部分cpu,所以计算方式应该是虚拟机的cpu使用量+物理机cpu使用量。

环境准备

既然做测试,首先肯定是具有相同的运行环境,以下是本次测试使用到的软件和硬件环境。

  • 软硬件环境
名称 操作系统 职责 CPU 核心数 内存
物理机器1 Windows 10 RS1 Web Server && 负载生成 Intel Core i5-4590 4 16G
虚拟机器2 Ubuntu Server 16.04 Web Server Intel Core i5-4590 2 1G
虚拟机器3 Nano Server Web Server Intel Core i5-4590 2 1G

其中 虚拟机器2 为 “物理机器1” 使用 win 10 的 Hyper-v 技术搭建的一个虚拟机,所以有几个指标对于本次测试至关重要。

image

虚拟机设置为了2个虚拟核心,以便于在压力测试的过程中利用到多核特性。其中的虚拟机保留百分比,需要设置为100%,来分配两个物理cpu所有资源给它。占综系统资源百分比设置为50,也就是说虚拟机最多利用本地50%的CPU资源,虚拟机限制设置为100。

  • 源代码

AspNet 在 GitHub 有一个开源的性能测试项目叫benchmarks,之前新闻中23倍的性能也是出自于本测试项目, 为了客观,本次测试并不使用该项目,所有项目均我们自己新建,并且使用当前流行的框架,为了排除代码因素的干扰,我们使用最简单的 Hello World!。

如果你觉得本代码不够客观公正,欢迎在GitHub上Fork本项目,修改后给我提交PR,我会重新进行测试,并且更新本博客。

GitHub: https://github.com/yuleyule66/AspNetCoreBenchmarksCompare

开始测试

wkr命令参数:

wrk -t 2 -c 50 -d 20 --latency http://xxx

因为已经分配了2个核心给虚拟机使用,所以开的是双线程。使用这个参数是我经过多次测试,得到的一个最佳的模拟效果。

1 – ASP.NET Core vs ASP.NET Core(Kestrel vs IIS)

ASP.NET Core

  • 环境:物理机器1
  • OS:Windows 10 RS 1
  • Host:Kestrel
wrk -t 2 -c 50 -d 20 --latency http://localhost:5000

Running 20s test @ http://localhost:5000
  2 threads and 50 connections
  Thread Stats   Avg      Stdev     Max   +/- Stdev
    Latency     5.49ms   21.72ms 358.18ms   98.99%
    Req/Sec    23.28k     1.98k   27.48k    92.13%
  Latency Distribution
     50%    0.00us
     75%    6.87ms
     90%   12.76ms
     99%   28.58ms
  913567 requests in 20.02s, 115.00MB read
Requests/sec:  45636.43
Transfer/sec:      5.74MB

ASP.NET Core

  • 环境:物理机器1
  • OS:Windows 10 RS 1
  • Host:IIS 10.0
wrk -t 2 -c 50 -d 20 --latency http://localhost:5001

Running 20s test @ http://localhost:5001
  2 threads and 50 connections
  Thread Stats   Avg      Stdev     Max   +/- Stdev
    Latency     5.30ms    5.81ms  22.24ms   76.75%
    Req/Sec     7.61k   455.21     8.12k    90.00%
  Latency Distribution
     50%    3.14ms
     75%    9.02ms
     90%   15.62ms
     99%   17.17ms
  302880 requests in 20.02s, 44.77MB read
Requests/sec:  15130.97
Transfer/sec:      2.24MB

总结

QPS(Kestrel):45636.43
QPS(IIS):15130.97

这个结果难免令人诧异,程序部署在IIS上和使用Kestrel竟然差别如此之大,我们知道实际上即便部署在IIS上,实际上内部还是调用的Kestrel,但是测试结果告诉了我们答案。可能是由于IIS进一步的http封装导致的吧,毕竟IIS提供了那么多的其他功能。

以下是Windows的性能监视器,两个的曲线图差不多我就放一个了:
image

  • 红色:CPU使用率
  • 蓝色:内存使用率

2 – ASP.NET Core vs ASP.NET(IIS vs IIS)

ASP.NET Core

  • 环境:物理机器1
  • OS:Windows 10 RS
  • Host:IIS
wrk -t 2 -c 50 -d 20 --latency http://localhost:5001

Running 20s test @ http://localhost:5001
  2 threads and 50 connections
  Thread Stats   Avg      Stdev     Max   +/- Stdev
    Latency     5.30ms    5.81ms  22.24ms   76.75%
    Req/Sec     7.61k   455.21     8.12k    90.00%
  Latency Distribution
     50%    3.14ms
     75%    9.02ms
     90%   15.62ms
     99%   17.17ms
  302880 requests in 20.02s, 44.77MB read
Requests/sec:  15130.97
Transfer/sec:      2.24MB

ASP.NET

  • 环境:物理机器1
  • OS:Windows 10 RS
  • Host:IIS
  • .NET Framework 4.6 + MVC5
wrk -t 2 -c 50 -d 20 --latency http://localhost:10280

Running 20s test @ http://localhost:10280
  2 threads and 50 connections
  Thread Stats   Avg      Stdev     Max   +/- Stdev
    Latency     4.94ms    5.58ms  22.82ms   80.90%
    Req/Sec     9.10k   444.04     9.42k    95.00%
  Latency Distribution
     50%    3.00ms
     75%   10.10ms
     90%   13.57ms
     99%   16.45ms
  362177 requests in 20.00s, 89.80MB read
Requests/sec:  18104.50
Transfer/sec:      4.49MB

总结

QPS(ASP.NET Core + IIS):15130.97
QPS(ASP.NET + IIS):18104.50

看到这个结果的时候,其实我还是有一点小惊讶的,不仅仅是因为ASP.NET跑出了1.8K QPS这样的成绩,而是通过Stdev可以看出,ASP.NET 在应对高请求高并发的时候,还是相当的稳定的。这个结果说明了,在同样Windows+IIS环境中,ASP.NET是具有优势和竞争力的,可以预见 ASP.NET 应该还不会淘汰的太快。

Windows性能图我就不上了,基本上和上面一样 CPU 100% 的使用率。

3 – ASP.NET Core vs ASP.NET(Kestrel vs IIS)

ASP.NET Core

  • 环境:物理机器1
  • OS:Windows 10 RS 1
  • Host:Kestrel
wrk -t 2 -c 50 -d 20 --latency http://localhost:5000

Running 20s test @ http://localhost:5000
  2 threads and 50 connections
  Thread Stats   Avg      Stdev     Max   +/- Stdev
    Latency     5.49ms   21.72ms 358.18ms   98.99%
    Req/Sec    23.28k     1.98k   27.48k    92.13%
  Latency Distribution
     50%    0.00us
     75%    6.87ms
     90%   12.76ms
     99%   28.58ms
  913567 requests in 20.02s, 115.00MB read
Requests/sec:  45636.43
Transfer/sec:      5.74MB

ASP.NET

  • 环境:物理机器1
  • OS:Windows 10 RS
  • Host:IIS
  • .NET Framework 4.6 + MVC5
wrk -t 2 -c 50 -d 20 --latency http://localhost:10280

Running 20s test @ http://localhost:10280
  2 threads and 50 connections
  Thread Stats   Avg      Stdev     Max   +/- Stdev
    Latency     4.94ms    5.58ms  22.82ms   80.90%
    Req/Sec     9.10k   444.04     9.42k    95.00%
  Latency Distribution
     50%    3.00ms
     75%   10.10ms
     90%   13.57ms
     99%   16.45ms
  362177 requests in 20.00s, 89.80MB read
Requests/sec:  18104.50
Transfer/sec:      4.49MB

总结

QPS(ASP.NET Core + Kestrel):45636.43

QPS(ASP.NET + IIS):18104.50

这个结果应该是在预料之中的,大概是3倍的性能差距吧。但是我觉得和之前微软宣传的23倍的性能,是有很大差距的。

4 – ASP.NET Core vs Python Django

注意,以下我们开始使用到虚拟机器2了,我们要在Windows性能监控器里面查看CPU使用率,还需要再添加2个计数器。

物理处理器 \Hyper-V Hypervisor Logical Processor(*) \ %Total Run Time

虚拟处理器 \Hyper-V Hypervisor Virtual Processor(*) \ %Guest Run Time

ASP.NET Core

  • 环境:虚拟机器2
  • OS:Linux
  • Host:Kestrel
wrk -t 2 -c 50 -d 20 --latency http://192.168.2.48:5000/
Running 20s test @ http://192.168.2.48:5000/
  2 threads and 50 connections
  Thread Stats   Avg      Stdev     Max   +/- Stdev
    Latency     4.39ms    5.33ms  33.05ms   77.20%
    Req/Sec    13.43k     1.32k   17.95k    74.75%
  Latency Distribution
     50%    2.00ms
     75%    8.15ms
     90%   13.75ms
     99%   15.80ms
  534787 requests in 20.01s, 67.32MB read
Requests/sec:  26730.83
Transfer/sec:      3.37MB

image


Python Django

  • 环境:虚拟机器2
  • OS:Linux
  • Host:uwsgi
  • Python 2.7.12 + Django 1.10.2

服务端宿主运行命令:

sudo uwsgi --http :8000 --file HelloWorldWebApp/wsgi.py --processes=2 --threads==2 --daemonize=/var/log/django.log

结果:

wrk -t 2 -c 50 -d 20 --latency http://192.168.2.48:8000
Running 20s test @ http://192.168.2.48:8000
  2 threads and 50 connections
  Thread Stats   Avg      Stdev     Max   +/- Stdev
    Latency    23.40ms   12.23ms  78.13ms   74.81%
    Req/Sec   792.64    143.13     1.25k    67.10%
  Latency Distribution
     50%   21.16ms
     75%   31.25ms
     90%   38.26ms
     99%   53.75ms
  31591 requests in 20.09s, 3.01MB read
  Socket errors: connect 0, read 31591, write 0, timeout 0
Requests/sec:   1572.64
Transfer/sec:    153.67KB

image


总结

QPS(ASP.NET Core + Kestrel):26730.83

QPS(Python Django + Kestrel ):1572.64

不知道是我运行的方式不对还是怎么,这个差距还是蛮大的,大概是17倍的差距。看来Python Web 在做针对于做大请求并发情况下,还是弱了一点。

5 – ASP.NET Core vs Java Servlet

C# 和 JAVA 一直是两大阵营的开发人员喜欢讨论的话题,为了避免有阵营偏见,JAVA的源代码是我委托我们一个JAVA同事编写的,并且委托由他部署的,并且已经交代了他避免使用jsp,由Servlet直接输出。

ASP.NET Core

  • 环境:虚拟机器2
  • OS:Linux
  • Host:Kestrel
wrk -t 2 -c 50 -d 20 --latency http://192.168.2.48:5000/
Running 20s test @ http://192.168.2.48:5000/
  2 threads and 50 connections
  Thread Stats   Avg      Stdev     Max   +/- Stdev
    Latency     4.39ms    5.33ms  33.05ms   77.20%
    Req/Sec    13.43k     1.32k   17.95k    74.75%
  Latency Distribution
     50%    2.00ms
     75%    8.15ms
     90%   13.75ms
     99%   15.80ms
  534787 requests in 20.01s, 67.32MB read
Requests/sec:  26730.83
Transfer/sec:      3.37MB

image


Java Servlet

  • 环境:虚拟机器2
  • OS:Linux
  • Host:Tomcat 7.0 + jdk 1.7
wrk -t 2 -c 50 -d 20 --latency http://192.168.2.48:8080/j2eeWebApp/hello
Running 20s test @ http://192.168.2.48:8080/j2eeWebApp/hello
  2 threads and 50 connections
  Thread Stats   Avg      Stdev     Max   +/- Stdev
    Latency     4.93ms    6.17ms  68.17ms   81.53%
    Req/Sec     9.22k     1.01k   14.06k    70.50%
  Latency Distribution
     50%    1.75ms
     75%    9.91ms
     90%   14.39ms
     99%   22.10ms
  367733 requests in 20.05s, 93.70MB read
Requests/sec:  18338.73
Transfer/sec:      4.67MB

image


总结

QPS(ASP.NET Core + Kestrel):26730.83

QPS(Java Servlet + Tomcat):18338.73

通过这个结果我们可以看出,在性能上 ASP.NET Core 已经超越了Java。不说太多了,怕被喷…

6 – ASP.NET Core vs NodeJS

ASP.NET Core

  • 环境:虚拟机器2
  • OS:Linux
  • Host:Kestrel
wrk -t 2 -c 50 -d 20 --latency http://192.168.2.48:5000/
Running 20s test @ http://192.168.2.48:5000/
  2 threads and 50 connections
  Thread Stats   Avg      Stdev     Max   +/- Stdev
    Latency     4.39ms    5.33ms  33.05ms   77.20%
    Req/Sec    13.43k     1.32k   17.95k    74.75%
  Latency Distribution
     50%    2.00ms
     75%    8.15ms
     90%   13.75ms
     99%   15.80ms
  534787 requests in 20.01s, 67.32MB read
Requests/sec:  26730.83
Transfer/sec:      3.37MB

NodeJS

  • 环境:虚拟机器2
  • OS:Linux
  • Host:self host
wrk -t 2 -c 50 -d 20 --latency http://192.168.2.48:1337
Running 20s test @ http://192.168.2.48:1337
  2 threads and 50 connections
  Thread Stats   Avg      Stdev     Max   +/- Stdev
    Latency     4.40ms    5.23ms  31.25ms   79.47%
    Req/Sec    10.32k     0.88k   11.37k    90.25%
  Latency Distribution
     50%    2.08ms
     75%    8.32ms
     90%   13.19ms
     99%   15.93ms
  410902 requests in 20.02s, 61.13MB read
Requests/sec:  20522.89
Transfer/sec:      3.05MB

image

***************更新1:NodeJS 添加Web框架*******

Express框架,cluster模式

wrk -t 2 -c 30 -d 20 --latency http://192.168.2.48:1337
Running 20s test @ http://192.168.2.48:1337
  2 threads and 30 connections
  Thread Stats   Avg      Stdev     Max   +/- Stdev
    Latency     1.97ms    1.45ms  32.23ms   83.97%
    Req/Sec     7.83k     0.90k    8.82k    91.50%
  Latency Distribution
     50%    2.00ms
     75%    2.50ms
     90%    3.50ms
     99%    6.00ms
  311896 requests in 20.01s, 66.03MB read
Requests/sec:  15583.99
Transfer/sec:      3.30MB

Koa框架,cluster模式

wrk -t 2 -c 30 -d 20 --latency http://192.168.2.48:1337
Running 20s test @ http://192.168.2.48:1337
  2 threads and 30 connections
  Thread Stats   Avg      Stdev     Max   +/- Stdev
    Latency     1.74ms    0.86ms  13.59ms   86.65%
    Req/Sec     8.79k   804.39     9.98k    87.75%
  Latency Distribution
     50%    1.99ms
     75%    2.00ms
     90%    2.96ms
     99%    4.83ms
  349856 requests in 20.02s, 53.38MB read
Requests/sec:  17478.73
Transfer/sec:      2.67MB

从测试结果可以看出,Koa框架性能略高于Express框架。

**************End***********


总结

QPS(ASP.NET Core + Kestrel):26730.83

QPS(NodeJS):20522.89 (非cluster模式)
QPS(NodeJS Express):15583.99 (cluster模式)
QPS(NodeJS Koa):17478.73 (cluster模式)

这个结果着实让我吃了一惊,NodeJS性能竟然如此惊人,比JAVA要快10%。作为一个解释性语言这个性能可以说达到了极致,虽然在测试之前知道NodeJS采用的是异步IO,但还是被测试结果震惊了。

===========更新1=========

NodeJS 在加入了Web框架之后,性能仍然不弱。


不知道是不是因为NodeJS没有经过什么Web框架,直接输出的结果。所以我需要再加测一个ASP.NET Core 通过中间件直接输入结果的性能,这次我要使用微软的测试项目benchmarks。

wrk -t 2 -c 50 -d 20 --latency http://192.168.2.48:5000/plaintext
Running 20s test @ http://192.168.2.48:5000/plaintext
  2 threads and 50 connections
  Thread Stats   Avg      Stdev     Max   +/- Stdev
    Latency     3.69ms    5.03ms  18.30ms   80.38%
    Req/Sec    25.06k     4.14k   29.19k    83.33%
  Latency Distribution
     50%  806.00us
     75%    6.82ms
     90%   12.62ms
     99%   15.63ms
  1002476 requests in 20.10s, 126.20MB read
Requests/sec:  49874.57
Transfer/sec:      6.28MB

My God !!!

总结

以下是测试结果的汇总统计:

编号 对比方 系统环境 宿主环境 测试结果(QPS)
1 ASP.NET Core vs ASP.NET Core Windows Kestrel vs IIS 45.6k vs 15.2k
2 ASP.NET Core vs ASP.NET Windows IIS vs IIS 15.2k vs 18.2k
3 ASP.NET Core vs ASP.NET Windows Kestrel vs IIS 45.6k vs 18.2k
4 ASP.NET Core vs Python Django Linux Kestrel vs uwsgi 26.7k vs 1.57k
5 ASP.NET Core vs Java Servlet Linux Kestrel vs Tomcat 26.7k vs 18.3k
6-1 ASP.NET Core vs NodeJS Express Linux Kestrel vs self host 26.7k vs 15.6k
6-2 ASP.NET Core vs NodeJS Koa Linux Kestrel vs self host 26.7k vs 17.5k

image

作为微软的下一代 ASP.NET 框架,ASP.NET Core没有让我们失望,通过本次测试,我们大概对ASP.NET Core的性能心里有底了。一个圈子的良好发展需要社区的共同参与,也希望大家共同为.NET Core社区贡献自己的力量,同时也希望看到本篇文章的CTOs们以后在平台和框架选择的过程中考虑一下ASP.NET Core,因为她真的很优秀。

如果你觉得本篇博客对您有帮助的话,感谢您的【推荐】,如果你对.NET Core感兴趣可以关注我,我会定期在博客分享关于.NET Core的学习心得。


========更新1 :2016-10-17 感谢园友“幻天芒” 关于NodeJS的贡献======

有园友反应NodeJS项目没有使用web mvc框架,所以特更新,同时感谢 “幻天芒” 在github向nodeJS项目提交的PR。

1、添加node 多核cpu cluster 模式
2、添加node koa框架和express框架测试

更新测试结果。


========更新2 :2016-10-19 添加ASP.NET Core 在Windows Nano Server的测试结果======

环境:虚拟机器3,和Linux硬件一样

wrk -t 2 -c 30 -d 20 --latency http://192.168.2.52:8000
Running 20s test @ http://192.168.2.52:8000
  2 threads and 30 connections
  Thread Stats   Avg      Stdev     Max   +/- Stdev
    Latency     1.08ms  709.98us  31.25ms   77.30%
    Req/Sec    13.98k     1.38k   15.80k    87.75%
  Latency Distribution
     50%    1.00ms
     75%    1.03ms
     90%    2.00ms
     99%    3.45ms
  556354 requests in 20.03s, 70.04MB read
Requests/sec:  27780.50
Transfer/sec:      3.50MB

这个测试结果和微软的测试结果是一致的,Nano Server大概比在Linux上高出5-10%的性能。


========更新3 :2016-12-30 添加 WebListener 测试 ======

WebListener 是基于 Http.sys 实现的非跨平台只能运行于 Windows 的一个 web 服务器,其目的我觉得是为了替代iis的性能不足问题。

引用自QQ群 Lyrics:我的理解是这样的,Kestrel是跨平台的,定义了一套通用的 feature,然而目前在windows平台上,Kestrel所具备的feature 并没有 http.sys 提供的那么强大,为了使老系统能顺利迁移到core上面,微软不得已搞了一个能支持所有http.sys 的web server,就是weblistener, weblistener 能完整的利用 http.sys 的特性,在windows上功能完整。

测试结果:

Windows ASP.NET Core Kestrel :35.5k

Windows ASP.NET Core WebListener:27.9k

Kestrl 大概比 WebListener 高出 5-10%的性能。


本文地址:http://www.cnblogs.com/savorboard/p/dotnet-benchmarks.html
作者博客:Savorboard
欢迎转载,请在明显位置给出出处及链接


ASP.NET Core: 全新的ASP.NET !

背景

最新版本的 ASP.NET 叫做 ASP.NET Core (也被称为 ASP.NET 5)   它颠覆了过去的 ASP.NET。

什么是 ASP.NET Core?

ASP.NET Core 1.0 是一个开源跨平台的开发框架,用于构建基于云的现代 Web 应用 。它是从底层开始重新构建来提供性能优良的Web应用开发框架,可以部署在云上或者本地服务器上。另外,它使得 ASP.NET 应用更加精简和模块化(可以根据你的应用需要向里面添加其他模块),跨平台(你可以很容易的在 Windows, Mac or Linux 上开发和部署你的应用),云优化(你可以在云上在云上部署和调试你的应用)。

以前的版本

对于使用 ASP.NET 旧版本的我们来说,这意味着什么?

如果你正在使用旧版本的 ASP.NET 或者你有 WebForms 的开发背景,那么你将会认识到 ASP.NET Core 有多完美,这感觉起来就像从古典的 ASP 时代来到全新的 ASP.NET 的世界。

1

现在,让我们来一探究竟

下面列出 ASP.NET Core 1.0 的核心变化.

跨平台的运行时

你可以在 OSX 和 Linux上运行 ASP.NET Core 应用,这对于 ASP.NET 来说,这具有跨时代的意义,也给 ASP.NET 开发者和设计师们带来了全新的体验。ASP.NET Core 具有两个运行时,这意味着你可以选择不同的运行环境来部署你的应用,使得你的应用将更加灵活。

ASP.NET Core 1.0 是一个 ASP.NET 的重构版本,它运行于最新的 .NET Core。它是模块化的,允许开发者以插件的形式添加应用所需要的模块,大多数的功能都将作为插件提供并通过 NuGet 程序包管理。这样做的一个好处就是你可以升级应用的一个模块,但丝毫不会影响其他模块;另外,.NET Core 是一个跨平台的运行时,因此你可以在 OSX 或 Linux 操作系统上部署你的应用;它也是一个云优化的运行时,用于在云上部署和调试应用;.NET Core 可以和你的应用程序一起被部署,当服务器上有多个 .NET Core 版本时, 你依旧可以运行 ASP.NET Core 应用。

你也可以创建只运行在 windows 下完整 .NET 框架的 ASP.NET Core 应用。

ASP.NET 4.6 是最新的完整 .NET Framework 的发布版本,它允许你可以利用所有的 .NET 组件并且具备向后兼容能力。如果你计划将应用迁移到 .NET core,那么你需要做适量的修改,因为 .NET Core 相对于完整 .NET Framework 来说有所限制。

需要明确的是,ASP.NET 4.6 更加成熟。它如今久经考验并且现已发布并可使用。ASP.NET Core 1.0 是1.0 发布版本,包含 Web API 和 MVC,但是现在还没有 SignalR 和 Web Pages。,它也不支持VB 和 F# 语言。

ASP.NET Core 不再只依赖Visual Studio

ASP.NET Core 的跨平台,让它不再只依赖 Visual Studio,开发者和设计师们可以在自己喜欢的环境上工作。比如 Sublime Text,WebStorm ,这真是太棒了!

新的工程解决方案结构

如果你使用 Visual Studio 创建了一个空的 ASP.NET Core 工程,那么你将会看到下面的惊喜。(除非你没有使用之前的 ASP.NET 创建过任何项目)

2

你感觉到惊喜了吗?新的工程结构完全不一样了, 工程模板焕然一新,包含以下的新文件:

· global.json: 你可以在这里放置解决方案的配置信息和工程之间的引用。

· Program.cs: 这个文件包含了 ASP.NET Core RC2 应用的 Main 方法,负责配置和启动应用程序。

· src folder: 包含组成你应用程序的全部项目代码。

· wwwroot: 你的静态文件将被放置在这个文件夹,它们都将作为资源直接提供给客户端,包含 HTML,CSS 和 JavaScript 文件。

· project.json: 包含项目设置。在 ASP.NET Core中,你可以通过使用 NuGet 程序包管理工具(NPM)添加 NuGet 包或者编辑这个文件来管理从属。你可以通过任何文本编辑器来编辑这个文件,如果你使用 Visual Studio 2015,,这将会更加 轻松,因为它的智能提示会帮助你找到合适的 NuGet 包作为从属。project.json 就像下面这样。

3

· startup.cs 这个主要放置你 ASP.NET Core 的 stratup 和 configuration 代码,下面就是 stratup 类的样子。

4

ConfigureServices 方法定义了你应用程序使用的服务,Configure 方法用来定义组成请求管道的中间件。

· References: 它包含了 .NETCoreApp 第一个版本运行时的引用。

WebForms

是的,WebForms 不再是 ASP.NET 5 的一部分,这真令人悲伤。你可以继续使用 VS2015 的 .NET 4.6 来构建 Web Forms 应用,但是却不能体会 ASP.NET 5 的新特性了。

我已经开发了很多年从小型到大型的企业级 Web Forms 应用。 我很喜欢 Web Forms,,事实上我还会继续支持在各种论坛使用 WebForms 的社区,比如 http://forums.asp.net。但是我们是时候进步了,去学习一些新东西。这是学习 ASP.NET MVC 最后的时间了,就像过去的许多事物,你要么去适应,要么被淘汰。

除了 WebForms, the .NET Core 也没有包含 Windows Forms, WCF, WPF, Silverlight 等等。

VB.NET and F#

目前,在当前 ASP.NET Core 1.0 RC2 版本中, VB.NET 和 F# 也不被支持。

MVC Core 统一架构

5


ASP.NET Core 将见证 MVC, Web API 和 Web Pages(可能包含)组合在一个架构中,它被称为 ASP.NET MVC Core。尽管当前发布版本中,还不支持 Web Pages and SignalR。

在之前的 ASP.NET MVC 中, MVC 控制器和 Web API 控制器是不同的。 一个 MVC 控制器使用基类 System.Web.MVC.Controller ,一个 Web API 控制器使用基类 System.Web.Http.ApiController 。 在 MVC Core 中,会为它们提供一个共同的基类,就是 Microsoft.AspNetCore.Mvc.Controller

对于 HTML Helpers 来说,MVC 和 Web Pages 的合并是非常有可能的。 Web Pages 编程模型对当前版本来说还不适用,所以我们还不能负责任地说下一步计划合并哪些特性。 但是我们可以预测到,传统的 MVC 模型绑定将会出现。

View Components

在之前 ASP.NET MVC 中,, Html.Action() 帮助方法一般用于调用一个 sub-controller。ASP.NET MVC Core 将会使用新的 View Components 用来代替使用Html.Action() 的部件。

View Components 支持完全异步,这允许你创建异步的视图组件。

下面是一个简单的视图组件的例子,根据身份会返回个人介绍。

using Microsoft.AspNetCore.Mvc;  
using MVC6Demo.Models;  
using System.Threading.Tasks;  
using System.Collections.Generic;  
  
namespace MVC6Demo.ViewComponents  
{  
    public class PersonListViewComponent : ViewComponent  
    {  
        public async Task<iviewcomponentresult> InvokeAsync(string status) {  
            string viewToUse = "Default";  
            bool isFiltered = false;  
  
            PersonModel model = new PersonModel();  
  
            if (status.ToLower().Equals("registered")) { 
                viewToUse = "Registered"; isFiltered = true; 
            }  
                  
            var p = await GetPersonAsync(status, isFiltered);  
            return View(viewToUse,p);  
        }  
          
        private Task<ienumerable<person>> GetPersonAsync(string status, bool isFiltered) {  
            return Task.FromResult(GetPerson(status,isFiltered));  
        }  
        private IEnumerable<person> GetPerson(string status, bool isFiltered) {  
            PersonModel model = new PersonModel();  
  
            if (isFiltered)  
                return model.GetPersonsByStatus(status);  
            else  
                return model.GetAll;  
  
        }  
    }  
}  </person>

下面是 View Component 的视图:

<h3>Person List</h3>  
<ul>  
    @foreach (var p in Model) {  
        <li>@string.Format("{0} {1}",p.FirstName,p.LastName)</li>  
    }  
</ul>

这里展示了如何在主视图中调用 View Components

<div>   
    @await Component.InvokeAsync("PersonList", new { type = "Registered" })
</div>

新指令: @inject, @using, @inherits

ASP.NET MVC Core 提供了少量新指令。 下面我们来看看如何使用 @inject。 @inject 指令允许你注入一个类中的方法到你的视图中。

这是一个简单的类,来展示一些异步的方法。

using System.Threading.Tasks;  
using System.Linq;  
  
namespace MVC6Demo.Models  
{  
    public class Stats  
    {  
        private PersonModel _persons = new PersonModel();  
  
        public async Task<int> GetPersonCount() {  
            return await Task.FromResult(_persons.GetAll.Count());  
        }  
  
        public async Task<int> GetRegisteredPersonCount() {  
            return await Task.FromResult(
                      _persons.GetAll.Where(o => o.Status.ToLower().Equals("registered")).Count());  
        }  
  
        public async Task<int> GetUnRegisteredPersonCount() {  
            return await Task.FromResult(
                     _persons.GetAll.Where(o => o.Status.ToLower().Equals("")).Count());  
        }  
    }  
}

现在我们就可以在视图中使用 @inject 指令来调用那些方法:

@inject MVC6Demo.Models.Stats Stats  
  
@{  
    ViewBag.Title = "Stats";  
}  
  
<div>

这是不是很酷?

查看我关于 ASP.NET MVC 新指令详细例子的文章: Getting Started with ASP.NET MVC Core

Tag Helpers

ASP.NET MVC Core 另外一个非常酷的东西就是 Tag Helpers。对于之前的 HTML Helpers,Tag Helpers 是可选的替代语法。

所以相比于以下代码:

@using (Html.BeginForm("Login", "Account", FormMethod.Post, 
        new { @class = "form-horizontal", role = "form" }))
            {
                @Html.AntiForgeryToken()
                <h4>Use a local account to log in.</h4>
                <hr />
                @Html.ValidationSummary(true, "", new { @class = "text-danger" })
                <div class="form-group">
                    @Html.LabelFor(m => m.UserName, new { @class = "col-md-2 control-label" })
                    <div class="col-md-10">
                        @Html.TextBoxFor(m => m.UserName, new { @class = "form-control" })
                        @Html.ValidationMessageFor(m => m.UserName, "", new { @class = "text-danger" })
                    </div>
                </div>
}

你可以使用这些代码:

<form asp-controller="Account" asp-action="Login" method="post" class="form-horizontal" role="form">  
    <h4>Use a local account to log in.</h4>  
    <hr />  
    <div asp-validation-summary="ValidationSummary.ModelOnly" class="text-danger"></div>  
    <div class="form-group">  
        <label asp-for="UserName" class="col-md-2 control-label"></label>  
        <div class="col-md-10">  
            <input asp-for="UserName" class="col-md-2 control-label" />  
            <span asp-validation-for="UserName" class="text-danger"></span>  
        </div>  
    </div>  
</form>

ASP.NET Core 不止可以部署在IIS上

14年前,ASP.NET 平台基本只能部署在一种服务器上,那就是 IIS。几年之后,Visual Studio Development Web Server(也叫作“Cassini”)作为一种开发服务被使用,但是它们最终都是调用 System.Web 作为应用程序和 Web 服务器中间的主机层。System.Web 主机与 IIS 耦合度很高,所以要想运行在另一台主机上会非常困难。

后来 OWIN 作为应用程序和 Web 服务器中间的接口出现。 Microsoft 开发了 Katana 作为一个 OWIN 的实现,可以部署 ASP.NET Web API, SignalR 和其他第三方框架,这些框架可以在 IIS 和 IIS Express, Katana’s 自托管主机和自定义主机。

ASP.NET Core 是不强调主机的,它在 Katana 和 OWIN 上行为一致。ASP.NET Core 也可以部署在 IIS, IIS Express 或者自托管在你自己的进程里。另外,ASP.NET Core 也会包含一个叫做 Kestrel 的 Web 服务器,它建立在 libuv 上,主要用于 iOS 和 Linux 操作系统。

新的HTTP请求管道

ASP.NET Core 提供了一种更加模块化的 HTTP 请求管道, 你可以只添加你需要的组件。这个管道不再依赖 System.Web,通过降低管道中的开销,你的 app 性能更加优良,更好的调谐 HTTP 协议栈。新的管道基于 Katana 项目经验,同时支持 OWIN。

动态的Web开发

Visual Studio 2015 中另一个非常酷的特性就是支持动态编译。在过去的 ASP.NET 中,当我们修改了应用的后台代码,我们需要重新编译并且运行才能看到页面的变化。 在新版本的 Visual Studio 中,你不需要再做这些额外的步骤,仅仅是保存你的修改和刷新浏览器即可。

6

这是在刷新页面之后的输出:

7

Attribute Routing: [controller] 和 [action] 标记

在过去的 MVC 和 Web API 中,使用路由属性可能会导致一些问题,尤其是你正在做一些代码重构。这是因为路由必须设定为字符串类型,当你修改了控制器的名字,你就必须修改路由属性的字符串

MVC Core 提供了新的 [controller] 和 [action] 标记,它们可以解决这个问题。下面这篇文章重点说明了这些新标记的用法。 : ASP.NET MVC 6 Attribute Routing.

集成的依赖注入 (DI)

ASP.NET Core 内嵌了对依赖注入和 Service Locator 模式的支持,这意味着你不在需要通过第三方依赖注入框架 Ninject 或 AutoFac。

集成 Grunt, Gulp and Bower

Visual Studio 2015 内嵌了对流行开源 Web 开发工具的支持。 Grunt 和 Gulp 可以帮你自动化构建 Web 开发工作流, 你可以使用它们来编译和压缩 JavaScript 文件。Bower 是一个用于客户端库的管理工具,包含 CSS 和 JavaScript 库。

内置的AngularJs模板

AngularJs 是当前最流行的前端框架之一,用于构建单页面应用程序(SPAs)。Visual Studio 包含了用于创建 AngularJs 模块,控制器,指令和工厂。

8

对 GruntJS 的支持使得 ASP.NET 成为一个用于构建客户端 AngularJs 应用的优秀服务器端框架。 当完成一个版本,你可以自动合并和压缩全部 AngularJs 文件。查看我的关于开始在 ASP.NET 中使用 Angular 和 Angular2 的文章 。

· ASP.NET 5: Jump Start to AngularJS with MVC 6 Web API

· ASP.NET Core:Getting Started with AngularJS 2

SignalR 3

ASP.NET Core 也是以 SignalR 3 为基础,这使得你可以向云连接的应用程序添加实时功能。查看我之前的 SignalR 例子: ASP.Net SignalR: Building a Simple Real-Time Chat Application

Web.Config

在 ASP.NET Core 中,混乱的 web.config 文件被新的云就绪配置文件代替,它称作 “config.json”。微软希望开发人员更容易地在云中部署应用程序,并使得应用能够根据特殊环境自动的读取正确的配置参数。

这是一个新的配置文件的样子:

9

由于 ASP.NET Core 都是插件化的,你需要配置 Stratup 类的源代码,就像下面这样:

 public Startup(IHostingEnvironment env)
        {
            var builder = new ConfigurationBuilder()
                .SetBasePath(env.ContentRootPath);

            builder.AddEnvironmentVariables();
            Configuration = builder.Build();
        }
        public IConfigurationRoot Configuration { get; }
        public void ConfigureServices(IServiceCollection services)
        {
            services.AddMvc();
            services.AddTransient<MVC6Demo.Models.HeroStats>();
        }

        public void Configure(IApplicationBuilder app)
        {
            app.UseDeveloperExceptionPage();


            app.UseMvc(m => {
                m.MapRoute(
                    name: "default",
                    template: "{controller}/{action}/{id?}",
                    defaults: new { controller = "Home", action="Index"});
            });
        }

xUnit.Net: .NET 新的单元测试工具

在之前的 ASP.NET MVC 中,默认的测试框架是 Visual Studio 单元测试框架(有时候也叫作mstest),这个框架使用 [TestClass] 和 [TestMethod] 特性来描述一个单元测试。

ASP.NET Core 使用 xUnit.net 作为它的单元测试框架。这个框架使用 [Fact] 特性来代替 [TestMethod] 特性,也消除了对 [TestClass] 属性的依赖。

绝对的免费和开源

是的,ASP.NET Core 被作为一个开源项目托管到 GitHub上, 你可以查看源代码,并下载并提交你的更改。

我认同开源的 .NET 会产生重大的意义,它产生了积极的商业意义和社区意义,十分感谢微软所做出的工作。

以上 ASP.NET Core 1.0 的新特性和新概念的介绍,是为了更好的帮助我们使用 ASP.NET Core 进行开发,同时在开发过程中,我们还可以借助一些好的工具来提高开发效率,并减少代码量,如 ComponentOne Studio for Asp.net MVC,它兼容 ASP.NET Core RC2 版本,是一款快速轻量级的控件来满足用户的所有需求。

 

文章来源:By Vincent Maverick Durano, 10 Jun 2016 

原文链接:http://www.codeproject.com/Articles/1104668/Introducing-ASP-NET-Core-The-New-ASP-NET-in-Town

葡萄城控件产品网站:http://www.gcpowertools.com.cn/
葡萄城企业软件网站:http://qy.grapecity.cn/
葡萄城技术支持论坛:http://gcdn.gcpowertools.com.cn/forum.php