分布式缓存框架：

Microsoft Velocity：微软自家分布式缓存服务框架。

Memcahed：一套分布式的高速缓存系统，目前被许多网站使用以提升网站的访问速度。

Redis：是一个高性能的KV数据库。 它的出现很大程度补偿了Memcached在某些方面的不足。

EnyimMemcached：访问Memcached最优秀的.NET客户端，集成不错的分布式均衡算法。

开源的.NET系统推荐：

OXITE：微软ASP.NET MVC案例演示框架。

PetShop：微软ASP.NET宠物商店。

Orchard：国外一个MVC开源的博客系统。

SSCLI：微软在NET Framework 2.0时代的开源代码。

DasBlog：国外一个基于ASP.NET的博客系统。

BlogEngine.NET：国外一款免费开源的博客系统。

Dotnetnuke.NET：一套非常优秀的基于ASP.NET的开源门户网站程序。

Discuz.NET：国内开源的论坛社区系统。

nopCommerce和Aspxcommerce：国外一套高质量的开源B2C网站系统。

JumboTCMS和DTCMS：国内两款开源的网站管理系统：

日志记录异常处理：

Log4Net：轻量级的免费开源.NET日志记录框架。

Enterprise Library Log Application Black：微软企业库日志记录。

Elmah：实现最流行的ASP.NET应用异常日志记录框架。

NLog：是一个简单灵活的日志记录类库，性能比Log4Net高，使用和维护难度低。

关于NoSQL数据库：

Mongodb：分布式文件存储数据库。

Membase：家族的一个新的重量级的成员。

自动任务调度框架

Quartz.NET：开源的作业调度和自动任务框架。

Topshelf：另一种创建Windows服务的开源框架

依赖注入IOC容器框架：

Unity：微软patterns&practicest团队开发的IOC依赖注入框架，支持AOP横切关注点。

MEF（Managed Extensibility Framework）：是一个用来扩展.NET应用程序的框架，可开发插件系统。

Spring.NET：依赖注入、面向方面编程(AOP)、数据访问抽象,、以及ASP.NET集成。

Autofac：最流行的依赖注入和IOC框架，轻量且高性能，对项目代码几乎无任何侵入性。

PostSharp：实现静态AOP横切关注点，使用简单，功能强大，对目标拦截的方法无需任何改动。

Ninject：基于.NET轻量级开源的依赖注入IOC框架

常用的几个ORM框架：

EF（ADO.NET Entity Framework）：微软基于ADO.NET开发的ORM框架。

Nhibernate：面向.NET环境的轻量级的ORM框架。

SqlMapper.cs：用于小项目的通用的C#数据库访问类。

AutoMapper：流行的对象映射框架，可减少大量硬编码，很小巧灵活，性能表现也可接受。

SubSonic：优秀的开源的ORM映射框架，同时提供符合自身需要的代码生成器。

FluentData：开源的基于Fluent API的链式查询ORM轻量级框架。

Dapper：轻量级高性能基于EMIT生成的ORM框架。

EmitMapper：性能较高的ORM框架，运行时通过EMIT动态生成IL代码，并非采用反射机制。

格式和数据类型转换

DotNetZip：轻便灵活的压缩\解压组件。

Newtonsoft.Json：目前.NET开发中最流行的JSON序列化库，为新版的WebApi库提供基础。

System.JSON.dll：微软自己开发的JSON序列化组件（需要单独下载）

DataContractJsonSerializer 和 DataContractXmlSerializer：微软在WCF中使用的序列化器。

JavaScriptSerializer：微软默认针对WEB开发者提供的JSON格式化器。

iTextSharp、PDFsharp 和 PDF.NET：通过.NET处理和生成PDF文档的组件。

SharpZipLib.dll：免费开源的ZIP和GZIP文件解压缩组件。

Math.NET：强大的数学运算、微积分、解方程和科学运算。

DocX：不需要安装word软件，通过C#操作word文件。

SharpSerializer：开源XML和、二进制、JSON、压缩和优化框架。

反射和动态语言

Clay dynamic：开源的动态语言dynamic框架让您形如javascript的方式创建对象。

ExposedObject：在类的外部通过动态语言dynamic的方式访问私有成员。

