杭州程序员圆桌交流第二期视频

本次交流在4月24日圆满完成,主题为关于JVM的那些事,撒迦@rednaxelafx给大家做了一个长达四小时的精彩分享,涵盖了javac、解释执行、c1、c2编译执行方面的知识点。

由于视频太大,感兴趣的同学请从以下地址下载,自行观看,:),也欢迎看完后在twitter上,或在这里来进行讨论。

本次交流在4月24日圆满完成,主题为关于JVM的那些事,撒迦@rednaxelafx给大家做了一个长达四小时的精彩分享,涵盖了javac、解释执行、c1、c2编译执行方面的知识点。

由于视频太大,感兴趣的同学请从以下地址下载,自行观看,:),也欢迎看完后在twitter上,或在这里来进行讨论。

ps: 撒迦同学在blog上也写了下这件事,最重要的是同时还放出了PPT,大家可以移步到此:

http://rednaxelafx.javaeye.com/blog/656951

(1)Part I
(2)Part II
(3)Part III
(4)Part IV
(5)Part V
(6)Part VI

大型应用与SOA

摘自我那本6月份要上市的,但目前名字还没完全确定的书,由于书中涵盖的更多的为构建高性能分布式Java应用所需要的基础知识,也许改成了《通往高性能分布式Java应用之路》,摘取的这段内容主要是阐述下为什么大型应用需要SOA,以及eBay的例子。

摘自我那本6月份要上市的,但目前名字还没完全确定的书,由于书中涵盖的更多的为构建高性能分布式Java应用所需要的基础知识,也许改成了《通往高性能分布式Java应用之路》,摘取的这段内容主要是阐述下为什么大型应用需要SOA,以及eBay的例子。

当应用获得用户的认可后,会不断的发展,以豆瓣 为例,早期豆瓣只有书评的功能,随着大家对豆瓣的认可以及使用的用户越来越多,豆瓣发展到了今天的豆瓣社区、豆瓣读书、豆瓣电影和豆瓣音乐等功能,这四个大块的功能有各自的特色,但又有很多可公用的业务逻辑,例如用户信息、评价等,如这四个系统都维护自己的用户信息读写或评价业务逻辑,此时会造成的问题一方面是当需要修改评价逻辑时,所有系统有可能都需要修改,当需要修改用户信息的读取方式时,也是所有系统都需要修改,会相当的复杂;另一方面是每个系统上都有很多种类的业务逻辑,这就像在一个小超市中,一个人负责收银、清洁、摆货、咨询等各种各样的事情,当来超市买东西的人多了后,这个人就没有办法再负责这么多的事情了,系统也同样如此。

第一个现象为系统多元化后带来的问题,可采用的方法为对共用逻辑的部分进行抽象,形成多个按领域划分的共用业务逻辑系统;第二个现象为系统访问量、数据量上涨后带来的典型问题,当超市的顾客不断增加时,通常超市会采取分工的方式来更好的服务顾客,同样,对于系统而言,也会采取拆分系统的方式来解决。

在构建了共用业务逻辑系统和拆分系统后,最明显的问题就是系统之间如何进行交互,如不做控制,会出现的现象是多个系统之间出现多种多样的交互方式,Http、TCP/IP+NIO、Hessian、RMI、Webservice等;同步、异步等方式可能都会出现,这会导致开发人员在每访问一个共用业务逻辑系统或拆分出来的系统后,都有可能要学习不同的交互方式;同时也会造成各开发团队重复造轮子,提供不同交互方式用的框架,这对于应用的性能、可用性而言也带来了极大的挑战。

对于上面的问题,很容易想到的一种解决方法就是统一交互的方式,SOA无疑是实现这种方式的首选指导思想。
SOA全称为面向服务架构,其强调系统之间以标准的服务方式进行交互,各系统可采用不同的语言、不同的框架进行实现,需要交互时则全部通过服务的方式来进行。

eBay也实现了一个SOA平台来支撑其业务的多元化发展 ,eBay认为SOA能给其带来的最大好处为提升业务的重用以及灵敏性,SOA平台除了要实现统一的交互外,还会碰到其他多方面的挑战,来看看eBay眼中SOA平台会带来哪些挑战:
 服务多级调用带来的延时;
当出现一个功能需要调用服务A,服务A又需要调用服务B,服务B又需要调用服务C时,这个时候会带来大幅度的延时,解决延时需要做到的是高性能的服务交互,以及完善的服务调用过程控制,例如当调用在服务B执行时已超时,那么则没必要继续调用服务C,而应该直接抛出超时异常给调用端。
 调试/跟踪困难
