蚂蚁变大象:浅谈常规网站是如何从小变大的(七)(转)

原文:http://blog.sina.com.cn/s/blog_6203dcd60100xyad.html

        

【阶段性小结】

 

经过了上述的架构扩展和优化以后,我们的系统无论是从前端接入,还是后端存储都较最初的阶段有了质的变化。这样的架构足以支撑起10亿级别的流量和10亿级别的数据量。我们具体的来看一下整体的架构。

上述的模型是我个人觉得的一个比较理想的模型。Virtual Server
Cluster接收数据包,转发给Web Server Cluster或者Private Protocol Server Cluster(如果有的话)。然后视图和逻辑层server负责调用cache或者数据访问组织层的接口,返回处理后的数据。定制存储系统、通用存储系统和数据库集群,提供基本的数据。

每一个层次通过负载均衡和一定的协议来获取下一层提供的数据,或者提交数据。在存储系统内部,通过Meta信息管理、主从同步、消息订阅等方式,实现数据的同步。

如果我们再要扩大规模,比如:机器数扩展到上千台、万台。对于我们来说,管理机器就成为了机器头等的大问题。

同时,我们之前还有几个问题没有很详尽的描述,比如:数据传输协议、远程系统调用、系统的异构性等等,这些都是会影响到我们系统可维护性的大问题。

我7年前就开始使用Java,到现在,总算能看懂一些东西了。J2EE我个人觉得确实是一个比较伟大的东东。里面其实早已经提出了一套比较完善的解决大型或者超大型网站的整体解决方案。

比如:

1、JNDI(Java Naming and Directory Interface):描述了如何使用命名和目录等的规范,使得我们能够将服务作为资源挂接到命名服务器上,并且通过标准的接口进行访问。这对我们管理巨大的机器资源和服务提供了很好的方案。

2、RMI(Remote Method Invoke):远程过程调用。即,通过标准的RMI接口,可以轻松实现跨系统的远程调用。

3、IDL(Interface Definition Language):接口定义语言。这个本来是CORBA中用来访问异构系统对象的统一语言,其实也给我们提供了跨系统调用中,对外接口的定义方案。

4、JDBC(Java Database Connectivity):数据库访问接口。屏蔽了不同数据库访问的实现细节,使得数据库开发变得轻松。

5、JSP(Java Server Page):实现将视图和控制层很好分离的方式。

6、JMS(Java Message Service):用于和面向消息的中间件相互通信的应用程序接口。提供了很好的消息推送和订阅的机制。

以上这些组件其实很好的协助构建了J2EE整体架构。我的很多想法都来源于这些东东。后续会结合这些,详细来分析诸如资源命名位置服务、数据传输协议、异构系统接口定义等解决大规模机器运维问题的方案。

蚂蚁变大象:浅谈常规网站是如何从小变大的(七)(转),码迷,mamicode.com

时间: 2024-12-28 18:23:18

蚂蚁变大象:浅谈常规网站是如何从小变大的(七)(转)的相关文章

蚂蚁变大象:浅谈常规网站是如何从小变大的(五)(转)

原文:http://blog.sina.com.cn/s/blog_6203dcd60100xurh.html          [第九阶段 : 逻辑关联和层次划分]   在第七阶段的时候,我们提到了几个问题,其中有一个就是业务关联问题.当我们将业务拆分以后,多个业务之间没有了耦合(或者是极弱的耦合),能够独立的运转.这个看起来是多么美妙的事情.但是实际情况真是如此嘛? 这样的业务还真是存在的.比如我们有两个业务blog和image.blog可以上传和展示图片.那image.XXX.com就提供

蚂蚁变大象:浅谈常规网站是如何从小变大的(八)(转)

原文:http://blog.sina.com.cn/s/blog_6203dcd60100y1vi.html          [第十一阶段 :命名位置服务]   在前面我们不止一次提到了命名位置服务(Naming & Location Service).在不同的架构或者公司里面,这个名字往往不一样,比如,在java里面叫JNDI(Java Naming & Directory Interface),在有些地方可能会叫做资源位置系统(Resource Location System).

蚂蚁变大象:浅谈常规网站是如何从小变大的(二)(转)