PrivateObject：微软单元测试框架中便捷在外部调用类内部私有成员的一个类。

跨平台和运行时解决方案

MONO.NET：跨平台的.NET运行环境，让.NET跨平台运行成为可能。

DotGnu Portable.NET：类似于MONO.NET的跨平台运行时。

Phalanger：将PHP编译成.NET，可实现PHP与.NET互操作。

VMDotNet：中国移动飞信所使用过的.NET运行时。

Unity3D：微软大力支持的机遇C#和JavaScript的跨平台游戏开发框架。

Cassini、IIS Express和Cassinidev：开源的ASP.NET执行环境。

Katana：微软基于OWIN规范实现的非IIS寄宿ASP.NET和MVC等。

IKVM.NET：基于.NET的JAVA虚拟机，让JAVA运行在.NET之上。

WEB开发和设计

Jumony Core：基于.NET开发的HTML引擎。

Microsoft.mshtml.dll、Winista.HtmlParser.dll 和 HtmlAgilityPack.dll：解析处理HTML文档的框架。

JavaScript.NET和ClearScript（微软出品）：基于.NET开发的JavaScript引擎。

NCrawler：其HTML处理引擎htmlagilitypack的的开源网络爬虫软件。

AntiXSS：微软官方预防跨站XSS脚本入侵攻击的开源类库，它通过白名单机制进行内容编码。

YUICompressor.NET、Microsoft Ajax Minifier 和 Google Closure Compiler：JavaScrip和CSS压缩器。

NancyFx：是一个不错的轻量级开源.NET WEB框架。如果想快速做个简单的WEB应用。

AspNetPager：国内知名的ASP.NET分页控件，支持多种分页方式。

NOPI.dll：导出Excel报表的插件（基于微软OpenXml实现）（nopi.css.dl通过css设置样式）

Enterprise Library：微软针对企业级应用开发的最佳实践组件。

PowerCollections：国外一个牛人写的高级开源集合。

移动互联网和云计算

PushSharp：通过.NET向各种移动平台推送消息。

mono for android：用.NET语言开发安卓应用：

MonoTouch：用.NET语言开发IOS应用。

PhoneGap和AppCan：跨平台基于HTML5的移动开发平台。

Cordova：PhoneGap贡献给Apache后的开源项目，是驱动PhoneGap的核心引擎。

网络通信和网络协议

SuperSocket：基于.NET轻量级的可扩展的Socket开发框架。

SuperWebSocket：通过.NET实现TML5 WebSocket框架。

XProxy：支持插件的基础代理程序集，内置NAT、加解密、反向、直接和间接代理。

图形和图像处理框架

Paint.NET：基于.NET小巧灵活强大的图形处理开源项目。

Imagemagick.NET：用C#对开源图像处理组件Imagemagick的封装。

Skimpt：基于.NET开源的屏幕截图软件。

ImageGlue.NET：商业的图像处理组件，支持的格式列了一大堆。

Sprite and Image Optimization Framework：微软CSS精灵，多图合成一张大图和CSS样式。

桌面应用程序框架

DevExpress：一个全球知名的桌面应用程序UI控件库。

Prism：微软开发的针对WPF和Silverlight的MVVM框架，通过功能模块化的思想，来讲复杂的业务功能和UI耦合性进行分离。

WPFToolkit 和 Fluent Ribbon Control Suite：开发类似于Office风格的Ribbon菜单。

测试和性能评估方面

Faker.Net：方便生成大批量测试数据的框架。

Nunit：一个轻量级的单元测试框架。

Moq：非常流行的Mock框架，支持LINQ，灵活且高性能。

xUnit：比NUnit更好的单元测试框架，升级改进版的Nunit框架。

MiniProfiler和Glimpse：基于MVC的两款性能事件监控框架。

事务和分布式事务支持

KtmIntegration：一个支持NTFS文件系统的事务开源类。

NET Transactional File Manager：对文件系统操作（复制、移动和删除）加入事务支持。

分词、全文检索和搜索引擎

Lucene.net：流行高性能的全文索引库，可用于为各类信息提供强大的搜索功能。

Lucene.Net.Analysis.PanGu：支持Lucene.Net最新版的盘古中文分词扩展库。

