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

最近回顾SAAS的书籍,书中的扩展架构都有点让我痴迷,但书中介绍的都是以Java,Apache,JBoss,Hadloop等技术实现负载均衡,大数据处理,对于微软架构并未提及,所以让我陷入无限遐想,夜不能眠啊。今天的文章纯属瞎想,有错的不要批评,大家一起讨论就可以了。

对于大数据处理来说,要解决的问题:
1、web服务器的负载均衡
2、web服务器的水平扩展
3、数据库的分库处理
4、数据库读写分离
5、数据库的水平扩展

大概的架构:
image (没什么工具,用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路

邮箱:james@taogame.com
QQ:785418
微信:jamesying1
QQ群:376248054 通关:cnblogs
技术改变生活,技术改变人生!用技术来创造价值,拥有技术,不仅仅是开发,您将获得更多!如果您觉得我能帮到您,您可以通过扫描下面二维码来【捐助】我!
posted @ 2014-02-21 11:43  James.Ying  阅读(4216)  评论(12编辑  收藏  举报