【对.NET系统架构改造的一点经验和教训】里面的几条对CSDN的改造的技术要点如下：
-
1.数据层放弃 SQL Server 数据库和存储过程，全部迁移到 Linux 平台上的 MySQL 数据库上； - 2.缓存不再依赖 .NET 自身提供的缓存机制，迁移到部署在 Linux 平台上的分布式的 Redis 上；
- 3.服务之间的调用，避免使用 .NET 自身专有协议，改成 Restful 的 HTTP Web API 调用；
- 4.静态资源请求，不再让 IIS 自己处理，分离到 Linux 平台上的 Nginx 去处理；
- 5.需要读取的文件系统，也改成访问 Linux 平台上的分布式文件系统；
- 6.部署 .NET 代码的 Windows 服务器放在 LVS 后面，用 LVS 做负载均衡和故障切换。
数据库应该采用SqlServer还是Mysql
作为web 程序web端从来都不是瓶颈，瓶颈从来都是在数据端。按照正常的逻辑，.net的执行速度要比php快，原因是.net是编译性的，php是解释性的。但是目前很多大型网站都部署在php下面。主要是php的现成的解决方案比较多。
如果一个系统出现问题从来都不是语言的问题，而是架构的问题，或者说是架构者的问题。作为web服务，大部分时候的瓶颈都是在数据库上。有童鞋说到sqlserver数据库授权贵的问题，大家可以去qinfo上找一下大众点评一个讲座，他们用的是asp.net和mysql数据库。本质上SqlServer和MySQL都是作为结构化数据库，对开发人员来讲没有太大的不同。而数据库的可扩展性大致就是 1）数据库读写分离2）业务水平分区 3）大表垂直分区 。其他的就是细节上的实现了
缓存是用自身缓存还是分布式缓存
CSDN将缓存迁移到Redis， 个人觉得这个并不是.net自身缓存机制的问题，如果做分布式缓存，不管是用Memcache还是Redis，中间都间隔着机器，肯定没有web服务器缓存快，如果业务量小的话，采用缓存服务器来替代web自身的缓存机制其实是不划算的。当系统访问量达到一定程度，自身的缓存机制已经不能够满足系统的要求了，是肯定要切换到缓存服务器的。当然我想没有人会用windows服务器来做缓存服务器。不管是.net还是java或者php。用memchace/Redis的时候难道还有性能上的差别么。CSDN最先改版的应该是博客系统，和博客园的博客系统用的都是一家，不过现在修修改改已经早就不是原版的样子了。不过很难想想当年CSDN的博客那么大的用户量用.net自身的缓存是怎么撑过来的。看博客园云路的文章就知道博客园用的是memcached缓存的。
我的理解是，作为缓存当用户量小的时候可以用web自身的缓存机制，当达到一定数量级后，自身缓存机制无法满足大量数据缓存的需求的时候就需要切换到分布式的缓存组件上去。而遵循的原则就是，让数据更加的靠近用户。现在很多互联网服务，使用memcached或者类是的key-value数据库将所有的数据都放到缓存里面，而mysql等结构化的数据库只是用来作为数据库的备份，当缓存失效等才会从数据库里面读取数据。
系统协议的选择
微软是一个很喜欢将一些协议里面加入自己的东西，并且也只有自己的那一套解决方案可以用，对于选择全套微软的产品来说确实是很方便，但是当我们需要用到非微软的东西的时候就拙计了。在web服务上主要是有webservice或者wcf的http服务。webservice是一套公开的标准，xml格式的一套协议。
Web Service是一项新技术， 能使得运行在不同机器上的不同应用无须借助附加的、专门的第三方软件或硬件， 就可相互交换数据或集成。依据Web Service规范实施的应用之间， 无论它们所使用的语言、 平台或内部协议是什么， 都可以相互交换数据。Web Service是自描述、 自包含的可用网络模块， 可以执行具体的业务功能。Web Service也很容易部署， 因为它们基于一些常规的产业标准以及已有的一些技术，诸如XML和HTTP。Web Service减少了应用接口的花费。Web Service为整个企业甚至多个组织之间的业务流程的集成提供了一个通用机制。
在web传输中json是比xml格式更加简短，并且能够被js原生支持的格式，而且第三方的支持也不少，选择json作为载体要比xml好。而Restful 对我而言更向是一种数据访问风格。让url请求更加清晰。而不是协议。所以在web系统中，做api我更加的倾向用Restful风格的api和json作为载体。如果全套都是微软的产品，我认为wcf微软出品还是最好的选择。
文件系统的选择
文件服务器放到linux下是比weindows好的，最起码linux不用去处理各种文件碎片，好吧文件服务我也没有玩过，不好评说。
静态资源请求是IIS还是单独出来
我们知道iis是只能够处理静态文件的如果访问动态比如.aspx文件，iis会交给aspnet_isapi来处理请求，然后将结果返回给iis。作为静态文件的处理，Nginx比iis是有优势的。静态文件处理的时候，我们通常会做的事情就是将js、css文件进行合并压缩，开个一个或多个单独的二级域名来作为图片服务器。减少前端的等待过程。或者是将图片服务交给又拍、七牛等来处理。前段时间研究过又拍一下，提供REST和表单Api的接口，可以很方便的集成过去。而且提供CDN加速，比自己搞静态文件服务器要便宜。
均衡负载。。。
当web服务器不够用的时候，这个时候需要对web服务器部署均衡负载，当然部署均衡负载的方法很多。俺也没有部署过这玩意，不好说，当单台web服务器无法支持业务需求的时候，均衡负载是必须滴。
总结
所以上面6点中除了第二点，我认为是作者对系统理解的不够外，其他的都是支持的。系统出现了问题，重来都不是语言的问题，而是架构的问题。当然这只是个人想法，也许我所认知的都是错了。