数据验证组件整理

FluentValidation for .NET：基于LINQ表达式方法链Fluent接口验证组件。

Microsoft.Practices.EnterpriseLibrary.Validation.dll：微软企业库验证程序块。

CuttingEdge.Conditions：基于Fluent接口方法练接口的契约编程组件。

DotNetOpenAuth：让网站具备支持OpenID、OAuth、InfoCard等身份验证的能力。

开源图表统计控件：

Visifire：一套效果非常好的WPF图表控件，支持3D绘制、曲线、折线、扇形、环形和梯形。
SparrowToolkit：一套WPF图表控件集，支持绘制动态曲线，可绘制示波器、CPU使用率和波形。
DynamicDataDisplay：微软开源的WPF动态曲线图，线图、气泡图和热力图。

消息队列

Kafka
Kafka是一种分布式的，基于发布/订阅的消息系统。主要设计目标如下：

以时间复杂度为O(1)的方式提供消息持久化能力，即使对TB级以上数据也能保证常数时间复杂度的访问性能。

高吞吐率。即使在非常廉价的商用机器上也能做到单机支持每秒100K条以上消息的传输。

支持Kafka Server间的消息分区，及分布式消费，同时保证每个Partition内的消息顺序传输。

同时支持离线数据处理和实时数据处理。

Scale out：支持在线水平扩展。

RabbitMQ

RabbitMQ是使用Erlang编写的一个开源的消息队列，本身支持很多的协议：AMQP，XMPP, SMTP, STOMP，也正因如此，它非常重量级，更适合于企业级的开发。同时实现了Broker构架，这意味着消息在发送给客户端时先在中心队列排队。对路由，负载均衡或者数据持久化都有很好的支持。

Redis

Redis是一个基于Key-Value对的NoSQL数据库，开发维护很活跃。虽然它是一个Key-Value数据库存储系统，但它本身支持MQ功能，所以完全可以当做一个轻量级的队列服务来使用。对于RabbitMQ和Redis的入队和出队操作，各执行100万次，每10万次记录一次执行时间。测试数据分为128Bytes、512Bytes、1K和10K四个不同大小的数据。实验表明：入队时，当数据比较小时Redis的性能要高于RabbitMQ，而如果数据大小超过了10K，Redis则慢的无法忍受；出队时，无论数据大小，Redis都表现出非常好的性能，而RabbitMQ的出队性能则远低于Redis。

ZeroMQ

ZeroMQ号称最快的消息队列系统，尤其针对大吞吐量的需求场景。ZeroMQ能够实现RabbitMQ不擅长的高级/复杂的队列，但是开发人员需要自己组合多种技术框架，技术上的复杂度是对这MQ能够应用成功的挑战。ZeroMQ具有一个独特的非中间件的模式，你不需要安装和运行一个消息服务器或中间件，因为你的应用程序将扮演这个服务器角色。你只需要简单的引用ZeroMQ程序库，可以使用NuGet安装，然后你就可以愉快的在应用程序之间发送消息了。但是ZeroMQ仅提供非持久性的队列，也就是说如果宕机，数据将会丢失。其中，Twitter的Storm 0.9.0以前的版本中默认使用ZeroMQ作为数据流的传输（Storm从0.9版本开始同时支持ZeroMQ和Netty作为传输模块）。

ActiveMQ

ActiveMQ是Apache下的一个子项目。 类似于ZeroMQ，它能够以代理人和点对点的技术实现队列。同时类似于RabbitMQ，它少量代码就可以高效地实现高级应用场景。

Kafka/Jafka

Kafka是Apache下的一个子项目，是一个高性能跨语言分布式发布/订阅消息队列系统，而Jafka是在Kafka之上孵化而来的，即Kafka的一个升级版。具有以下特性：快速持久化，可以在O(1)的系统开销下进行消息持久化；高吞吐，在一台普通的服务器上既可以达到10W/s的吞吐速率；完全的分布式系统，Broker、Producer、Consumer都原生自动支持分布式，自动实现负载均衡；支持Hadoop数据并行加载，对于像Hadoop的一样的日志数据和离线分析系统，但又要求实时处理的限制，这是一个可行的解决方案。Kafka通过Hadoop的并行加载机制统一了在线和离线的消息处理。Apache Kafka相对于ActiveMQ是一个非常轻量级的消息系统，除了性能非常好之外，还是一个工作良好的分布式系统。

