- 浏览: 208931 次
- 性别:
- 来自: 广州
文章分类
最新评论
-
brenda:
...
技术选型(转) -
JavaScriptOMG:
写的真好,不知道如果是java.sql.date的话,怎么写呢 ...
Java得到下一天明天,明天时间 -
少女杀手:
和他的一摸一样,一个字都不差
http://anysky131 ...
弹出窗口代码大全 -
shipping:
字体好小啊,都没兴趣看下去了
测试网站性能的30款免费在线工具 -
ddd:
其实一切人活着的意义就在于他死前的心情是什么。
活着是多么美好
间过得很快,来新公司已经两个月了,在这两个月的时间里,自己也感受颇深。下面就说说自己的一些理解。
一 应用无状态
俗话说,一个系统的伸缩性的好坏取决于应用的状态如何管理。为什么这么说呢?咱们试想一下,假如我们在session中保存了大量与客户端的状态信息的话,那么当保存状态信息的server宕机的时候,我们怎么办?通常来说,我们都是通过集群来解决这个问题,而通常所说的集群,不仅有负载均衡,更重要的是要有失效恢复failover,比如tomcat采用的集群节点广播复制,jboss采用的配对复制等session状态复制策略,但是集群中的状态恢复也有其缺点,那就是严重影响了系统的伸缩性,系统不能通过增加更多的机器来达到良好的水平伸缩,因为集群节点间session的通信会随着节点的增多而开销增大,因此要想做到应用本身的伸缩性,我们需要保证应用的无状态性,这样集群中的各个节点来说都是相同的,从而是的系统更好的水平伸缩。
OK,上面说了无状态的重要性,那么具体如何实现无状态呢?此时一个session框架就会发挥作用了。一般通过cookie来实现,或者也可以采用集中式session管理来完成,说具体点就是多个无状态的应用节点连接一个session 服务器,session服务器将session保存到缓存中,session服务器后端再配有底层持久性数据源,比如数据库,文件系统等等。
二 有效使用缓存
做互联网应用的兄弟应该都清楚,缓存对于一个互联网应用是多么的重要,从浏览器缓存,反向代理缓存,页面缓存,局部页面缓存,对象缓存等等都是缓存应用的场景。
一般来说缓存根据与应用程序的远近程度不同可以分为:local cache 和 remote cache。一般系统中要么采用local cache,要么采用remote cache,两者混合使用的话对于local cache和remote cache的数据一致性处理会变大比较麻烦.
在大部分情况下,我们所说到的缓存都是读缓存,缓存还有另外一个类型:写缓存. 对于一些读写比不高,同时对数据安全性需求不高的数据,我们可以将其缓存起来从而减少对底层数据库的访问,比如统计商品的访问次数,统计API的调用量等等,可以采用先写内存缓存然后延迟持久化到数据库,这样可以大大减少对数据库的写压力。
三 应用拆分
首先,在说明应用拆分之前,我们先来回顾一下一个系统从小变大的过程中遇到的一些问题,通过这些问题我们会发现拆分对于构建一个大型系统是如何的重要。
系统刚上线初期,用户数并不多,所有的逻辑也许都是放在一个系统中的,所有逻辑跑到一个进程或者一个应用当中,这个时候因为比较用户少,系统访问量低,因此将全部的逻辑都放在一个应用未尝不可。但是,兄弟们都清楚,好景不长,随着系统用户的不断增加,系统的访问压力越来越多,同时随着系统发展,为了满足用户的需求,原有的系统需要增加新的功能进来,系统变得越来越复杂的时候,我们会发现系统变得越来越难维护,难扩展,同时系统伸缩性和可用性也会受到影响。那么这个时候我们如何解决这些问题呢?明智的办法就是拆分(这也算是一种解耦),我们需要将原来的系统根据一定的标准,比如业务相关性等分为不同的子系统,不同的系统负责不同的功能,这样切分以后,我们可以对单独的子系统进行扩展和维护,从而提高系统的扩展性和可维护性,同时我们系统的水平伸缩性scale out大大的提升了,因为我们可以有针对性的对压力大的子系统进行水平扩展而不会影响到其它的子系统,而不会像拆分以前,每次系统压力变大的时候,我们都需要对整个大系统进行伸缩,而这样的成本是比较大的,另外经过切分,子系统与子系统之间的耦合减低了,当某个子系统暂时不可用的时候,整体系统还是可用的,从而整体系统的可用性也大大增强了。
因此一个大型的互联网应用,肯定是要经过拆分,因为只有拆分了,系统的扩展性,维护性,伸缩性,可用性才会变的更好。但是拆分也给系统带来了问题,就是子系统之间如何通信的问题,而具体的通信方式有哪些呢?一般有同步通信和异步通信,这里我们首先来说下同步通信,下面的主题“消息系统”会说到异步通信。既然需要通信,这个时候一个高性能的远程调用框架就显得非常总要啦.
上面所说的都是拆分的好处,但是拆分以后必然的也会带来新的问题,除了刚才说的子系统通信问题外,最值得关注的问题就是系统之间的依赖关系,因为系统多了,系统的依赖关系就会变得复杂,此时就需要更好的去关注拆分标准,比如能否将一些有依赖的系统进行垂直化,使得这些系统的功能尽量的垂直,这也是目前公司正在做的系统垂直化,同时一定要注意系统之间的循环依赖,如果出现循环依赖一定要小心,因为这可能导致系统连锁启动失败。
从上面可以看出,一个大型系统要想变得可维护,可扩展,可伸缩,我们必须的对它进行拆分,拆分必然也带来系统之间如何通信以及系统之间依赖管理等问题。
四 数据库拆分
在前面“应用拆分”主题中,我们提到了一个大型互联网应用需要进行良好的拆分,而那里我们仅仅说了”应用级别”的拆分,其实我们的互联网应用除了应用级别的拆分以外,还有另外一个很重要的层面就是存储如何拆分的。因此这个主题主要涉及到如何对存储系统,通常就是所说的RDBMS进行拆分。
好了,确定了这个小节的主题之后,我们回顾一下,一个互联网应用从小变大的过程中遇到的一些问题,通过遇到的问题来引出我们拆分RDBMS的重要性。
系统刚开始的时候,因为系统刚上线,用户不多,那个时候,所有的数据都放在了同一个数据库中,这个时候因为用户少压力小,一个数据库完全可以应付的了,但是随着运营那些哥们辛苦的呐喊和拼命的推广以后,突然有一天发现,oh,god,用户数量突然变多了起来,随之而来的就是数据库这哥们受不了,它终于在某一天大家都和惬意的时候挂掉啦。此时,咱们搞技术的哥们,就去看看究竟是啥原因,我们查了查以后,发现原来是数据库读取压力太大了,此时咱们都清楚是到了读写分离的时候,这个时候我们会配置一个server为master节点,然后配几个salve节点,这样以来通过读写分离,使得读取数据的压力分摊到了不同的salve节点上面,系统终于又恢复了正常,开始正常运行了。但是好景还是不长,有一天我们发现master这哥们撑不住了,它负载老高了,汗流浃背,随时都有翘掉的风险,这个时候就需要咱们垂直分区啦(也就是所谓的分库),比如将商品信息,用户信息,交易信息分别存储到不同的数据库中,同时还可以针对商品信息的库采用master,salve模式,OK,通过分库以后,各个按照功能拆分的数据库写压力被分担到了不同的server上面,这样数据库的压力终于有恢复到正常状态。但是是不是这样,我们就可以高枕无忧了呢?NO,这个NO,不是我说的,是前辈们通过经验总结出来的,随着用户量的不断增加,你会发现系统中的某些表会变的异常庞大,比如好友关系表,店铺的参数配置表等,这个时候无论是写入还是读取这些表的数据,对数据库来说都是一个很耗费精力的事情,因此此时就需要我们进行“水平分区”了(这就是俗话说的分表,或者说sharding).
OK,上面说了一大堆,无非就是告诉大家一个事实“数据库是系统中最不容易scale out的一层”,一个大型的互联网应用必然会经过一个从单一DB server,到Master/salve,再到垂直分区(分库),然后再到水平分区(分表,sharding)的过程,而在这个过程中,Master/salve 以及垂直分区相对比较容易,对应用的影响也不是很大,但是分表会引起一些棘手的问题,比如不能跨越多个分区join查询数据,如何平衡各个shards的负载等等,这个时候就需要一个通用的DAL框架来屏蔽底层数据存储对应用逻辑的影响,使得底层数据的访问对应用透明化。
五 异步通信
在”远程调用框架”的介绍中,我们说了一个大型的系统为了扩展性和伸缩性方面的需求,肯定是要进行拆分,但是拆分了以后,子系统之间如何通信就成了我们首要的问题,在”远程调用框架”小节中,我们说了同步通信在一个大型分布式系统中的应用,那么这一小节我们就来说说异步通信.好了,既然说到了异步通信,那么”消息中间件”就要登场了,采用异步通信这其实也是关系到系统的伸缩性,以及最大化的对各个子系统进行解耦.
说到异步通信,我们需要关注的一点是这里的异步一定是根据业务特点来的,一定是针对业务的异步,通常适合异步的场合是一些松耦合的通信场合,而对于本身业务上关联度比较大的业务系统之间,我们还是要采用同步通信比较靠谱。
OK,那么下一步我们说说异步能给系统带来什么样子的好处。首先我们想想,假如系统有A和B两个子系统构成,假如A和B是同步通信的话,那么要想使得系统整体伸缩性提高必须同时对A和B进行伸缩,这就影响了对整个系统进行scale out.其次,同步调用还会影响到可用性,从数学推理的角度来说,A同步调用B,如果A可用,那么B可用,逆否命题就是如果B不可用,那么A也不可用,这将大大影响到系统可用性,再次,系统之间异步通信以后可以大大提高系统的响应时间,使得每个请求的响应时间变短,从而提高用户体验,因此异步在提高了系统的伸缩性以及可用性的同时,也大大的增强了请求的响应时间(当然了,请求的总体处理时间也许不会变少)。
最后,关于异步方面的讨论,我可以推荐大家一些资源:
1 . J2EE meets web2.0
2. Ebay架构特点(HPTS 2009)
六 非结构化数据存储
在一个大型的互联网应用当中,我们会发现并不是所有的数据都是结构化的,比如一些配置文件,一个用户对应的动态,以及一次交易的快照等信息,这些信息一般不适合保存到RDBMS中,它们更符合一种Key-value的结构,另外还有一类数据,数据量非常的大,但是实时性要求不高,此时这些数据也需要通过另外的一种存储方式进行存储,另外一些静态文件,比如各个商品的图片,商品描述等信息,这些信息因为比较大,放入RDBMS会引起读取性能问题,从而影响到其它的数据读取性能,因此这些信息也需要和其它信息分开存储,而一般的互联网应用系统都会选择把这些信息保存到分布式文件系统中。
随着互联网的发展,业界从08年下半年开始逐渐流行了一个概念就是NOSQL。我们都知道根据CAP理论,一致性,可用性和分区容错性3者不能同时满足,最多只能同时满足两个,我们传统的关系数据采用了ACID的事务策略,而ACID的事务策略更加讲究的是一种高一致性而降低了可用性的需求,但是互联网应用往往对可用性的要求要略高于一致性的需求,这个时候我们就需要避免采用数据的ACID事务策略,转而采用BASE事务策略,BASE事务策略是基本可用性,事务软状态以及最终一致性的缩写,通过BASE事务策略,我们可以通过最终一致性来提升系统的可用性,这也是目前很多NOSQL产品所采用的策略,包括facebook 的cassandra,apache hbase,google bigtable等,这些产品非常适合一些非结构化的数据,比如key-value形式的数据存储,并且这些产品有个很好的优点就是水平伸缩性。目前公司也在研究和使用一些成熟的NOSQL产品。
七 监控、预警系统
对于大型的系统来说,唯一可靠的就是系统的各个部分是不可靠。
因为一个大型的分布式系统中势必会涉及到各种各样的设备,比如网络交换机,普通PC机,各种型号的网卡,硬盘,内存等等,而这些东东都在数量非常多的时候,出现错误的概率也会变大,因此我们需要时时刻刻监控系统的状态,而监控也有粒度的粗细之分,粒度粗一点的话,我们需要对整个应用系统进行监控,比如目前的系统网络流量是多少,内存利用率是多少,IO,CPU的负载是多少,服务的访问压力是多少,服务的响应时间是多少等这一系列的监控,而细粒度一点的话,我们就需对比如应用中的某个功能,某个URL的访问量是多,每个页面的PV是多少,页面每天占用的带宽是多少,页面渲染时间是多少,静态资源比如图片每天占用的带宽是多少等等进行进一步细粒度的监控。因此一个监控系统就变得必不可少了。
前面说了一个监控系统的重要性,有了监控系统以后,更重要的是要和预警系统结合起来,比如当某个页面访问量增多的时候,系统能自动预警,某台Server的CPU和内存占用率突然变大的时候,系统也能自动预警,当并发请求丢失严重的时候,系统也能自动预警等等,这样以来通过监控系统和预警系统的结合可以使得我们能快速响应系统出现的问题,提高系统的稳定性和可用性。
八 配置统一管理
一个大型的分布式应用,一般都是有很多节点构成的,如果每次一个新的节点加入都要更改其它节点的配置,或者每次删除一个节点也要更改配置的话,这样不仅不利于系统的维护和管理,同时也更加容易引入错误。另外很多时候集群中的很多系统的配置都是一样的,如果不进行统一的配置管理,就需要再所有的系统上维护一份配置,这样会造成配置的管理维护很麻烦,而通过一个统一的配置管理可以使得这些问题得到很好的解决,当有新的节点加入或者删除的时候,配置管理系统可以通知各个节点更新配置,从而达到所有节点的配置一致性,这样既方便也不会出错。
原文地址:http://yuquan-nana.iteye.com/blog/710302
一 应用无状态
俗话说,一个系统的伸缩性的好坏取决于应用的状态如何管理。为什么这么说呢?咱们试想一下,假如我们在session中保存了大量与客户端的状态信息的话,那么当保存状态信息的server宕机的时候,我们怎么办?通常来说,我们都是通过集群来解决这个问题,而通常所说的集群,不仅有负载均衡,更重要的是要有失效恢复failover,比如tomcat采用的集群节点广播复制,jboss采用的配对复制等session状态复制策略,但是集群中的状态恢复也有其缺点,那就是严重影响了系统的伸缩性,系统不能通过增加更多的机器来达到良好的水平伸缩,因为集群节点间session的通信会随着节点的增多而开销增大,因此要想做到应用本身的伸缩性,我们需要保证应用的无状态性,这样集群中的各个节点来说都是相同的,从而是的系统更好的水平伸缩。
OK,上面说了无状态的重要性,那么具体如何实现无状态呢?此时一个session框架就会发挥作用了。一般通过cookie来实现,或者也可以采用集中式session管理来完成,说具体点就是多个无状态的应用节点连接一个session 服务器,session服务器将session保存到缓存中,session服务器后端再配有底层持久性数据源,比如数据库,文件系统等等。
二 有效使用缓存
做互联网应用的兄弟应该都清楚,缓存对于一个互联网应用是多么的重要,从浏览器缓存,反向代理缓存,页面缓存,局部页面缓存,对象缓存等等都是缓存应用的场景。
一般来说缓存根据与应用程序的远近程度不同可以分为:local cache 和 remote cache。一般系统中要么采用local cache,要么采用remote cache,两者混合使用的话对于local cache和remote cache的数据一致性处理会变大比较麻烦.
在大部分情况下,我们所说到的缓存都是读缓存,缓存还有另外一个类型:写缓存. 对于一些读写比不高,同时对数据安全性需求不高的数据,我们可以将其缓存起来从而减少对底层数据库的访问,比如统计商品的访问次数,统计API的调用量等等,可以采用先写内存缓存然后延迟持久化到数据库,这样可以大大减少对数据库的写压力。
三 应用拆分
首先,在说明应用拆分之前,我们先来回顾一下一个系统从小变大的过程中遇到的一些问题,通过这些问题我们会发现拆分对于构建一个大型系统是如何的重要。
系统刚上线初期,用户数并不多,所有的逻辑也许都是放在一个系统中的,所有逻辑跑到一个进程或者一个应用当中,这个时候因为比较用户少,系统访问量低,因此将全部的逻辑都放在一个应用未尝不可。但是,兄弟们都清楚,好景不长,随着系统用户的不断增加,系统的访问压力越来越多,同时随着系统发展,为了满足用户的需求,原有的系统需要增加新的功能进来,系统变得越来越复杂的时候,我们会发现系统变得越来越难维护,难扩展,同时系统伸缩性和可用性也会受到影响。那么这个时候我们如何解决这些问题呢?明智的办法就是拆分(这也算是一种解耦),我们需要将原来的系统根据一定的标准,比如业务相关性等分为不同的子系统,不同的系统负责不同的功能,这样切分以后,我们可以对单独的子系统进行扩展和维护,从而提高系统的扩展性和可维护性,同时我们系统的水平伸缩性scale out大大的提升了,因为我们可以有针对性的对压力大的子系统进行水平扩展而不会影响到其它的子系统,而不会像拆分以前,每次系统压力变大的时候,我们都需要对整个大系统进行伸缩,而这样的成本是比较大的,另外经过切分,子系统与子系统之间的耦合减低了,当某个子系统暂时不可用的时候,整体系统还是可用的,从而整体系统的可用性也大大增强了。
因此一个大型的互联网应用,肯定是要经过拆分,因为只有拆分了,系统的扩展性,维护性,伸缩性,可用性才会变的更好。但是拆分也给系统带来了问题,就是子系统之间如何通信的问题,而具体的通信方式有哪些呢?一般有同步通信和异步通信,这里我们首先来说下同步通信,下面的主题“消息系统”会说到异步通信。既然需要通信,这个时候一个高性能的远程调用框架就显得非常总要啦.
上面所说的都是拆分的好处,但是拆分以后必然的也会带来新的问题,除了刚才说的子系统通信问题外,最值得关注的问题就是系统之间的依赖关系,因为系统多了,系统的依赖关系就会变得复杂,此时就需要更好的去关注拆分标准,比如能否将一些有依赖的系统进行垂直化,使得这些系统的功能尽量的垂直,这也是目前公司正在做的系统垂直化,同时一定要注意系统之间的循环依赖,如果出现循环依赖一定要小心,因为这可能导致系统连锁启动失败。
从上面可以看出,一个大型系统要想变得可维护,可扩展,可伸缩,我们必须的对它进行拆分,拆分必然也带来系统之间如何通信以及系统之间依赖管理等问题。
四 数据库拆分
在前面“应用拆分”主题中,我们提到了一个大型互联网应用需要进行良好的拆分,而那里我们仅仅说了”应用级别”的拆分,其实我们的互联网应用除了应用级别的拆分以外,还有另外一个很重要的层面就是存储如何拆分的。因此这个主题主要涉及到如何对存储系统,通常就是所说的RDBMS进行拆分。
好了,确定了这个小节的主题之后,我们回顾一下,一个互联网应用从小变大的过程中遇到的一些问题,通过遇到的问题来引出我们拆分RDBMS的重要性。
系统刚开始的时候,因为系统刚上线,用户不多,那个时候,所有的数据都放在了同一个数据库中,这个时候因为用户少压力小,一个数据库完全可以应付的了,但是随着运营那些哥们辛苦的呐喊和拼命的推广以后,突然有一天发现,oh,god,用户数量突然变多了起来,随之而来的就是数据库这哥们受不了,它终于在某一天大家都和惬意的时候挂掉啦。此时,咱们搞技术的哥们,就去看看究竟是啥原因,我们查了查以后,发现原来是数据库读取压力太大了,此时咱们都清楚是到了读写分离的时候,这个时候我们会配置一个server为master节点,然后配几个salve节点,这样以来通过读写分离,使得读取数据的压力分摊到了不同的salve节点上面,系统终于又恢复了正常,开始正常运行了。但是好景还是不长,有一天我们发现master这哥们撑不住了,它负载老高了,汗流浃背,随时都有翘掉的风险,这个时候就需要咱们垂直分区啦(也就是所谓的分库),比如将商品信息,用户信息,交易信息分别存储到不同的数据库中,同时还可以针对商品信息的库采用master,salve模式,OK,通过分库以后,各个按照功能拆分的数据库写压力被分担到了不同的server上面,这样数据库的压力终于有恢复到正常状态。但是是不是这样,我们就可以高枕无忧了呢?NO,这个NO,不是我说的,是前辈们通过经验总结出来的,随着用户量的不断增加,你会发现系统中的某些表会变的异常庞大,比如好友关系表,店铺的参数配置表等,这个时候无论是写入还是读取这些表的数据,对数据库来说都是一个很耗费精力的事情,因此此时就需要我们进行“水平分区”了(这就是俗话说的分表,或者说sharding).
OK,上面说了一大堆,无非就是告诉大家一个事实“数据库是系统中最不容易scale out的一层”,一个大型的互联网应用必然会经过一个从单一DB server,到Master/salve,再到垂直分区(分库),然后再到水平分区(分表,sharding)的过程,而在这个过程中,Master/salve 以及垂直分区相对比较容易,对应用的影响也不是很大,但是分表会引起一些棘手的问题,比如不能跨越多个分区join查询数据,如何平衡各个shards的负载等等,这个时候就需要一个通用的DAL框架来屏蔽底层数据存储对应用逻辑的影响,使得底层数据的访问对应用透明化。
五 异步通信
在”远程调用框架”的介绍中,我们说了一个大型的系统为了扩展性和伸缩性方面的需求,肯定是要进行拆分,但是拆分了以后,子系统之间如何通信就成了我们首要的问题,在”远程调用框架”小节中,我们说了同步通信在一个大型分布式系统中的应用,那么这一小节我们就来说说异步通信.好了,既然说到了异步通信,那么”消息中间件”就要登场了,采用异步通信这其实也是关系到系统的伸缩性,以及最大化的对各个子系统进行解耦.
说到异步通信,我们需要关注的一点是这里的异步一定是根据业务特点来的,一定是针对业务的异步,通常适合异步的场合是一些松耦合的通信场合,而对于本身业务上关联度比较大的业务系统之间,我们还是要采用同步通信比较靠谱。
OK,那么下一步我们说说异步能给系统带来什么样子的好处。首先我们想想,假如系统有A和B两个子系统构成,假如A和B是同步通信的话,那么要想使得系统整体伸缩性提高必须同时对A和B进行伸缩,这就影响了对整个系统进行scale out.其次,同步调用还会影响到可用性,从数学推理的角度来说,A同步调用B,如果A可用,那么B可用,逆否命题就是如果B不可用,那么A也不可用,这将大大影响到系统可用性,再次,系统之间异步通信以后可以大大提高系统的响应时间,使得每个请求的响应时间变短,从而提高用户体验,因此异步在提高了系统的伸缩性以及可用性的同时,也大大的增强了请求的响应时间(当然了,请求的总体处理时间也许不会变少)。
最后,关于异步方面的讨论,我可以推荐大家一些资源:
1 . J2EE meets web2.0
2. Ebay架构特点(HPTS 2009)
六 非结构化数据存储
在一个大型的互联网应用当中,我们会发现并不是所有的数据都是结构化的,比如一些配置文件,一个用户对应的动态,以及一次交易的快照等信息,这些信息一般不适合保存到RDBMS中,它们更符合一种Key-value的结构,另外还有一类数据,数据量非常的大,但是实时性要求不高,此时这些数据也需要通过另外的一种存储方式进行存储,另外一些静态文件,比如各个商品的图片,商品描述等信息,这些信息因为比较大,放入RDBMS会引起读取性能问题,从而影响到其它的数据读取性能,因此这些信息也需要和其它信息分开存储,而一般的互联网应用系统都会选择把这些信息保存到分布式文件系统中。
随着互联网的发展,业界从08年下半年开始逐渐流行了一个概念就是NOSQL。我们都知道根据CAP理论,一致性,可用性和分区容错性3者不能同时满足,最多只能同时满足两个,我们传统的关系数据采用了ACID的事务策略,而ACID的事务策略更加讲究的是一种高一致性而降低了可用性的需求,但是互联网应用往往对可用性的要求要略高于一致性的需求,这个时候我们就需要避免采用数据的ACID事务策略,转而采用BASE事务策略,BASE事务策略是基本可用性,事务软状态以及最终一致性的缩写,通过BASE事务策略,我们可以通过最终一致性来提升系统的可用性,这也是目前很多NOSQL产品所采用的策略,包括facebook 的cassandra,apache hbase,google bigtable等,这些产品非常适合一些非结构化的数据,比如key-value形式的数据存储,并且这些产品有个很好的优点就是水平伸缩性。目前公司也在研究和使用一些成熟的NOSQL产品。
七 监控、预警系统
对于大型的系统来说,唯一可靠的就是系统的各个部分是不可靠。
因为一个大型的分布式系统中势必会涉及到各种各样的设备,比如网络交换机,普通PC机,各种型号的网卡,硬盘,内存等等,而这些东东都在数量非常多的时候,出现错误的概率也会变大,因此我们需要时时刻刻监控系统的状态,而监控也有粒度的粗细之分,粒度粗一点的话,我们需要对整个应用系统进行监控,比如目前的系统网络流量是多少,内存利用率是多少,IO,CPU的负载是多少,服务的访问压力是多少,服务的响应时间是多少等这一系列的监控,而细粒度一点的话,我们就需对比如应用中的某个功能,某个URL的访问量是多,每个页面的PV是多少,页面每天占用的带宽是多少,页面渲染时间是多少,静态资源比如图片每天占用的带宽是多少等等进行进一步细粒度的监控。因此一个监控系统就变得必不可少了。
前面说了一个监控系统的重要性,有了监控系统以后,更重要的是要和预警系统结合起来,比如当某个页面访问量增多的时候,系统能自动预警,某台Server的CPU和内存占用率突然变大的时候,系统也能自动预警,当并发请求丢失严重的时候,系统也能自动预警等等,这样以来通过监控系统和预警系统的结合可以使得我们能快速响应系统出现的问题,提高系统的稳定性和可用性。
八 配置统一管理
一个大型的分布式应用,一般都是有很多节点构成的,如果每次一个新的节点加入都要更改其它节点的配置,或者每次删除一个节点也要更改配置的话,这样不仅不利于系统的维护和管理,同时也更加容易引入错误。另外很多时候集群中的很多系统的配置都是一样的,如果不进行统一的配置管理,就需要再所有的系统上维护一份配置,这样会造成配置的管理维护很麻烦,而通过一个统一的配置管理可以使得这些问题得到很好的解决,当有新的节点加入或者删除的时候,配置管理系统可以通知各个节点更新配置,从而达到所有节点的配置一致性,这样既方便也不会出错。
原文地址:http://yuquan-nana.iteye.com/blog/710302
发表评论
-
技术选型(转)
2011-05-17 15:05 11722.1. 基础架构 ... -
分布式Java 应用(转)
2011-05-17 14:43 1379网络通信:协议TCP/IP,UDP/Ip,Multicas ... -
跨域访问session(转)
2011-04-22 16:14 2678大一些的网站,通常都 ... -
(转)分享一下,我常去的中文技术网站
2011-04-18 13:31 876先说一下大多数人都知 ... -
(转) request.getPathInfo() 方法的作用
2011-04-14 11:58 946request.getPathInfo(); 这个方法返回请 ... -
找到一篇性能测试的好文,简单实用,收藏之。
2011-04-10 21:59 863Java程序性能测试 1 概述 在 ... -
需要牢记的java编程规则(收藏)
2011-04-10 20:52 757(1) 类名首字母应该 ... -
一个计算机专业学生几年的编程经验汇总之二(收藏)
2011-04-10 19:48 922############################### ... -
一个计算机专业学生几年的编程经验汇总之一(收藏)
2011-04-10 18:05 917来学习Java也有两个年头了,永远不敢说多么精通,但也想谈谈自 ... -
(转)各种架构图汇总
2011-04-06 22:27 1450转载请保留出处,刘晓涛汇总!!! http://bl ... -
(转)java并发编程实践笔记
2011-04-05 22:23 8231, 保证线程安全的三种方法 : a, 不要跨线程访问共享变量 ... -
(转)百万级访问量网站的技术准备工作
2011-04-05 22:20 926当今从纯网站技术上来说,因为开源模式的发展,现在建一个小网站已 ... -
测试数据库连接状态
2011-03-25 08:45 1431while (true) { long star ... -
(转)什么是Java里的OO思想?
2011-03-24 14:12 925OO就是面向对象 面向对象(Object Oriented,O ... -
(转)JAVA 检测网络是否为连通状态 ping
2011-03-23 14:34 2558要用java检测网络资源是否可用,我们可以采用以下两种方法: ... -
中文乱码问题的解决方法
2011-01-21 17:33 1203tomcat下中文的彻底解决[转] http://blo ... -
nginx 映射80端口
2009-08-04 09:13 3923配置一个resin, 为不用输入端 ... -
调整 Java 虚拟机
2009-07-09 23:43 1106尽管 JVM 调整操作随 JVM 提供程序的不同而有所变化,但 ... -
测试网站性能的30款免费在线工具
2009-06-28 02:12 2054你是否肯定你的网站完全兼容各大浏览器?是否知道多少秒可以打开你 ... -
Memcached-----memcached实现内存缓存
2009-06-27 15:38 2732Memcached是danga.com(运营LiveJourn ...
相关推荐
10. **代码优化**:最后但同样重要的是,编写高效、优化的代码,减少冗余,提高执行效率,也是确保Web应用可伸缩性的基础。 综上所述,构建可伸缩的Web应用涉及多个层面,从系统架构到具体的技术选择,都需要...
在探讨如何构建一个高性能的.NET应用程序时,IIS(Internet Information Services,互联网信息服务)服务器的配置是不容忽视的一个环节。IIS作为Windows平台上的主要HTTP服务器软件,广泛用于托管***网站和应用程序...
【淘宝网高性能可伸缩架构技术探秘】深入解析了如何构建高可用、可扩展的电商系统。在设计这样的架构时,几个关键点至关重要:应用无状态、有效使用缓存和应用拆分。 1. 应用无状态: 系统的伸缩性很大程度上依赖...
构建可伸缩的系统是现代IT架构设计中的关键议题,特别是在面对互联网应用、大数据处理以及云计算等场景时,系统的可伸缩性成为了决定其成功与否的重要因素。在“可伸缩的系统技术方案”这一主题下,我们探讨了一系列...
因此,选择合适的架构模式对于构建高质量的互联网应用至关重要。本文将深入探讨大型Java开发平台的技术架构,帮助读者理解当前主流的互联网应用开发模式。 #### 大型Java开发平台技术架构 Java作为一种广泛使用的...
在构建高性能、高可用、高可伸缩性的服务集群时,Linux操作系统因其开源、免费以及强大的社区支持成为了首选平台。Linux集群系统主要分为HA容错集群、负载均衡集群和HPC高性能计算机集群三类。 HA容错集群是设计...
在IT行业中,构建可伸缩的SAAS(Software as a Service)应用框架是现代企业级软件开发的关键。本章将深入探讨如何设计和实现这样的框架,以满足不断变化的业务需求,提供高效、稳定且可扩展的服务。我们将从以下几...
这种模型对于构建高性能、高并发的网络服务非常有效,因为它消除了线程或进程上下文切换的开销,降低了CPU利用率。 在这个模型中,服务器通常会创建多个工作线程,每个线程都可以独立地处理SELECT调用,这样就可以...
本书旨在探索如何构建高性能、可伸缩且具有高可用性的Web站点,特别是在PHP方面。为了确保内容的质量和实用性,作者邀请读者参与到讨论组中来,以便收集反馈并不断改进书中的内容。此外,本书还尝试打破传统技术书籍...
它的高性能和集成度高是其显著特点,包括模拟外设、内部JTAG调试、边界扫描、高速控制器内核以及数字外设等模块。其高速8051兼容内核使得它拥有100MIPS的处理速度,同时它还具备了真正的12位、8通道ADC和可在系统...
总结来说,互联网应用系统的横向扩展架构是通过服务化、中间件、读写分离、分区表、分库分表等技术手段,解决快速增长的业务需求和单体应用的局限性,构建出一个高可用、可扩展的分布式系统。这样的架构能够有效地...
云计算服务的通用性强,可为不同的企业和应用场景提供定制化的服务,并能同时运行多个应用,具备良好的伸缩性。此外,云计算的动态性也是一大特点,即使信息服务池相对固定,但分配给不同应用的资源可以根据实际需求...
### Java高性能编程——构建高可用系统的关键技术与实践 #### 引言 随着互联网技术的飞速发展,用户对服务的稳定性和响应速度提出了更高的要求。对于任何IT系统而言,“高可用性”(High Availability, HA)已经...
这种设备通常配备可插拔或可扩展的组件,如额外的显示器、存储设备或高性能处理器,可以根据用户的需求进行定制,适应不同的工作场景。在电子政务中,可伸缩电脑笔记本具有以下优势: 1. **灵活性**:政府工作人员...
在当今互联网时代,随着用户规模的不断扩大和技术需求的日益复杂,构建能够支持高并发、具备高可用性和可伸缩性的系统架构变得至关重要。本文将深入探讨高并发高可用的可伸缩架构设计的原则,并通过具体的实践方法来...
在IT领域,尤其是互联网行业,高性能和高并发是衡量服务质量和用户体验的重要指标。本文将围绕“高性能高并发服务架构”这一主题,结合提供的文档内容,深入探讨相关的知识点。 ### 1. 高性能高并发服务架构的关键...