例如当调用服务A,服务A报错时,调用者通常会去找服务A的开发人员来解决,服务A的开发人员去查问题,有可能会发现是由于服务B报错,服务B的开发人员去查,有可能发现是网络有问题,在这样的情况下,就会导致出现问题时调试/跟踪非常困难。
 更高的安全/监测的要求
在未拆分系统时,对系统的安全和监测都只需要在一个系统上做即可,当拆分后,就必须在每个系统上都有相应的安全控制以及监测。
 现有应用移植
这一点是SOA平台在推广时的大挑战,需要移植的应用上的功能越多,就需要花费越多的时间来完成移植。
 QoS的支持
每个服务提供者能够支撑的访问量必然是有限的,因此设定服务的QoS非常重要,并且应尽可能采取一系列的措施来保障QoS,例如流量控制、机器资源分配等。
 高可用和高度可伸缩
这是互联网应用必须做到的两点,SOA平台承担了所有服务的交互,因此其可用性以及伸缩性就更会影响巨大。
 多版本和依赖管理
随着服务不断发展,以及使用面不断扩大,服务多版本的存在会成为一个大的需求,同时由于服务众多,这些服务的依赖关系也需要管理起来,以便在升级时能进行相应的安排。

eBay根据这些挑战自行实现了一个SOA平台,这个SOA平台主要包含了以下几点:
 高性能、可扩展的轻量级框架;
 监测、安全控制、流量控制的支持;
 服务注册和服务仓库;
 开发工具;

在推行SOA平台时,eBay采取的为按领域驱动的方式划分服务,同时不断的培训开发人员,以便让开发人员明确服务化后和之前单系统的方式的区别,例如可能会产生网络通信错误、超时等。

综合上面的内容来看,对于一个大型应用中的SOA平台,至少应包含以下几点功能:
 统一的服务交互方式,并可实现和现有应用的无缝集成;
 提供调试/跟踪的支持;
 依赖管理;
 高性能以及高可用。

在实现SOA时,可参考的标准或概念有SCA、ESB,同时业界也有一些实现了SCA、ESB的框架,下面就来具体的看看SCA、ESB、SCA框架以及ESB框架。

《Web容量规划的艺术》书评

twitter上@fire9给我推荐了这本书,花了一些时间把这本书看了两遍,总结性的点评语就是:“书的质量非常的高,一方面这本书中的内容来源于flickr.com实际的经验,另一方面是作者采用了很多生活中的例子来讲解一些复杂的技术,让人很快就明白了。”下面就具体来看看这本书传达的容量规划该怎么做。

twitter上@fire9给我推荐了这本书,花了一些时间把这本书看了两遍,总结性的点评语就是:“书的质量非常的高,一方面这本书中的内容来源于flickr.com实际的经验,另一方面是作者采用了很多生活中的例子来讲解一些复杂的技术,让人很快就明白了。”下面就具体来看看这本书传达的容量规划该怎么做。

容量规划主要分为四个步骤来进行:

1、设定容量的目标:例如网站需要在3秒内响应,达到99.99%的可用性。

2、收集对应的指标并找出面临的限制
这个步骤需要做的为:
测量和记录服务器的主要功能,例如数据库的主要功能为插入数据、删除数据、更新数据和获取数据,在这里书中举了个例子是没有油量表的车;
测量和记录基础硬件资源,例如cpu、文件IO、网络IO和内存的消耗;
判断服务器的主要功能如何与硬件资源关联,判断的方法为寻找主要功能增长时硬件资源的主要增长点,例如在书中的例子为flickr.com中数据库的主从复制的延时率与磁盘的IO关联,web服务器能支撑的请求量和cpu资源关联;
基于主要功能、硬件资源和容量目标,找出在目前的资源情况下所能承担的上限(例如复制延时率最多能接受的为延迟180ms,此时磁盘IO大概为40%,就此就可制对磁盘IO报警的阈值,并可观察此时系统能支撑的并发量),这里书中提到的一个方法为在生产环境中通过负载均衡来引导真实的流量来测试上限。
测量对于容量规划而言至关重要,因此书中写到了测量不是可选的,是必须的。

3、绘制趋势并根据指标和限制进行预测
基于历史数据进行曲线拟合,工具可采用excel或ftiyk,从而预测什么时候目前的资源将达到上限阀值;另外需要考虑的一点是如何制定红线,例如CPU消耗最多能接受多少,这里要根据历史的偶发高峰状况做个安全值的考虑,假设历史数据显示偶然比平时高个8%是常见的话,就至少要留个10%左右的安全空间。