前端性能会直接影响到用户体验，加载的延迟、操作的卡顿等都会影响用户的使用体验。尤其是移动端，用户对页面响应延迟和连接中断的容忍度很低。尽管性能很重要，开发迭代过程中难免会有所忽视，性能会伴随产品的迭代而有所衰减，事实上并没有简单的几条黄金规则就可以搞定性能优化工作，我们需要一套性能监控系统持续监控、评估、预警页面性能状况、发现瓶颈，指导优化工作的进行。

If you cannot measure it, you cannot improve it.

维度与指标

1. 前端性能指标无非是这几个值：

• 白屏时间；
• 首屏时间；
• 用户可交互时间；
• 总下载时间；
• DNS解析时间；
• TCP连接时间；
• HTTP请求时间；
• HTTP响应时间；

2. 关于维度：如果有心思去做IP分析，将「运营商」、「网络」、「URL」作为维度，实际每个指标都可以做出分布图 (图中数据经过处理，非真实数据)；

阈值：

1. 每个业务形态都不尽相同，不可能有统一的阈值，特别是配置短信/邮件报警的时候。
2. 当用户网络差异大的时候(特别是移动端)，平均数其实没什么用，也就看个概况，中位数也同理。比较好的方式还是做堆叠图，方便看分布。
3. 同比环比，报警功能，当然也是需要的。

引言

分布式系统指由网络连接的计算机系统，每个节点独立地承担计算或存储任务，节点间通过网络协同工作。

一致性是分布式理论中的根本性问题，近半个世纪以来，科学家们围绕着一致性问题提出了很多理论模型，依据这些理论模型，业界也出现了很多工程实践投影。下面我们从一致性问题、特定条件下解决一致性问题的两种方法(2PC、3PC)入门，了解最基础的分布式系统理论。

一致性(consensus)

何为一致性问题？简单而言，一致性问题就是相互独立的节点之间如何达成一项决议的问题。分布式系统中，进行数据库事务提交(commit transaction)、Leader选举、序列号生成等都会遇到一致性问题。这个问题在我们的日常生活中也很常见，比如牌友怎么商定几点在哪打几圈麻将。

假设一个具有N个节点的分布式系统，当其满足以下条件时，我们说这个系统满足一致性：

1. 全认同(agreement): 所有N个节点都认同一个结果
2. 值合法(validity): 该结果必须由N个节点中的节点提出
3. 可结束(termination): 决议过程在一定时间内结束，不会无休止地进行下去

有人可能会说，决定什么时候在哪搓搓麻将，4个人商量一下就ok，这不很简单吗？

但就这样看似简单的事情，分布式系统实现起来并不轻松，因为它面临着这些问题：

• 消息传递异步无序(asynchronous): 现实网络不是一个可靠的信道，存在消息延时、丢失，节点间消息传递做不到同步有序(synchronous)
• 节点宕机(fail-stop): 节点持续宕机，不会恢复
• 节点宕机恢复(fail-recover): 节点宕机一段时间后恢复，在分布式系统中最常见
• 网络分化(network partition): 网络链路出现问题，将N个节点隔离成多个部分
• 拜占庭将军问题(byzantine failure)[2]: 节点或宕机或逻辑失败，甚至不按套路出牌抛出干扰决议的信息

假设现实场景中也存在这样的问题，我们看看结果会怎样：

1
2
3
4
5
6
7
8
9
10
11
12
13
14

我: 老王，今晚7点老地方，搓够48圈不见不散！
……
（第二天凌晨3点） 隔壁老王: 没问题！       // 消息延迟
我: ……
----------------------------------------------
我: 小张，今晚7点老地方，搓够48圈不见不散！
小张: No ……                           
（两小时后……）
小张: No problem！                     // 宕机节点恢复
我: ……
-----------------------------------------------
我: 老李头，今晚7点老地方，搓够48圈不见不散！
老李: 必须的，大保健走起！               // 拜占庭将军
（这是要打麻将呢？还是要大保健？还是一边打麻将一边大保健……）

