对于大数据大流量情况下微软架构的水平扩展的遐想（瞎想）

最近回顾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路