【對.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點中除了第二點，我認為是作者對系統理解的不夠外，其他的都是支持的。系統出現了問題，重來都不是語言的問題，而是架構的問題。當然這只是個人想法，也許我所認知的都是錯了。