我们把以上所列的问题称为系统模型(system model)，讨论分布式系统理论和工程实践的时候，必先划定模型。例如有以下两种模型：

1. 异步环境(asynchronous)下，节点宕机(fail-stop)
2. 异步环境(asynchronous)下，节点宕机恢复(fail-recover)、网络分化(network partition)

2比1多了节点恢复、网络分化的考量，因而对这两种模型的理论研究和工程解决方案必定是不同的，在还没有明晰所要解决的问题前谈解决方案都是一本正经地耍流氓。

一致性还具备两个属性，一个是强一致(safety)，它要求所有节点状态一致、共进退；一个是可用(liveness)，它要求分布式系统24*7无间断对外服务。FLP定理(FLP impossibility) 已经证明在一个收窄的模型中(异步环境并只存在节点宕机)，不能同时满足 safety 和 liveness。

FLP定理是分布式系统理论中的基础理论，正如物理学中的能量守恒定律彻底否定了永动机的存在，FLP定理否定了同时满足safety 和 liveness 的一致性协议的存在。

工程实践上根据具体的业务场景，或保证强一致(safety)，或在节点宕机、网络分化的时候保证可用(liveness)。2PC、3PC是相对简单的解决一致性问题的协议，下面我们就来了解2PC和3PC。

2PC

2PC(tow phase commit)两阶段提交[5]顾名思义它分成两个阶段，先由一方进行提议(propose)并收集其他节点的反馈(vote)，再根据反馈决定提交(commit)或中止(abort)事务。我们将提议的节点称为协调者(coordinator)，其他参与决议节点称为参与者(participants, 或cohorts)：

在阶段1中，coordinator发起一个提议，分别问询各participant是否接受。

在阶段2中，coordinator根据participant的反馈，提交或中止事务，如果participant全部同意则提交，只要有一个participant不同意就中止。

在异步环境(asynchronous)并且没有节点宕机(fail-stop)的模型下，2PC可以满足全认同、值合法、可结束，是解决一致性问题的一种协议。但如果再加上节点宕机(fail-recover)的考虑，2PC是否还能解决一致性问题呢？

coordinator如果在发起提议后宕机，那么participant将进入阻塞(block)状态、一直等待coordinator回应以完成该次决议。这时需要另一角色把系统从不可结束的状态中带出来，我们把新增的这一角色叫协调者备份(coordinator watchdog)。coordinator宕机一定时间后，watchdog接替原coordinator工作，通过问询(query) 各participant的状态，决定阶段2是提交还是中止。这也要求 coordinator/participant 记录(logging)历史状态，以备coordinator宕机后watchdog对participant查询、coordinator宕机恢复后重新找回状态。

从coordinator接收到一次事务请求、发起提议到事务完成，经过2PC协议后增加了2次RTT(propose+commit)，带来的时延(latency)增加相对较少。

3PC

3PC(three phase commit)即三阶段提交[6][7]，既然2PC可以在异步网络+节点宕机恢复的模型下实现一致性，那还需要3PC做什么，3PC是什么鬼？

在2PC中一个participant的状态只有它自己和coordinator知晓，假如coordinator提议后自身宕机，在watchdog启用前一个participant又宕机，其他participant就会进入既不能回滚、又不能强制commit的阻塞状态，直到participant宕机恢复。这引出两个疑问：

能不能去掉阻塞，使系统可以在commit/abort前回滚(rollback)到决议发起前的初始状态
当次决议中，participant间能不能相互知道对方的状态，又或者participant间根本不依赖对方的状态

相比2PC，3PC增加了一个准备提交(prepare to commit)阶段来解决以上问题：

coordinator接收完participant的反馈(vote)之后，进入阶段2，给各个participant发送准备提交(prepare to commit)指令。participant接到准备提交指令后可以锁资源，但要求相关操作必须可回滚。coordinator接收完确认(ACK)后进入阶段3、进行commit/abort，3PC的阶段3与2PC的阶段2无异。协调者备份(coordinator watchdog)、状态记录(logging)同样应用在3PC。

participant如果在不同阶段宕机，我们来看看3PC如何应对：

