濟南軟件開發(fā)之對.NET系統(tǒng)架構改造的經(jīng)驗和教訓
1、數(shù)據(jù)層放棄SQL Server數(shù)據(jù)庫和存儲過程，全部遷移到Linux平臺上的MySQL數(shù)據(jù)庫上；
2、緩存不再依賴.net自身提供的緩存機制，遷移到部署在Linux平臺上的分布式的Redis上；
3、服務之間的調用，避免使用.net自身專有協(xié)議，改成Restful的HTTP Web API調用；
4、靜態(tài)資源請求，不再讓IIS自己處理，分離到Linux平臺上的nginx去處理；
5、需要讀取的文件系統(tǒng)，也改成訪問Linux平臺上的分布式文件系統(tǒng)；
6、部署.net代碼的Windows服務器放在LVS后面，用LVS做負載均衡和故障切換；
簡單說來，就是單純讓.net做應用層的編程語言和框架，其他都交給Linux平臺的開源解決方案。而.net框架單純做應用層，無論ASP.net MVC的開發(fā)效率，還是.net CLR虛擬機的運行效率都非常好，目前我們單臺Windows服務器上跑幾百萬的動態(tài)請求毫無壓力，而且應用層架構是可以橫向擴展的：如果請求負載非常高，只需要添加更多Windows服務器即可�？傊龅搅藫P長避短。
我們濟南軟件開發(fā)還有熟悉大型互聯(lián)網(wǎng)技術架構的人應該很容易的發(fā)現(xiàn)，這個重構過程其實就是一個“讓合適的東西干合適的事情”這樣一項工作：
1、把過多業(yè)務邏輯寫到存儲過程中必然導致數(shù)據(jù)庫服務器壓力的增大，而且不利于負載均衡，因此去“存儲過程”是必要的；
2、SQLServer實現(xiàn)集群的能力很差，用MYSQL之類的數(shù)據(jù)庫是一個不錯的選擇；
3、緩存還是用.Net內置的InProc緩存機制對于高并發(fā)的網(wǎng)站來講是一個災難，用Redis之類分布式緩存來代替是必然的過程；
4、使用.Net Remoting之類的私有協(xié)議不利于異構系統(tǒng)集成，改成webservice、REST也是必須的；
5、靜態(tài)文件的請求也經(jīng)過IIS有點太勞煩IIS了，扔給nginx才更合適；
6、Windows服務器的文件系統(tǒng)很不靈活，換成更加靈活的Linux下的分布式文件系統(tǒng)是聰明的；
7、采用LVS、nginx之類做負載均衡也是最合適的。
其實任何一個大型互聯(lián)網(wǎng)基本都是這樣一個架構：前端使用nginx等做負載均衡，使用Redis、memcached等做分布式緩存，使用數(shù)據(jù)庫集群進行讀寫分離之類的優(yōu)化，使用分布式文件系統(tǒng)處理圖片等靜態(tài)文件。 請問，使用PHP、Java等做web服務器開發(fā)的大型互聯(lián)網(wǎng)，哪個使用JSP內置的Session對象做Session的，不都要換用redis嗎?哪個把圖片和php放到一個服務器的，不都放到文件服務器中嗎?哪個一個apache服務器就可以扛起來的，不都是nginx之類的擋在前面做負載均衡的嗎? 怎么不說“去php化”、“去java化”呢?要知道redis、memcached、ngix之類的可都不是java、php寫的呀，一個java項目竟然用其他語言寫的東西，難道不丟面子?
我們濟南軟件開發(fā)認為，其實一個大型的系統(tǒng)中，根據(jù)項目的不同特點來組合搭配不同的產品、組件是一個必然的過程，去了解一下這些系統(tǒng)中“混搭”是常見的現(xiàn)象。單一產品中提供能的功能只能滿足普通項目的需求，要想滿足復雜的項目，必須把這些產品中提供的一些傻瓜化的簡單組件用更專業(yè)的組件來替換，就像做小項目php中的Session足夠了，但是大項目必須用c/c++開發(fā)的memcached來替換。