4、容量部署和管理
基于上面的预测就可制定采购计划或架构调整计划了,到底什么时候需要采购机器是个复杂的问题,这个和零库存面临的问题基本是一样的;另外就是当机器到了后如何快速完成部署,因此需要自动化的部署工具。

按照上面的步骤不断的迭代可逐步的做好容量规划,但实践起来必然会有很多的难点,容量规划和性能调优的最大差别在于容量规划是基于现有状况来评估什么时候需要什么资源来支撑网站的运行,而性能调优更多的纯粹是考虑如何提升性能。

书中最后还提及到了如何应对突发增长的情况,对于突发增长的状况,由于不可能提前准备,书中给的几个建议是:禁用重量级的功能、临时采用静态页面、缓存而不是过期以及采用更为人性化的方式处理故障,最后一点我觉得最有意思,这也是我们现在处理故障时遗漏的,书中举了一个例子来比喻,就是如果厨房被淹了,此时有个水管工在处理的话,你会感觉到至少有人在处理,而一个好的水管工还会告诉你原因和解决的方法,在这样的情况下也许你能对这个故障更加容忍了。

最后,强烈向希望能够预测什么时候需要增加多少资源,或做什么架构调整的同学推荐这本书,相信会给你带来很多的感触,毕竟这是来源于flickr.com的实际经验。

Unicorn给Twitter带来的效果

3月30日Twitter在其engineering blog上写了一篇Unicorn Power的blog:http://engineering.twitter.com/2010/03/unicorn-power.html,写的挺经典的,按我的理解来讲下这篇blog吧,如有错误,请帮忙纠正,:)。

3月30日Twitter在其engineering blog上写了一篇Unicorn Power的blog:http://engineering.twitter.com/2010/03/unicorn-power.html,写的挺经典的,按我的理解来讲下这篇blog吧,如有错误,请帮忙纠正,:)。
@sandofsky和@netik在blog中首先举了个经典的超市收银的问题,通常超市会有多个收银台,在高峰期通常每个收银台前都会排队,而这个时候如果某个顾客买的东西特别多,或者某个顾客买东西时遇到麻烦的话,就会导致队伍后面的人要排很久的队,而其实此时其他的队有可能处理的更快很多,这种情况会造成的问题是有些人先排的队,但却等了更长很多的时间,于是有家叫Fry的超市,采取了另外一种方法来进行收银,就是让所有的顾客在同一个地方排队,然后三十个收银员进行收银,每完成一个时就按下信号灯,表示可以去该收银台进行付款了,这样之后的好处是减少了由于个别顾客造成一堆人等待很长时间的现象。
从超市的例子脱离出来,来看看twitter的状况,之前twitter运行在apache和mongrel上,通过mod_proxy_balancer来做负载均衡,每台业务处理器能处理一定的请求,处理不过来的就排队,于是就有可能出现有些用户不幸的在处理比较慢的机器中排队,在排了长时间后可能会出现的是超时,而另外一个问题就是队列排不下了,就只能丢弃请求了,但其实也许这个时候如果请求都合理的分配的话,可能能够让超时或丢弃请求的现象降低,于是twitter的工程师开始寻求改变。
在去年11月,twitter开始尝试Unicorn,unicorn增加了一个类似Fry超市的拉的方式,twitter首先在mobile.twitter.com上进行了尝试,到了今年1月,已经在twitter.com上也采用了unicorn,在采用Unicorn了后,twitter惊喜的发现,它们明显的降低了30%的请求延时,并且还很明显的降低了CPU使用率。
其他的是一些监测方面的介绍,就不在此分析了,感兴趣的同学可以看看原作。

这篇blog给了我挺大的感触的,在标准的通过硬件负载设备访问real server时,尤其典型的通过硬件负载设备访问后端tomcat的情况中,会出现的现象就和twitter的现象基本一样了,假设一个tomcat只能处理100个请求,为了避免用户太高的失败率,必然会给一个较大的等待队列,这个时候就会出现如果请求处理慢,就导致了排在队中的用户要等待很久,从而造成超时或请求丢弃,如果能采取类似Fry的方法,那么就能够做到按照用户发起请求的顺序来进行处理了,而不会因为个别用户请求处理慢就造成排队的用户超时和请求被拒绝的现象,这确实是一个合理发挥server请求处理能力的负载均衡不同角度的策略,但这里其实有个要求,就是负载设备或软件负载方案要能支持排队功能,这对传统的方案还是有一定挑战的(例如最少连接数),但无论如何,其能带来的效果还是明显的。

ps: 不过如果一家超市只有一个队的话,那得多长呀…有些时候可能会给顾客造成心理压力,搞不好就不买了,呵呵,当然,应用到软件领域倒是没这个问题,反正用户也不知道现在排的队有多长,:)