• 阶段1: coordinator或watchdog未收到宕机participant的vote，直接中止事务；宕机的participant恢复后，读取logging发现未发出赞成vote，自行中止该次事务
• 阶段2: coordinator未收到宕机participant的precommit ACK，但因为之前已经收到了宕机participant的赞成反馈(不然也不会进入到阶段2)，coordinator进行commit；watchdog可以通过问询其他participant获得这些信息，过程同理；宕机的participant恢复后发现收到precommit或已经发出赞成vote，则自行commit该次事务
• 阶段3: 即便coordinator或watchdog未收到宕机participant的commit ACK，也结束该次事务；宕机的participant恢复后发现收到commit或者precommit，也将自行commit该次事务

因为有了准备提交(prepare to commit)阶段，3PC的事务处理延时也增加了1个RTT，变为3个RTT(propose+precommit+commit)，但是它防止participant宕机后整个系统进入阻塞态，增强了系统的可用性，对一些现实业务场景是非常值得的。

小结

以上介绍了分布式系统理论中的部分基础知识，阐述了一致性(consensus)的定义和实现一致性所要面临的问题，最后讨论在异步网络(asynchronous)、节点宕机恢复(fail-recover)模型下2PC、3PC怎么解决一致性问题。

开发过程中使用到了vue框架进行前端批量数据的处理，将批量数据转换为json格式进行ajax传参时需要注意将vue数据源得到的json结果进行如下处理，webservice接收json数据时无法有效的识别双引号。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

//错误的json格式
//error_json:'[{ "Module_id": "", "Project_id": "", "Feature_type": "", "Feature_name": "", "Calc_type": "", "Alarm_type": "", "Alarm_channel": "", "Int_param1": "", "Int_param2": "", "Owner": [], "Follower": [] }]'
var feature_group_json = JSON.stringify(this.featureGroup);