原文:http://blog.sina.com.cn/s/blog_6203dcd60100xokd.html          [第四阶段 : 第一次服务多机化] 当IO性能得到解决以后,我们可能就会面临CPU瓶颈,即程序处理不过来了.那这个时候,最好的方式,就是优化程序.从整体架构和具体业务逻辑上去分析并做优化(可以借助一些性能分析工具,如gprof,xprof等).根据之前的经验,反射.正则表达式.字符串拼接.内存拷贝等是吃CPU的大户,所以优化上可以重点考虑.通过性能优化,一般可以将性能

蚂蚁变大象:浅谈常规网站是如何从小变大的(六)(转)

原文:http://blog.sina.com.cn/s/blog_6203dcd60100xvky.html          [第十阶段 : 数据存储优化]   在前面的阶段中,我们都使用数据库作为默认的存储引擎,很少谈论关于关于数据存储的话题.但是,数据的存储却是我们现在众多大型网站面临的最核心的问题.现在众多网络巨头纷纷推出自己的"高端"存储引擎,也吸引了众多的眼球.比如:google的BigTable.facebook的cassandra.以及开源的Hadoop等等.国内众多

蚂蚁变大象:浅谈常规网站是如何从小变大的(一)(转)

add by zhj:非常完整的介绍了一个网站从小到大,后台的设计及服务器的部署的演进过程,太牛了. 原文:http://blog.sina.com.cn/zgwangbo001 话说今天是清明节假期第一天,早上早早的和朋友开车逃离了帝都.现在正在G104上缓慢的爬行. 言归正传,计划了很久写这篇文章,不过心里还是比较忐忑,担心自己在技术上的深度和沉淀还是不够.不过,最后想起某老师说的:follow my heart! 想想,人生就这么些年,想做啥就做啥吧,不用想的太多. ―――――――――――

蚂蚁变大象:浅谈常规网站是如何从小变大的(十)(转)

原文:http://blog.sina.com.cn/s/blog_6203dcd60100y9r7.html          [第十三阶段 :分布式计算和存储的运维设计与考虑]   以上的部分已经从前到后的将系统架构进行了描述,同时针对我们会遇到的问题进行了分析和处理,提出了一些解决方案,以保证我们的系统在不断增长的压力之下,如何的良好运转. 不过,我们很少描述运维相关的工作,以及设计如何和运维相关联.系统运维的成败,直接决定了系统设计的成败.所以系统的运维问题,是设计中必须考虑的问题.特别

蚂蚁变大象:浅谈常规网站是如何从小变大的(九)(转)

原文:http://blog.sina.com.cn/s/blog_6203dcd60100y2gd.html          [第十二阶段 :传输协议.接口.远程调用]   这一部分主要谈谈关于协议.接口和远程调用相关的内容.本来这一部分应该在之前就有比较详细的讨论,不过我放到后面来,足见其重要性.特别是在系统越来越多的时候,这几个东东直接决定了我们的开发速度和运维成本. 好,接下来我们一个个的看. 1.传输协议 到目前为止,在不同系统之间获取数据的时候,你是采用那种方式呢? 我们简单看一个

蚂蚁变大象:浅谈常规网站是如何从小变大的(三)(转)

原文:http://blog.sina.com.cn/s/blog_6203dcd60100xon9.html          [第七阶段 : 拆分] 到上面一个阶段,我们初步接触到了逻辑.存储等的多机模式.这样的结构,对于逻辑不是特别复杂的网站,足以撑起千万级的压力.所以大多数网站,只要能够用好上面的结构就可以很好的应对服务压力了.只不过还有很多细节的工作需要精细化,比如:多机的运维.稳定性的监控.日志的管理.请求的分析与挖掘等. 如果流量持续增长,或者是业务持续的扩展,上述的架构可能又将面

蚂蚁变大象:浅谈常规网站是如何从小变大的(四)(转)

原文:http://blog.sina.com.cn/s/blog_6203dcd60100xthv.html          [第八阶段 : WebServer多机化]   上面说了这么多,我们的业务都基本上运转在只有一个WebServer的条件下.如果出现宕机,所有服务就停掉了:如果压力大了,单机不能承载了,怎么办? 说到这个话题,我们需要来回顾一下在大学时学习的关于网络的基本知识.^_^ 抛开复杂的网络,我们简化我们的模型.我们的电脑通过光纤直接连入互联网.当我们在浏览器地址栏里面输入h