最近回顧SAAS的書籍，書中的擴展架構都有點讓我痴迷，但書中介紹的都是以Java，Apache，JBoss，Hadloop等技術實現負載均衡，大數據處理，對於微軟架構並未提及，所以讓我陷入無限遐想，夜不能眠啊。今天的文章純屬瞎想，有錯的不要批評，大家一起討論就可以了。
對於大數據處理來說，要解決的問題：
1、web服務器的負載均衡
2、web服務器的水平擴展
3、數據庫的分庫處理
4、數據庫讀寫分離
5、數據庫的水平擴展
大概的架構： 
（沒什么工具，用word畫的，丑了點，哈）
在大數據，大流量的情況下，web服務器的水平擴展及數據庫的水平擴展尤為重要，水平擴展的好處就是省錢，服務器越多說明你流量也越多，平均的性價比也最划算。
WINDOWS服務器可以使用NLB來實現均衡負載，但查下來最大只支持32台服務器！（這我不是很理解，為什么有數量限制呢，那超過32台怎么辦？）
在水平擴展中，我們需要實現如下問題：
1、環境的搭建
2、網站文件的同步
環境的搭建比較簡單，在相同配置的服務器來說，我們只要先配置好一台服務器，進行ghost后，每增加一台服務器，就恢復一下就可以了。
文件的同步，目前有好幾種解決方案：
1、主服務器目錄 推送 到 各個子服務器，同步文件，各個子服務器需開通必要的端口，讓主服務器與其通信。
2、子服務器每隔一段時間進行拉操作。這樣只要主服務器開通必要的端口，子服務器每隔一段時間來進行請求。
對於此類系統來說，關鍵我們需要知道哪些文件新增、更改、重命名、刪除，最好用一個Sqlite來記錄下網站目錄的子目錄、文件的對應關系，比對盡量使用文件的md5。記錄更新記錄，可以讓我們在同步的時候同步需要的文件，而不是整個網站目錄，最好還有個版本號和同步開關，可以更好的讓我們先進行測試，再進行同步。
數據庫是大數據情況下最頭大的事情，數據量的增加，連接數不夠用，日志文件的激增，都是MSSQL會遇到的問題。
在大多數網站，都是讀多寫少，采用讀寫分離是個好方案，但需要注意的是數據庫的同步，MSSQL有復制的功能，但總感覺不夠好，小弟不才，也不太清楚有沒有更好的方案。
解決了MSSQL的同步問題，基本上就能實現數據庫的水平擴展了，也要注意好Log文件，這家伙膨脹起來不得了啊。
其次就是分庫問題，分庫能夠很好的解決數據庫堆積的問題，可以利用某些字段進行分庫判斷，一般的網站都會以用戶ID進行分庫，比如userid<= 10000進Master 1，10000<userid<=20000進Master 2等，但分庫處理，需要在應用層有一個很強的業務邏輯進行判斷，也可以多加一層專門的處理分庫的。
以上都是針對微軟架構，現在很多大型網站都用的非微軟架構，用微軟架構的不多，原先京東、大眾點評都使用的微軟架構，但在隨后數據量激增的情況下，都轉到java apache旗下，現留的估計已經不多。之前在5173用的微軟架構，現在5173的技術部門很強大了，不知道是否還延續着。
作為程序員，我們也可以轉到其他語言，架構，但習慣了微軟開發，一下子換到其他架構還真有點不太習慣，開源項目多是個好事，能讓我們減少很多事情，但太多也未必是好事，會得選擇糾結症的。前幾年我都會在糾結到底JAVA好還是Net好，因為Java工資高，Net工資低（普遍現象哦），現在不糾結了，語言只是工具，即使老板要求用Java開發，我們也會拿起Eclipse來進行開發，只是進度快慢問題而已。
作為十年的程序員，一路風風雨雨，別問我工資多少，那永遠是個痛。現在的我，想接觸下微軟架構下的大數據，有大拿覺得鄙人還行的，可以跟我聯系下，不過鄙人家庭穩定，有兒一枚，所以希望是上海的企業。
起起伏伏,跌跌盪盪,謹以此文紀念我的十年IT路