//正确的json格式
//success_json:'{"featureGroupJson":"[{ \'Module_id\': \'\', \'Project_id\': \'\', \'Feature_type\': \'\', \'Feature_name\': \'\', \'Calc_type\': \'\', \'Alarm_type\': \'\', \'Alarm_channel\': \'\', \'Int_param1\': \'\', \'Int_param2\': \'\', \'Owner\': [], \'Follower\': [] }]"}'
feature_group_json = JSON.stringify(this.featureGroup).replace(/\"/g, "\\'"); 

//ajax请求webservice
$.ajax({
　　type: 'POST',
　　contentType: 'application/json;charset=utf-8',
　　url: 'your_url',
　　data: '{"featureGroupJson":"' + feature_group_json + '"}',
　　dataType: 'json',
　　success: function (data) {
　　　　alert("success");
　　}
});

设计一个安全的账号系统，很重要的一个方面就是如何保护用户的密码。保护用户密码最简单的方式就是使用带盐的密码hash(salted password hashing)。

具体的操作就是给密码加一个随机的前缀或者后缀，然后再进行hash。这个随机的后缀或者前缀成为“盐”。通过加盐，相同的密码每次hash都是完全不一样的字符串了。检查用户输入的密码是否正确的时候，我们也还需要这个盐，所以盐一般都是跟hash一起保存在数据库里，或者作为hash字符串的一部分。

如果需要达到更高的安全等级，可以考虑将salt值和最终hash结果存在不同的数据库。

比较加盐hash结果时，注意使用时间恒定的比较函数。

普通的情况下，在比较两个字符串时，函数是一个字符一个字符进行比较，如果某个字符不匹配就会立即返回。攻击者可以根据验证的时间长短来判断前几位字符是否正确，然后逐步修正最终得到正确的结果。

因此，在比较 hash 时，使用时间恒定的比较函数，可以让攻击者摸不着头脑。

Visual Studio配合IIS Express为Web开发提供了强劲的调试功能，本文介绍IIS Express如何在调试模式下让局域网的其他设备进行访问，以便进行测试。

1.打开IIS Express中对应站点的配置文件(IIS Express–>显示所有应用程序–>选中对应的站点–>配置文件–>applicationhost.config)

2.找到以下节点

1
2
3
4
5
6
7
8
9

<site name="${your project name}" id="xxx">
    <application path="/">
        <virtualDirectory path="/" physicalPath="${your physicalpath}" />
    </application>
    <bindings>
        <binding protocol="http" bindingInformation="*:8080:localhost" />
        <binding protocol="http" bindingInformation="*:8080:${ip地址}" />
    </bindings>                
</site>

在以下节点中配置程序的ip地址和端口

1
2
3
4
5
6

<binding protocol="http" bindingInformation="*:${端口}:${ip地址}" />
``` 

3.按上面配置后，当你通过IP地址访问时可能会出现400错误，如果出现，就采用下面的方法：

以管理员身份打开CMD命令窗口，执行如下命令：

netsh http add urlacl url=http://ip地址:端口/ user=everyone
`
重启IISExpress

4.如其他电脑还是无法访问服务,有可能是防火墙的原因：

打开windows防火墙高级设置,为指定端口新建入站规则即可。

高性能原则

• 减少阻塞调用：ASP.NET提供的工作线程有限，同步代码并不能高效的利用服务器的CPU，而且会产生阻塞，通过异步技术减少阻塞调用。
• 减少往返：通过缓存、合并请求（批处理）、合并源数据、合并响应等技术来减少客户端、web服务器、数据库之间的往返。
• 在所有架构层次采用缓存：浏览器缓存、Cookie、IIS缓存、服务器端针对每个请求的缓存、数据库依赖缓存、分布式缓存等。
• 优化数据库：权衡存储过程、事物、索引等技术的取舍。

ajax请求webservice返回json数据，数据规模过大时ajax请求会得到500的响应，webservice+ajax处理大规模的数据需要在web.config中进行如下配置:

1
2
3
4
5
6
7

<system.web.extensions>
    <scripting>
        <webServices>
            <jsonSerialization maxJsonLength="#####"/>
        </webServices>
    </scripting>
</system.web.extensions>

注:####为指定上限值

一、在没有权限操作IIS管理器的情况下，在Web.config中的system.webServer节点进行如下配置：

1
2
3
4
5
6

<system.webServer>    
    <staticContent>
        <remove fileExtension=".woff" />
        <mimeMap fileExtension=".woff" mimeType="font/x-font-woff" />      
    </staticContent>
</system.webServer>

配置是为了防止出现这个错误：“在唯一密钥属性“fileExtension”设置为“.woff”时，无法添加类型为“mimeMap”的重复集合项”，如果只添加下面的 这个节点，而且没有报这个错误的话，remove节点可以不用添加。另外”font/x-font-woff”是woff字体的MIME类型值。

二、在IIS中添加woff字体的MIME类型
打开控制面板中的IIS管理器，选择当前IIS，打开MIME类型配置，点击MIME类型右边操作的栏的添加功能，弹出的添加MIME类型对话框中，文件扩展名填写.woff，MIME类型可填写 font/x-font-woff 或者application/x-font-woff，点击确定后成功添加了.woff扩展名的MIMI TYPE，现在打开网站请求WOFF字体就不会出现404 NOT FOUND错误了。

三、woff字体简介

Web开放字体格式（Web Open Font Format，简称WOFF） 是一种网页所采用的字体格式标准。此字体格式发展于2009年，现在正由万维网联盟的Web字体工作小组标准化，以求成为推荐标准。此字体格式不但能够有效利用压缩来减少档案大小，并且不包含加密也不受DRM（数位著作权管理）限制。

在2010年4月8日，Mozilla基金会、Opera软件公司和微软提交WOFF之后，万维网联盟发表评论指，希望WOFF不久能成为所有浏览器都支持的、“单一、可互操作的(字体)格式”。[6]2010年7月27日，万维网联盟将WOFF作为工作草案发布。

WOFF的MIME类型是：application/x-font-woff（font/x-font-woff也可以），目前的IIS7里面默认没有这个MIME类型，如果要让网站支持这个，请在IIS7里面的MIME类型里面添加woff。

1
2
3
4
5
6
7
8
9
10
11
12
13

$.ajax({
　　type: "post",
　　url: "your_webservice.asmx/you_method",
　　contentType: "application/json; charset=utf-8",
　　dataType: "json",
　　data: '{parameter_key:"parameter_value"}',
　　success: function (data) {
　　alert(data.d);
　　},
　　error: function () {
　　alert("fail");
　　}
});

注：数据格式均采用json